docs(plugin-audit-port): correct the context: fork rejection rationale - #1274
Conversation
Closes #1268 The deep-audit phase rejects `context: fork` on the stated grounds that a fork "inherits the degraded history the gate exists to escape". That is false for `context: fork`. Per the skills reference (fetched 2026-07-24) a forked skill "won't have access to your conversation history" — it would satisfy the fresh-eyes requirement it was being rejected for. The decision is unchanged. The real basis was already recorded in the same PLAN's [EXEC-SHAPE] agent decision: plugin agents start with fresh context and the Brief requires a NAMED subagent, which a forked skill is not. Both prose sites now carry that basis, and `design-resolution.md` — which stated the rule with no rationale — gains it. History inheritance is documented for the Agent tool's separate `fork` subagent type. That attribution is stated as documented rather than as observed, because #1258 reports Agent-tool forks not inheriting the conversation in practice either. The correction does not depend on which way #1258 resolves: the named-subagent requirement is the load-bearing basis, and the skills reference settles the `context: fork` half independently. A wrong rationale in a design record propagates into later decisions that cite it, which is why the reason is corrected even though the outcome stands. The same inversion was already fixed once in docs-hygiene under #1053. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
Claude finished @kyle-sexton's task in 2m 37s —— View job PR Review — docs(plugin-audit-port): correct the context: fork rejection rationale
Verdict: Approve with one advisory note. The correction is accurate and the two changed files are internally consistent. Both carry the right load-bearing reasons now, and the What the diff does wellConstraints section ( Alternatives table ( Design resolution ( One advisory note
This is a third site in the same file that cites the rejection basis — but here it is without the corrected rationale. The "fresh-eyes doctrine" as defined in This site is in the Test plan verification
No functional changes; no security surface; no plugin manifest edits. Ready to merge. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: e179e2f8c8
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
…tating it Review finding on #1274. The "why not context: fork" rationale had grown a third and fourth independent wording — the alternatives-table cell and design-resolution.md's design-thread map each stated their own version, and design-resolution.md's had already drifted, asserting "both start with fresh context" which the EXEC-SHAPE basis does not say. Both now point at the `[EXEC-SHAPE]` plugin-agent decision, which is the single home for that basis. Per the topic-docs single-home rule and point-dont-copy, a reworded paraphrase drifts exactly as a verbatim copy does — this PR was creating the drift it exists to correct. The mechanism disambiguation stays in the alternatives cell, because that cell is where the false claim lived and a reader scanning rejected options needs to see which "fork" was meant. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
Claude finished @kyle-sexton's task in 2m 6s —— View job PR Review — docs(plugin-audit-port): point at the EXEC-SHAPE basis instead of restating it
Verdict: Approve. The Codex challenge does not land; the second commit addresses my prior advisory. Second commit (
|
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: df3d0648e8
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
… fork The audit skill told every invocation that a fork "would inherit this session's degraded history". A skill's `context: fork` frontmatter does the opposite: the forked subagent starts with no conversation history at all. Conversation inheritance belongs to the Agent tool's separate `fork` subagent type. Step 2 now names that type explicitly and also forbids running inline, which is the failure mode the sentence was reaching for. The skill-lens composition question likewise stops treating a forked sub-skill's lack of history as a defect and asks whether the choice fits the step. The plan's rejection rationale was also unsupported. It claimed `context: fork` is anonymous, but the skills frontmatter `agent` field selects the subagent type for a forked skill, and discovery's explore-deep ships that pairing. Neither "fresh context" nor "named" discriminates, so neither can be the basis. The real basis is topological: `context: fork` forks the whole skill, and only steps 2-3 want a fresh context. Step 1 reads this session's own conversation to capture evidence, and steps 4 and 6 need user-interactive surfaces a forked skill does not get. A skill cannot fork one of its own steps. That basis now has one home under the [EXEC-SHAPE] agent decision, self-standing rather than circularly deferring to the Brief, with the Brief, the alternatives row, phase B3, and design-resolution pointing at it. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
…context note Fourth site carrying the ambiguity. `agents/auditor.md` said it has no conversation history "by design", leaving the reader to infer why. It now states the mechanism — a named subagent, not a conversation fork — so the sentence cannot be read as a claim about `context: fork`. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
Claude finished @kyle-sexton's task in 2m 50s —— View job PR Review — docs(plugin-audit-port): correct the context: fork rejection rationale
Verdict: Approve. All previous review concerns resolved; the PR is complete. Third commit (
|
|
Claude finished @kyle-sexton's task in 1m 8s —— View job Security Review — docs(plugin-audit-port): correct the context: fork rejection rationale
No security issues found. This PR is a documentation correction with a corresponding patch-version bump. All seven changed files were reviewed against the diff:
No code execution paths, file-access patterns, network-access surfaces, permission grants, GitHub Actions workflows, dependency pins, or secrets were added or modified. The |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 73abd759b7
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
…, not as fork behavior Review findings on #1274. Two more rationales fell. Three successive bases for rejecting `context: fork` have now each been refuted: it inherits degraded history (false — a forked skill has no conversation access); a forked skill is anonymous (false — the `agent` frontmatter field names the subagent type); a forked sibling cannot receive per-run inputs (false — `$ARGUMENTS` is that channel, and `plugins/discovery/skills/explore-deep/SKILL.md` ships the pattern). Every one of them argued from what fork does. The requirement does not depend on that, so it is stated positively instead: the deep phase needs a context that provably excludes this session's evidence, and a named dispatch target that makes the dispatch site auditable. `agents/auditor.md` supplies both and already ships. `context: fork` is therefore no longer rejected as impossible — it is rejected on cost, because it needs a second skill existing only to be forked, spending shared skill-listing budget (#1271 measures that budget and the silent description drops it causes) for zero user-facing capability. The shipped step-2 instruction no longer asserts that the Agent-tool fork inherits the conversation. That claim is contested by #1258, and a shipped prompt should not state a contested empirical claim as settled — especially not one it uses to forbid an execution mode. The invariant holds either way #1258 resolves. Out of scope, recorded: `plugins/planning/skills/audit-answers/SKILL.md:49,96` carry the same fork-inheritance assertion. Different plugin, and fixing it here would widen this diff and pull in a second version bump. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
Claude finished @kyle-sexton's task in 2m 50s —— View job PR Review — docs(plugin-audit-port): correct the context: fork rejection rationale
Verdict: Approve. The fifth commit answers all three Codex challenges; the PR is complete. What
|
| Codex challenge | Commit it landed on | Status after dac51f3 |
|---|---|---|
Named-subagent basis unsupported (context: fork + agent: pairing) |
e179e2f |
Prior Claude review established this was already addressed in df3d064; still correct |
| SKILL.md:127-128 still carried the stale fork-inheritance claim | df3d064 |
d70ee7a removed it; dac51f3 further replaces the contested unconditional wording |
$ARGUMENTS closes the sibling-input channel; explore-deep ships it |
73abd75 |
Conceded in dac51f3; rejection now rests on cost, not impossibility |
Out-of-scope, noted
The commit message records plugins/planning/skills/audit-answers/SKILL.md:49,96 carrying the same fork-inheritance assertion in a different plugin. Deferring is correct — fixing it here would cross a plugin boundary and pull in a second version bump. Worth a follow-up issue if the pattern needs systematic correction.
Test plan verification
grep -rn "degraded history" docs/topics/plugin-audit-port/— no matchesgrep -rn "degraded history" plugins/plugin-quality/— no matches (SKILL.md no longer carries this)[EXEC-SHAPE]row at:553is unmodified; the basis subsection it points to is expanded but consistent- No functional changes, no security surface, no manifest schema violations, no new permissions
#1258forward-reference hedged correctly; this PR's correctness does not depend on that issue's resolution
Ready to merge.
|
Claude finished @kyle-sexton's task in 1m 30s —— View job Security Review — docs(plugin-audit-port): correct the context: fork rejection rationale
No security issues found. All seven changed files were reviewed against the full diff. The PR is a documentation correction with a patch-version bump and carries no security surface.
Checked specifically:
|
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: dac51f3e69
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
…evidence packet Review finding on #1274, and the invariant I wrote was self-contradicting. It said the auditor's context "provably excludes this session's evidence". The opposite is required: `agents/auditor.md`'s procedure opens by reading the evidence packet as its ground truth, and step 1 exists solely to write that packet. The chosen implementation violated the property the text used to reject alternatives. What must not cross is the main thread's conversation history and prior reasoning — the reasoning that produced the work under review, which a same-context self-check cannot escape. The packet is the deliberate channel across the boundary, which is also what makes the design compaction-proof and resumable. Corrected at both sites: the shipped step-2 instruction and the plan's `[EXEC-SHAPE]` basis. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
Claude finished @kyle-sexton's task in 1m 31s —— View job Security Review — docs(plugin-audit-port): correct the context: fork rejection rationale
No security issues found. All seven changed files were reviewed against the full diff. The PR is a documentation correction with patch-version bumps and carries no security surface.
Checked specifically:
|
|
Claude finished @kyle-sexton's task in 2m 5s —— View job PR Review — docs(plugin-audit-port): correct the context: fork rejection rationale
Verdict: Approve with one remaining fix needed — CHANGELOG What
|
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 9101dc98e1
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
…raming Review findings on #1274. Both were sites the previous two commits missed. The constraints bullet still said `context: fork` "cannot express this topology" while the [EXEC-SHAPE] basis in the same revision concedes a forked sibling can run steps 2-3 with the parent retaining 1, 4 and 6. The bullet now matches the alternatives table: not chosen, on listing-budget and synchronization cost. The 0.1.2 changelog entry still described the invariant as excluding the session's evidence — the same contradiction the shipped wording had just been corrected for, reintroduced in the release note a reader consults first. It now states the invariant as excluding conversation history and prior reasoning, and says the packet crossing the boundary is deliberate. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
Claude finished @kyle-sexton's task in 1m 54s —— View job PR Review — docs(plugin-audit-port): clear two internal contradictions in the reframing
Verdict: Approve. Both Codex fifth review challenges resolved; the PR is complete. What
|
| Site | Language |
|---|---|
Constraint bullet (:80–81) |
"not chosen — rejected on listing-budget and synchronization cost, not as inexpressible" |
Alternatives table (:461) |
"Not impossible — rejected on cost" |
[EXEC-SHAPE] basis (:609–613) |
"not rejected as impossible. It is rejected on cost" |
Test plan verification
grep -rn "cannot express" docs/topics/plugin-audit-port/— no matches ✓grep -rn "excludes.*session.*evidence" plugins/plugin-quality/ docs/topics/plugin-audit-port/— no matches ✓grep -rn "degraded history" docs/topics/plugin-audit-port/ plugins/plugin-quality/— only in historical/defeated-rationale context (PLAN.md:593, CHANGELOG.md:25) ✓[EXEC-SHAPE]row at:553unmodified ✓- No functional changes, no security surface, no permission additions, no manifest schema violations ✓
#1258forward-reference hedged correctly in PLAN.md and CHANGELOG; this PR's correctness does not depend on its resolution ✓
No outstanding review concerns. Ready to merge.
|
Claude finished @kyle-sexton's task in 1m 33s —— View job Security Review — docs(plugin-audit-port): correct the context: fork rejection rationale
No security issues found. All seven changed files were reviewed against the full diff. The PR is a documentation correction with patch-version bumps and carries no security surface.
Checked specifically:
|
Closes #1268
Summary
docs/topics/plugin-audit-port/rejectedcontext: forkfor the deep-audit phase on the stated grounds that a fork "inherits the degraded history the gate exists to escape" (PLAN.md:78-79, and again in the alternatives table at:457).That is false for
context: fork. Per the skills reference (fetched 2026-07-24) a forked skill "won't have access to your conversation history" — it would satisfy the fresh-eyes requirement it was being rejected for.The decision is unchanged. The real basis was already recorded in the same PLAN's
[EXEC-SHAPE]agent decision at:550: plugin agents start with fresh context, and the Brief requires a named subagent, which a forked skill is not. Both prose sites now carry that basis, anddesign/design-resolution.md— which stated the rule with no rationale at all — gains it.A wrong rationale in a design record propagates into later decisions that cite it, which is why the reason is corrected even though the outcome stands.
Test plan
grep -rn -i "degraded history" docs/topics/plugin-audit-port/— no matches[EXEC-SHAPE]decision at:550is unmodified; the corrected text points at it rather than restating itRelated
One claim is deliberately attributed rather than asserted. History inheritance is documented for the Agent tool's separate
forksubagent type. #1258 reports empirically that Agent-tool forks did not inherit the conversation, contradicting that doc. The corrected text therefore says "documented for", not "does". The correction here does not depend on how #1258 resolves — the named-subagent requirement is the load-bearing basis, and the skills reference settles thecontext: forkhalf independently.Prior art, both closed: #1053 fixed the identical inversion in
docs-hygiene'saudit-derivabilityrubric and evals; #1062 clarified its Hard Rules wording. This is the same class of error in a different file, not a duplicate.Adjacent, non-overlapping: #1252 also edits
plugin-audit-port/PLAN.md, at:551— the table row directly below the[EXEC-SHAPE]row this PR points at. It does not touch that row, and this PR does not touch:551.