QA: intra-run lane-ownership primitive, plus a void-vs-flaky triage rule #43

Author

Owner

{
  "status": "resolved",
  "chosen_option": "accept",
  "rationale": "slot-isolation.md is the canonical owner of cross-slot provisioning and allocation, and the SREQ pins the dependency direction (this feature consumes slot identities, never allocates); forking that ownership would violate the one-canonical-home rule. Autonomous resolution by the orchestrating session under the operator's delegated wave-1 orchestration; the planning session's recommendation was followed."
}

```json { "status": "resolved", "chosen_option": "accept", "rationale": "slot-isolation.md is the canonical owner of cross-slot provisioning and allocation, and the SREQ pins the dependency direction (this feature consumes slot identities, never allocates); forking that ownership would violate the one-canonical-home rule. Autonomous resolution by the orchestrating session under the operator's delegated wave-1 orchestration; the planning session's recommendation was followed." } ```

jbr870 commented

Author

Owner

{
  "status": "resolved",
  "chosen_option": "accept",
  "rationale": "Already filed as #62 and accumulating live evidence (comment 1278, wave 1); it constrains this design via AC-5/AC-6 but is fixed there, not here. Autonomous resolution by the orchestrating session under the operator's delegated wave-1 orchestration; the planning session's recommendation was followed."
}

```json { "status": "resolved", "chosen_option": "accept", "rationale": "Already filed as #62 and accumulating live evidence (comment 1278, wave 1); it constrains this design via AC-5/AC-6 but is fixed there, not here. Autonomous resolution by the orchestrating session under the operator's delegated wave-1 orchestration; the planning session's recommendation was followed." } ```

jbr870 commented

Author

Owner

{
  "status": "resolved",
  "chosen_option": "accept",
  "rationale": "A deliberate non-goal, not deferred work: AC-5/AC-6 plus a mechanical lint check enforce that no new mandatory CLAUDE.md block is introduced, matching the operator's requirements-time decision (suite-owned vocabulary, optional project extension). Autonomous resolution by the orchestrating session under the operator's delegated wave-1 orchestration; the planning session's recommendation was followed."
}

```json { "status": "resolved", "chosen_option": "accept", "rationale": "A deliberate non-goal, not deferred work: AC-5/AC-6 plus a mechanical lint check enforce that no new mandatory CLAUDE.md block is introduced, matching the operator's requirements-time decision (suite-owned vocabulary, optional project extension). Autonomous resolution by the orchestrating session under the operator's delegated wave-1 orchestration; the planning session's recommendation was followed." } ```

jbr870 commented

Author

Owner

{
  "status": "resolved",
  "chosen_option": "accept",
  "rationale": "Owned by #40, whose convergence-rule amendment already landed on main (6aeae6b, 2026-08-25) — the fix-loop exit criteria are suite text now; nothing remains to spawn. Autonomous resolution by the orchestrating session under the operator's delegated wave-1 orchestration; the planning session's recommendation was followed."
}

```json { "status": "resolved", "chosen_option": "accept", "rationale": "Owned by #40, whose convergence-rule amendment already landed on main (6aeae6b, 2026-08-25) — the fix-loop exit criteria are suite text now; nothing remains to spawn. Autonomous resolution by the orchestrating session under the operator's delegated wave-1 orchestration; the planning session's recommendation was followed." } ```

jbr870 commented

Author

Owner

{
  "status": "resolved",
  "chosen_option": "accept",
  "rationale": "Runner sharding and CI parallelism are pure project stack; per the repo litmus test the suite must not hold an opinion on them, so there is nothing suite-side to track. Autonomous resolution by the orchestrating session under the operator's delegated wave-1 orchestration; the planning session's recommendation was followed."
}

```json { "status": "resolved", "chosen_option": "accept", "rationale": "Runner sharding and CI parallelism are pure project stack; per the repo litmus test the suite must not hold an opinion on them, so there is nothing suite-side to track. Autonomous resolution by the orchestrating session under the operator's delegated wave-1 orchestration; the planning session's recommendation was followed." } ```

jbr870 commented

Author

Owner

{
  "status": "resolved",
  "chosen_option": "accept",
  "rationale": "Proactive liveness cadence is wait-discipline.md subject matter already owned by open issues #44 and #58 — which gained two further independent sightings today (#43 comment 1327); a second waiting protocol here would restate their scope. Autonomous resolution by the orchestrating session under the operator's delegated wave-1 orchestration; the planning session's recommendation was followed."
}

```json { "status": "resolved", "chosen_option": "accept", "rationale": "Proactive liveness cadence is wait-discipline.md subject matter already owned by open issues #44 and #58 — which gained two further independent sightings today (#43 comment 1327); a second waiting protocol here would restate their scope. Autonomous resolution by the orchestrating session under the operator's delegated wave-1 orchestration; the planning session's recommendation was followed." } ```

jbr870 commented

Author

Owner

{
  "status": "resolved",
  "chosen_option": "accept",
  "rationale": "The SREQ makes serialization cost measurable from the record itself (waited_ms on every DISPATCH entry), so the study can run on real data after landing; gating a correctness fix on a prior performance study would invert the operator's standing correct-over-fast priority. Autonomous resolution by the orchestrating session under the operator's delegated wave-1 orchestration; the planning session's recommendation was followed."
}

```json { "status": "resolved", "chosen_option": "accept", "rationale": "The SREQ makes serialization cost measurable from the record itself (waited_ms on every DISPATCH entry), so the study can run on real data after landing; gating a correctness fix on a prior performance study would invert the operator's standing correct-over-fast priority. Autonomous resolution by the orchestrating session under the operator's delegated wave-1 orchestration; the planning session's recommendation was followed." } ```

jbr870 commented

2026-08-25 10:43:31 +00:00

Author

Owner

{
  "status": "resolved",
  "chosen_option": "accept",
  "rationale": "The lane split is the declared validation model, not a gap: this repo declares e2e/a11y/security-browser not applicable and uat.url_source defines validation as merged-text review plus dogfooding, so 12/17 human-uat lanes is the honest mechanical ceiling, made visible per technical-plan 2.6b. Autonomous resolution by the orchestrating session under the operator's delegated wave-1 orchestration; the planning session's recommendation was followed."
}

```json { "status": "resolved", "chosen_option": "accept", "rationale": "The lane split is the declared validation model, not a gap: this repo declares e2e/a11y/security-browser not applicable and uat.url_source defines validation as merged-text review plus dogfooding, so 12/17 human-uat lanes is the honest mechanical ceiling, made visible per technical-plan 2.6b. Autonomous resolution by the orchestrating session under the operator's delegated wave-1 orchestration; the planning session's recommendation was followed." } ```

jbr870 commented

Author

Owner

{
  "status": "resolved",
  "chosen_option": "defer-to-issue",
  "rationale": "Real hole independently raised by the solution-architect review and tracked nowhere: a resumed driver can read DISPATCH/RELEASE entries, but nothing defines who may reclaim an open claim or on what evidence — recovery semantics that must stay consistent with the operator's positive-death-check rule and deserve their own requirements round. Autonomous resolution by the orchestrating session under the operator's delegated wave-1 orchestration; the planning session's recommendation was followed.",
  "rejected_alternative": "Folding into #46 or #58 was considered and rejected: both are wait-discipline protocols about live-actor signals, not claim-state recovery after the driver dies; the match was weak, and prefer-spawn-when-uncertain applies."
}

```json { "status": "resolved", "chosen_option": "defer-to-issue", "rationale": "Real hole independently raised by the solution-architect review and tracked nowhere: a resumed driver can read DISPATCH/RELEASE entries, but nothing defines who may reclaim an open claim or on what evidence — recovery semantics that must stay consistent with the operator's positive-death-check rule and deserve their own requirements round. Autonomous resolution by the orchestrating session under the operator's delegated wave-1 orchestration; the planning session's recommendation was followed.", "rejected_alternative": "Folding into #46 or #58 was considered and rejected: both are wait-discipline protocols about live-actor signals, not claim-state recovery after the driver dies; the match was weak, and prefer-spawn-when-uncertain applies." } ```

jbr870 referenced this issue

2026-08-25 10:43:32 +00:00

Reconstructing outstanding claims after the driver itself dies mid-run #65

jbr870 commented

2026-08-25 10:43:32 +00:00

Author

Owner

Linked: this issue is sibling #65 (recorded by the devwork pipeline).

Linked: this issue is **sibling** #65 (recorded by the devwork pipeline).

jbr870 commented

2026-08-25 10:43:33 +00:00

Author

Owner

{
  "status": "resolved",
  "chosen_option": "defer-to-issue",
  "rationale": "Covering actors that never claim (migrations, provisioning steps, humans at terminals) would need the enforcement layer the operator declined, so the boundary is permanent in the declared-and-honoured model; a tracked issue keeps that known blind spot visible instead of silent. Autonomous resolution by the orchestrating session under the operator's delegated wave-1 orchestration; the planning session's recommendation was followed.",
  "rejected_alternative": "Accepting with no follow-up was considered and rejected: the panel identified this as the residual hole of the chosen model, and silence would erase the limit from the record."
}

```json { "status": "resolved", "chosen_option": "defer-to-issue", "rationale": "Covering actors that never claim (migrations, provisioning steps, humans at terminals) would need the enforcement layer the operator declined, so the boundary is permanent in the declared-and-honoured model; a tracked issue keeps that known blind spot visible instead of silent. Autonomous resolution by the orchestrating session under the operator's delegated wave-1 orchestration; the planning session's recommendation was followed.", "rejected_alternative": "Accepting with no follow-up was considered and rejected: the panel identified this as the residual hole of the chosen model, and silence would erase the limit from the record." } ```

jbr870 referenced this issue

2026-08-25 10:43:33 +00:00

Contention caused by actors that never claimed anything (a migration, a provisioning step, a human at a terminal) #66

jbr870 commented

2026-08-25 10:43:34 +00:00

Author

Owner

Linked: this issue is sibling #66 (recorded by the devwork pipeline).

Linked: this issue is **sibling** #66 (recorded by the devwork pipeline).

jbr870 commented

2026-08-25 10:43:34 +00:00

Author

Owner

{
  "status": "resolved",
  "chosen_option": "defer-to-issue",
  "target_issue_ref": "39",
  "rationale": "The finding is a direct constraint on #39's payoff: with one declared test database per slot, dispatch serializes and #39's concurrency gain caps at one suite until a project widens its pool via slot-isolation derived_suffixes. #39 is filed and pre-PREQ, so its requirements round is exactly where that trade-off must be weighed — a confident topical fold per the autonomous-folding rule. Autonomous resolution by the orchestrating session under the operator's delegated wave-1 orchestration; the planning session's recommendation was followed.",
  "rejected_alternative": "Spawning a separate performance issue was considered and rejected: separated from #39, the finding loses the very decision it exists to inform."
}

```json { "status": "resolved", "chosen_option": "defer-to-issue", "target_issue_ref": "39", "rationale": "The finding is a direct constraint on #39's payoff: with one declared test database per slot, dispatch serializes and #39's concurrency gain caps at one suite until a project widens its pool via slot-isolation derived_suffixes. #39 is filed and pre-PREQ, so its requirements round is exactly where that trade-off must be weighed — a confident topical fold per the autonomous-folding rule. Autonomous resolution by the orchestrating session under the operator's delegated wave-1 orchestration; the planning session's recommendation was followed.", "rejected_alternative": "Spawning a separate performance issue was considered and rejected: separated from #39, the finding loses the very decision it exists to inform." } ```

jbr870 commented

2026-08-25 10:43:36 +00:00

Author

Owner

Linked: this issue is sibling #39 (recorded by the devwork pipeline).

Linked: this issue is **sibling** #39 (recorded by the devwork pipeline).

jbr870 commented

2026-08-25 11:33:38 +00:00

Author

Owner

{
  "waves": [
    {
      "wave": 1,
      "work_units": [
        {
          "id": "WU-43-3-1",
          "title": "The canonical rule + its record shapes",
          "files": [
            "plugin/skills/_shared/procedures/run-resource-claims.md",
            "plugin/skills/_shared/procedures/journal-template.md"
          ],
          "acceptance_criteria": [
            {"id": "AC-1", "scope": "the serialize-default rule is stated here"},
            {"id": "AC-2", "scope": "the claim block shape and its fixed keys"},
            {"id": "AC-3"},
            {"id": "AC-4", "scope": "remedy is a required DISPATCH key"},
            {"id": "AC-5", "scope": "the doc declares the no-declaration default"},
            {"id": "AC-6", "scope": "project-named classes via existing surfaces"},
            {"id": "AC-7"},
            {"id": "AC-8"},
            {"id": "AC-9", "scope": "DISPATCH/RELEASE entry types + the named journal file + the triage scan recipe"},
            {"id": "AC-10", "scope": "the routing rule as stated in the doc"},
            {"id": "AC-13"},
            {"id": "AC-15"},
            {"id": "AC-16", "scope": "the run-resource-claims side of the cross-reference"}
          ]
        },
        {
          "id": "WU-43-3-2",
          "title": "QA consumer edits — playbook precondition + spawn rule, triage, late withdrawal, fixer re-run",
          "files": [
            "plugin/skills/_shared/procedures/qa-playbook.md",
            "plugin/skills/_shared/procedures/validate-workflow.md",
            "plugin/skills/_shared/procedures/fix-workflow.md"
          ],
          "acceptance_criteria": [
            {"id": "AC-1", "scope": "qa-playbook references the rule, does not restate it"},
            {"id": "AC-2", "scope": "the spawn-prompt rule for QA-dispatched actors"},
            {"id": "AC-10", "scope": "validate-workflow Step 3 structural classification"},
            {"id": "AC-11"},
            {"id": "AC-12"},
            {"id": "AC-14", "scope": "the QA playbook half of the cite-by-path requirement"}
          ]
        },
        {
          "id": "WU-43-3-3",
          "title": "Lifecycle + cross-reference edits — develop wave parallelism, worktree-discipline pointer, lane/claim disambiguation",
          "files": [
            "plugin/skills/develop/SKILL.md",
            "plugin/skills/_shared/procedures/worktree-discipline.md",
            "plugin/skills/_shared/schemas/test-plan.v1.md"
          ],
          "acceptance_criteria": [
            {"id": "AC-2", "scope": "the spawn-prompt rule for /dev:develop work units"},
            {"id": "AC-14", "scope": "the /dev:develop half of the cite-by-path requirement"},
            {"id": "AC-16", "scope": "the test-plan.v1 side of the cross-reference"}
          ]
        }
      ]
    },
    {
      "wave": 2,
      "work_units": [
        {
          "id": "WU-43-3-4",
          "title": "Mechanical gate — lint checks asserting the shape the other three produced",
          "files": [
            "scripts/lint-conventions.sh",
            "scripts/test-lint-conventions.sh"
          ],
          "acceptance_criteria": [
            {"id": "AC-5", "scope": "mechanical: no new required item in readiness-check.md"},
            {"id": "AC-6", "scope": "mechanical: no new mandatory declaration block"},
            {"id": "AC-14", "scope": "mechanical: normative sentences in exactly one file; both consumers cite by path"},
            {"id": "AC-15", "scope": "mechanical: the new doc carries no derivation rules"},
            {"id": "AC-16", "scope": "mechanical: reciprocal cross-references exist"}
          ]
        }
      ]
    }
  ]
}

Decomposition

Four work units in two waves, following the SREQ's Implementation Scope with one merge.

The merge: the SREQ split the canonical document (its WU-1) from the journal-template.md
entry types (its WU-2). Those are folded into WU-43-3-1. The SREQ itself says the entry shapes
"are specified here", so the two halves are one design; the DISPATCH/RELEASE YAML in
journal-template.md and the lifecycle prose in run-resource-claims.md must agree field-for-field,
and that agreement is exactly what drifts when two authors write it from the same spec independently.
One author, two files, no shared file with any other unit.

Intra-wave execution is sequential, not parallel. This project runs on a single shared worktree
(/dev:git-worktrees slot machinery is deliberately unused here — CLAUDE.md §Parallel sessions), so
per /dev:develop §3.1 the wave's units run one complete Test-Writer→Implementer pair at a time. The
wave structure below is an ordering, not a concurrency claim. This is also the cheapest possible
dogfood of the feature under construction: the one contended resource in this repo is the
bash scripts/lint-conventions.sh gate itself, and serialize-by-default is what the rule prescribes
when claims cannot be made disjoint.

Wave 2 is a real barrier. WU-43-3-4's checks assert the shape the first three units produce. A
check authored before its target exists fails for the wrong reason and teaches the author to weaken
it — so the gate lands last, against real content.

Test Writer disposition. WU-43-3-1 through WU-43-3-3 are artifact-shape units: every acceptance
criterion they carry is an assertion about the text of a skill-markdown file, verified by code-domain
inspection and — for the load-bearing ones — by WU-43-3-4's mechanical checks. There is no behaviour
for a behavioural test to exercise, so those three spawn an Implementer only, per /dev:develop §3.2's
artifact-shape exception, and each records the skip in its outcome summary. WU-43-3-4 spawns both:
its acceptance criteria are behavioural (a check must fire on a violation and stay silent on a
conforming tree), and this repo has a real harness for exactly that in scripts/test-lint-conventions.sh.

```json { "waves": [ { "wave": 1, "work_units": [ { "id": "WU-43-3-1", "title": "The canonical rule + its record shapes", "files": [ "plugin/skills/_shared/procedures/run-resource-claims.md", "plugin/skills/_shared/procedures/journal-template.md" ], "acceptance_criteria": [ {"id": "AC-1", "scope": "the serialize-default rule is stated here"}, {"id": "AC-2", "scope": "the claim block shape and its fixed keys"}, {"id": "AC-3"}, {"id": "AC-4", "scope": "remedy is a required DISPATCH key"}, {"id": "AC-5", "scope": "the doc declares the no-declaration default"}, {"id": "AC-6", "scope": "project-named classes via existing surfaces"}, {"id": "AC-7"}, {"id": "AC-8"}, {"id": "AC-9", "scope": "DISPATCH/RELEASE entry types + the named journal file + the triage scan recipe"}, {"id": "AC-10", "scope": "the routing rule as stated in the doc"}, {"id": "AC-13"}, {"id": "AC-15"}, {"id": "AC-16", "scope": "the run-resource-claims side of the cross-reference"} ] }, { "id": "WU-43-3-2", "title": "QA consumer edits — playbook precondition + spawn rule, triage, late withdrawal, fixer re-run", "files": [ "plugin/skills/_shared/procedures/qa-playbook.md", "plugin/skills/_shared/procedures/validate-workflow.md", "plugin/skills/_shared/procedures/fix-workflow.md" ], "acceptance_criteria": [ {"id": "AC-1", "scope": "qa-playbook references the rule, does not restate it"}, {"id": "AC-2", "scope": "the spawn-prompt rule for QA-dispatched actors"}, {"id": "AC-10", "scope": "validate-workflow Step 3 structural classification"}, {"id": "AC-11"}, {"id": "AC-12"}, {"id": "AC-14", "scope": "the QA playbook half of the cite-by-path requirement"} ] }, { "id": "WU-43-3-3", "title": "Lifecycle + cross-reference edits — develop wave parallelism, worktree-discipline pointer, lane/claim disambiguation", "files": [ "plugin/skills/develop/SKILL.md", "plugin/skills/_shared/procedures/worktree-discipline.md", "plugin/skills/_shared/schemas/test-plan.v1.md" ], "acceptance_criteria": [ {"id": "AC-2", "scope": "the spawn-prompt rule for /dev:develop work units"}, {"id": "AC-14", "scope": "the /dev:develop half of the cite-by-path requirement"}, {"id": "AC-16", "scope": "the test-plan.v1 side of the cross-reference"} ] } ] }, { "wave": 2, "work_units": [ { "id": "WU-43-3-4", "title": "Mechanical gate — lint checks asserting the shape the other three produced", "files": [ "scripts/lint-conventions.sh", "scripts/test-lint-conventions.sh" ], "acceptance_criteria": [ {"id": "AC-5", "scope": "mechanical: no new required item in readiness-check.md"}, {"id": "AC-6", "scope": "mechanical: no new mandatory declaration block"}, {"id": "AC-14", "scope": "mechanical: normative sentences in exactly one file; both consumers cite by path"}, {"id": "AC-15", "scope": "mechanical: the new doc carries no derivation rules"}, {"id": "AC-16", "scope": "mechanical: reciprocal cross-references exist"} ] } ] } ] } ``` ## Decomposition Four work units in two waves, following the SREQ's Implementation Scope with one merge. **The merge:** the SREQ split the canonical document (its WU-1) from the `journal-template.md` entry types (its WU-2). Those are folded into **WU-43-3-1**. The SREQ itself says the entry shapes "are specified here", so the two halves are one design; the `DISPATCH`/`RELEASE` YAML in `journal-template.md` and the lifecycle prose in `run-resource-claims.md` must agree field-for-field, and that agreement is exactly what drifts when two authors write it from the same spec independently. One author, two files, no shared file with any other unit. **Intra-wave execution is sequential, not parallel.** This project runs on a single shared worktree (`/dev:git-worktrees` slot machinery is deliberately unused here — CLAUDE.md §Parallel sessions), so per `/dev:develop` §3.1 the wave's units run one complete Test-Writer→Implementer pair at a time. The wave structure below is an ordering, not a concurrency claim. This is also the cheapest possible dogfood of the feature under construction: the one contended resource in this repo is the `bash scripts/lint-conventions.sh` gate itself, and serialize-by-default is what the rule prescribes when claims cannot be made disjoint. **Wave 2 is a real barrier.** WU-43-3-4's checks assert the shape the first three units produce. A check authored before its target exists fails for the wrong reason and teaches the author to weaken it — so the gate lands last, against real content. **Test Writer disposition.** WU-43-3-1 through WU-43-3-3 are artifact-shape units: every acceptance criterion they carry is an assertion about the text of a skill-markdown file, verified by `code`-domain inspection and — for the load-bearing ones — by WU-43-3-4's mechanical checks. There is no behaviour for a behavioural test to exercise, so those three spawn an Implementer only, per `/dev:develop` §3.2's artifact-shape exception, and each records the skip in its outcome summary. **WU-43-3-4 spawns both**: its acceptance criteria are behavioural (a check must fire on a violation and stay silent on a conforming tree), and this repo has a real harness for exactly that in `scripts/test-lint-conventions.sh`.

jbr870 commented

2026-08-25 11:35:21 +00:00

Author

Owner

{
  "supersedes": "comment:1369",
  "waves": [
    {
      "wave": 1,
      "work_units": [
        {
          "id": "WU-43-3-1",
          "title": "The mechanical gate, authored blind — checks + harness cases from the AC text alone",
          "files": [
            "scripts/lint-conventions.sh",
            "scripts/test-lint-conventions.sh"
          ],
          "acceptance_criteria": [
            {"id": "AC-5", "scope": "mechanical: no new required item in readiness-check.md; the doc declares the no-declaration default"},
            {"id": "AC-6", "scope": "mechanical: no new mandatory declaration block"},
            {"id": "AC-14", "scope": "mechanical: the normative sentences live in exactly one file and both consumers cite it by path"},
            {"id": "AC-15", "scope": "mechanical: the new doc carries a reference, not derivation rules"},
            {"id": "AC-16", "scope": "mechanical: run-resource-claims.md and test-plan.v1.md each cross-reference the other"}
          ]
        }
      ]
    },
    {
      "wave": 2,
      "work_units": [
        {
          "id": "WU-43-3-2",
          "title": "The canonical rule and its record shapes",
          "files": [
            "plugin/skills/_shared/procedures/run-resource-claims.md",
            "plugin/skills/_shared/procedures/journal-template.md"
          ],
          "acceptance_criteria": [
            {"id": "AC-1", "scope": "the serialize-default rule is stated here"},
            {"id": "AC-2", "scope": "the claim block shape and its fixed keys"},
            {"id": "AC-3"},
            {"id": "AC-4", "scope": "remedy is a required DISPATCH key"},
            {"id": "AC-5", "scope": "the doc's no-declaration default"},
            {"id": "AC-6", "scope": "project-named classes via surfaces the project already has"},
            {"id": "AC-7"},
            {"id": "AC-8"},
            {"id": "AC-9", "scope": "DISPATCH/RELEASE entry types, the named journal file, the triage scan recipe"},
            {"id": "AC-10", "scope": "the routing rule as stated in the doc"},
            {"id": "AC-13"},
            {"id": "AC-15"},
            {"id": "AC-16", "scope": "the run-resource-claims side of the cross-reference"}
          ]
        }
      ]
    },
    {
      "wave": 3,
      "work_units": [
        {
          "id": "WU-43-3-3",
          "title": "The six consumer edits — QA playbook, triage, fixer, develop, worktree-discipline, test-plan schema",
          "files": [
            "plugin/skills/_shared/procedures/qa-playbook.md",
            "plugin/skills/_shared/procedures/validate-workflow.md",
            "plugin/skills/_shared/procedures/fix-workflow.md",
            "plugin/skills/develop/SKILL.md",
            "plugin/skills/_shared/procedures/worktree-discipline.md",
            "plugin/skills/_shared/schemas/test-plan.v1.md"
          ],
          "acceptance_criteria": [
            {"id": "AC-1", "scope": "both consumers reference the rule rather than restating it"},
            {"id": "AC-2", "scope": "the spawn-prompt rule in qa-playbook.md and develop/SKILL.md"},
            {"id": "AC-10", "scope": "validate-workflow Step 3 structural classification"},
            {"id": "AC-11"},
            {"id": "AC-12"},
            {"id": "AC-14", "scope": "both halves of the cite-by-path requirement"},
            {"id": "AC-16", "scope": "the test-plan.v1 side of the cross-reference"}
          ]
        }
      ]
    }
  ]
}

Decomposition

Three work units, run strictly in sequence. This supersedes the plan posted as comment 1369, which
had the gate last; the reasoning for the inversion is below and is the substantive part of this plan.

The gate is authored first, and blind

The SREQ's Implementation Scope put scripts/lint-conventions.sh last, on the argument that "a check
written before its target exists fails for the wrong reason." On inspection that argument does not hold,
and the ordering it produces gives up the one piece of test discipline this feature can actually have.

A check asserting "the normative sentence appears in exactly one file" against a tree where it appears
in zero files has failed for precisely the right reason. That is red. Nothing about it is spurious.

What the SREQ's ordering does cost is real. The SREQ names AC-14 and AC-15 as load-bearing and says why:
"the failure mode is one consumer quietly restating the rule instead of referencing it, which reads
correct in isolation and drifts silently." A gate authored after reading the prose it judges is
written to fit that prose — that is the same defect one level up, and it is invisible for the same
reason. Authoring the checks from the acceptance-criteria text alone, before any of the documents exist,
is what makes them an independent assertion rather than a description.

This also restores the 2-phase TDD split, which a documentation feature otherwise forfeits entirely.
There is no behaviour here for a conventional Test Writer to exercise, so the usual answer is to invoke
/dev:develop §3.2's artifact-shape exception and skip the phase. The inversion gives the split back
its meaning: WU-43-3-1 is the test-writer half of this feature, at feature scale rather than unit
scale, and it is context-isolated from the implementation by construction — it is authored before the
implementation exists, not merely by a different agent.

Credit where due: this inversion was worked out by the session that paused this run at 3.1 and recorded
it in PAUSED.md. It is adopted here on its merits.

Why three units rather than that note's two

PAUSED.md proposed the gate plus a single unit carrying all eight documentation files. The argument for
inverting is sound; the sizing is not. Eight files — a new canonical document of a few hundred lines, plus
edits into qa-playbook.md (514 lines) and develop/SKILL.md (695 lines) — is a large amount of reading
and authoring for one context window, and quality degrades at the end of a full one. The documentation
is therefore split at its natural seam:

WU-43-3-2 writes the rule itself and the record shapes it depends on. These two files are one
design: the SREQ specifies the DISPATCH/RELEASE YAML and the lifecycle prose that describes it, and
they must agree field-for-field. Two authors working from the same spec independently is exactly how
that agreement drifts.
WU-43-3-3 makes the six consumer edits. All six are citation-shaped — a precondition pointer, a
spawn-prompt rule, a triage rule, a withdrawal rule, a cross-reference, a disambiguating line — and
they share a single concern: cite the canonical document, restate nothing from it. One author holding
that concern across all six is more likely to keep AC-14 honest than three authors holding it once each.

No unit shares a file with any other, so the boundaries stay clean whether or not execution is parallel.

Execution is sequential, and the red baseline is briefed explicitly

This project runs on a single shared worktree — the slot machinery is deliberately unused here
(CLAUDE.md §Parallel sessions) — so per /dev:develop §3.1 the units run one at a time regardless of
wave structure. The waves above are an ordering.

That has one consequence worth stating rather than discovering: the gate is red from the end of
WU-43-3-1 until the end of WU-43-3-3, which is the point of writing it first. The Implementer
verification bar ("linter clean, full suite green") therefore cannot apply unchanged to the middle unit.
Each brief carries its known-red baseline explicitly:

Unit	Bar at completion
WU-43-3-1	`bash scripts/lint-conventions.sh` fails only on the new checks, and `bash scripts/test-lint-conventions.sh` proves each new check fires on a violation and stays silent on a conforming tree. Every pre-existing check still passes.
WU-43-3-2	The checks judging `run-resource-claims.md` and `journal-template.md` pass. The citation checks are still red — that is the recorded baseline, not a regression.
WU-43-3-3	`bash scripts/lint-conventions.sh` is fully green. No exceptions, no documented-red remainder.

This run is subject to the rule it is building

The feature's subject is that concurrent actors sharing a resource must declare and honour ownership, and
serialize when they cannot. The one contended resource in this repo is the lint-conventions.sh gate
itself, and three sequential units with a single writer each is what the rule prescribes. The SREQ
anticipated this ("this feature's own development is subject to the rule it describes"); the sequencing
above is that dogfood, not a coincidence.

Test Writer disposition

No conventional Test Writer is spawned in this run, and the reason differs per unit:

WU-43-3-1 is the test-writing phase — that is the whole inversion. It writes both the gate and
the harness cases proving the gate fires. A Test Writer for it would be a test of a test.
WU-43-3-2 and WU-43-3-3 are artifact-shape units under /dev:develop §3.2: every criterion
they carry is an assertion about the text of a skill-markdown file, verified by code-domain
inspection and by WU-43-3-1's checks. There is no behaviour to exercise.

Each unit records this in its outcome summary, per the exception's logging requirement.

```json { "supersedes": "comment:1369", "waves": [ { "wave": 1, "work_units": [ { "id": "WU-43-3-1", "title": "The mechanical gate, authored blind — checks + harness cases from the AC text alone", "files": [ "scripts/lint-conventions.sh", "scripts/test-lint-conventions.sh" ], "acceptance_criteria": [ {"id": "AC-5", "scope": "mechanical: no new required item in readiness-check.md; the doc declares the no-declaration default"}, {"id": "AC-6", "scope": "mechanical: no new mandatory declaration block"}, {"id": "AC-14", "scope": "mechanical: the normative sentences live in exactly one file and both consumers cite it by path"}, {"id": "AC-15", "scope": "mechanical: the new doc carries a reference, not derivation rules"}, {"id": "AC-16", "scope": "mechanical: run-resource-claims.md and test-plan.v1.md each cross-reference the other"} ] } ] }, { "wave": 2, "work_units": [ { "id": "WU-43-3-2", "title": "The canonical rule and its record shapes", "files": [ "plugin/skills/_shared/procedures/run-resource-claims.md", "plugin/skills/_shared/procedures/journal-template.md" ], "acceptance_criteria": [ {"id": "AC-1", "scope": "the serialize-default rule is stated here"}, {"id": "AC-2", "scope": "the claim block shape and its fixed keys"}, {"id": "AC-3"}, {"id": "AC-4", "scope": "remedy is a required DISPATCH key"}, {"id": "AC-5", "scope": "the doc's no-declaration default"}, {"id": "AC-6", "scope": "project-named classes via surfaces the project already has"}, {"id": "AC-7"}, {"id": "AC-8"}, {"id": "AC-9", "scope": "DISPATCH/RELEASE entry types, the named journal file, the triage scan recipe"}, {"id": "AC-10", "scope": "the routing rule as stated in the doc"}, {"id": "AC-13"}, {"id": "AC-15"}, {"id": "AC-16", "scope": "the run-resource-claims side of the cross-reference"} ] } ] }, { "wave": 3, "work_units": [ { "id": "WU-43-3-3", "title": "The six consumer edits — QA playbook, triage, fixer, develop, worktree-discipline, test-plan schema", "files": [ "plugin/skills/_shared/procedures/qa-playbook.md", "plugin/skills/_shared/procedures/validate-workflow.md", "plugin/skills/_shared/procedures/fix-workflow.md", "plugin/skills/develop/SKILL.md", "plugin/skills/_shared/procedures/worktree-discipline.md", "plugin/skills/_shared/schemas/test-plan.v1.md" ], "acceptance_criteria": [ {"id": "AC-1", "scope": "both consumers reference the rule rather than restating it"}, {"id": "AC-2", "scope": "the spawn-prompt rule in qa-playbook.md and develop/SKILL.md"}, {"id": "AC-10", "scope": "validate-workflow Step 3 structural classification"}, {"id": "AC-11"}, {"id": "AC-12"}, {"id": "AC-14", "scope": "both halves of the cite-by-path requirement"}, {"id": "AC-16", "scope": "the test-plan.v1 side of the cross-reference"} ] } ] } ] } ``` ## Decomposition Three work units, run strictly in sequence. **This supersedes the plan posted as comment 1369**, which had the gate last; the reasoning for the inversion is below and is the substantive part of this plan. ### The gate is authored first, and blind The SREQ's Implementation Scope put `scripts/lint-conventions.sh` last, on the argument that "a check written before its target exists fails for the wrong reason." On inspection that argument does not hold, and the ordering it produces gives up the one piece of test discipline this feature can actually have. A check asserting *"the normative sentence appears in exactly one file"* against a tree where it appears in **zero** files has failed for precisely the right reason. That is red. Nothing about it is spurious. What the SREQ's ordering does cost is real. The SREQ names AC-14 and AC-15 as load-bearing and says why: *"the failure mode is one consumer quietly restating the rule instead of referencing it, which reads correct in isolation and drifts silently."* A gate authored **after** reading the prose it judges is written to fit that prose — that is the same defect one level up, and it is invisible for the same reason. Authoring the checks from the acceptance-criteria text alone, before any of the documents exist, is what makes them an independent assertion rather than a description. This also restores the 2-phase TDD split, which a documentation feature otherwise forfeits entirely. There is no behaviour here for a conventional Test Writer to exercise, so the usual answer is to invoke `/dev:develop` §3.2's artifact-shape exception and skip the phase. The inversion gives the split back its meaning: **WU-43-3-1 is the test-writer half of this feature**, at feature scale rather than unit scale, and it is context-isolated from the implementation by construction — it is authored before the implementation exists, not merely by a different agent. Credit where due: this inversion was worked out by the session that paused this run at 3.1 and recorded it in `PAUSED.md`. It is adopted here on its merits. ### Why three units rather than that note's two `PAUSED.md` proposed the gate plus a single unit carrying all eight documentation files. The argument for inverting is sound; the sizing is not. Eight files — a new canonical document of a few hundred lines, plus edits into `qa-playbook.md` (514 lines) and `develop/SKILL.md` (695 lines) — is a large amount of reading and authoring for one context window, and quality degrades at the end of a full one. The documentation is therefore split at its natural seam: - **WU-43-3-2** writes the rule itself and the record shapes it depends on. These two files are one design: the SREQ specifies the `DISPATCH`/`RELEASE` YAML and the lifecycle prose that describes it, and they must agree field-for-field. Two authors working from the same spec independently is exactly how that agreement drifts. - **WU-43-3-3** makes the six consumer edits. All six are citation-shaped — a precondition pointer, a spawn-prompt rule, a triage rule, a withdrawal rule, a cross-reference, a disambiguating line — and they share a single concern: cite the canonical document, restate nothing from it. One author holding that concern across all six is more likely to keep AC-14 honest than three authors holding it once each. No unit shares a file with any other, so the boundaries stay clean whether or not execution is parallel. ### Execution is sequential, and the red baseline is briefed explicitly This project runs on a single shared worktree — the slot machinery is deliberately unused here (CLAUDE.md §Parallel sessions) — so per `/dev:develop` §3.1 the units run one at a time regardless of wave structure. The waves above are an ordering. That has one consequence worth stating rather than discovering: **the gate is red from the end of WU-43-3-1 until the end of WU-43-3-3**, which is the point of writing it first. The Implementer verification bar ("linter clean, full suite green") therefore cannot apply unchanged to the middle unit. Each brief carries its known-red baseline explicitly: | Unit | Bar at completion | |---|---| | WU-43-3-1 | `bash scripts/lint-conventions.sh` fails **only** on the new checks, and `bash scripts/test-lint-conventions.sh` proves each new check fires on a violation and stays silent on a conforming tree. Every pre-existing check still passes. | | WU-43-3-2 | The checks judging `run-resource-claims.md` and `journal-template.md` pass. The citation checks are still red — that is the recorded baseline, not a regression. | | WU-43-3-3 | `bash scripts/lint-conventions.sh` is **fully green**. No exceptions, no documented-red remainder. | ### This run is subject to the rule it is building The feature's subject is that concurrent actors sharing a resource must declare and honour ownership, and serialize when they cannot. The one contended resource in this repo is the `lint-conventions.sh` gate itself, and three sequential units with a single writer each is what the rule prescribes. The SREQ anticipated this ("this feature's own development is subject to the rule it describes"); the sequencing above is that dogfood, not a coincidence. ### Test Writer disposition No conventional Test Writer is spawned in this run, and the reason differs per unit: - **WU-43-3-1** *is* the test-writing phase — that is the whole inversion. It writes both the gate and the harness cases proving the gate fires. A Test Writer for it would be a test of a test. - **WU-43-3-2** and **WU-43-3-3** are artifact-shape units under `/dev:develop` §3.2: every criterion they carry is an assertion about the text of a skill-markdown file, verified by `code`-domain inspection and by WU-43-3-1's checks. There is no behaviour to exercise. Each unit records this in its outcome summary, per the exception's logging requirement.

jbr870 commented

2026-08-25 12:09:55 +00:00

Author

Owner

Development journal — WU-43-3-1 (mechanical gate for the run-resource-claims contract)

Files owned: scripts/lint-conventions.sh, scripts/test-lint-conventions.sh.
Authored blind: the documents this gate judges did not exist while it was written.

[2026-08-25] DISCOVERY: the anchors every other work unit must honour

where: scripts/lint-conventions.sh, section "Run-resource-claims contract (#43)"
claude_md_gap: none — this is the contract direction the brief asked for
(the gate names the shape; the prose conforms to it).

This is the mandatory entry. WU-43-3-2 and WU-43-3-3 must honour every item below
verbatim, or the gate stays red against correct-looking prose.

1. The canonical document

Exact path, nothing else will satisfy the gate:

plugin/skills/_shared/procedures/run-resource-claims.md

2. The six normative anchors

Each of these six literal fragments must appear in run-resource-claims.md, and
must not appear in any other *.md under plugin/skills/ or .claude/skills/.

#	Anchor (exact substring)
1	`serialize by default`
2	`an absent key means unknown`
3	`non-empty set intersection`
4	`sum of concurrently-claimed workers`
5	`a project that declares nothing`
6	`no new mandatory block`

Matching rules — these are the things that actually bite:

Case-insensitive (grep -iF), so sentence-initial capitals are fine:
"An absent key means unknown…" satisfies anchor 2.
Literal substring, so the surrounding sentence is the author's to write. Only the
fragment is fixed.
Each anchor must sit on ONE line. A fragment wrapped across a line break reads as
absent. This is the single most likely way to fail this gate by accident — an editor
reflowing a paragraph at 100 columns will silently break anchor 4, which is 36
characters long and easy to land on a wrap point.
The scan covers both skills roots and all markdown, prose and fences alike. A
fenced example that restates the rule is a restatement just the same.

Zero pre-existing occurrences of any anchor exist in the tree today (verified before
choosing them), so the uniqueness half is currently green and only a new restatement
can turn it red.

3. The two AC-14 consumers must cite by path

These two files must each contain this exact string:

${CLAUDE_PLUGIN_ROOT}/skills/_shared/procedures/run-resource-claims.md

plugin/skills/_shared/procedures/qa-playbook.md
plugin/skills/develop/SKILL.md

The match is a plain substring, so the quoted in-fence spelling
("${CLAUDE_PLUGIN_ROOT}/…/run-resource-claims.md") and the bare prose spelling in
backticks both satisfy it. The ${CLAUDE_PLUGIN_ROOT}/skills/ prefix is not optional
— tier 3's class-2 rule already requires it for every _shared/ reference in shipped
markdown, so this anchor is forced by an existing rule rather than invented here.

Only these two are required to cite. validate-workflow.md, fix-workflow.md and
worktree-discipline.md are free to cite as well (and should), but the gate does not
require it — AC-14 names only the QA playbook and /dev:develop. What the gate does
enforce on them is anchor uniqueness: they may reference the rule, never restate it.

4. AC-15 — `run-resource-claims.md` defers, never derives

Must contain both:

the literal ${CLAUDE_PLUGIN_ROOT}/skills/_shared/procedures/slot-isolation.md
the literal §7.2 (the section sign, not "section 7.2")

Must NOT contain any of (this is the derivation ban, matched as an ERE against the
whole file):

derived_suffixes
SLOT_PORT_BASE, SLOT_PORT_BLOCK, SLOT_PORT_END
base_port / base port / Base Port / BASE_PORT
PORT_OFFSET, SLOT_OFFSET, port offset / Port offset
slot arithmetic in either direction: slot… * N / slot… + N, or N * slot / N + slot

Explicitly still legal, because naming a value source is not restating a derivation:
SLOT_DB, SLOT_DB_<SUFFIX>, .slot.env, and a port-range literal such as "4080-4089".
The SREQ's own vocabulary table uses all four; the conforming fixture in the harness
carries all four precisely so a future edit cannot tighten the ban onto them without a
scenario going red.

5. AC-16 — the cross-reference is mutual

run-resource-claims.md must contain
${CLAUDE_PLUGIN_ROOT}/skills/_shared/schemas/test-plan.v1.md
plugin/skills/_shared/schemas/test-plan.v1.md must contain
${CLAUDE_PLUGIN_ROOT}/skills/_shared/procedures/run-resource-claims.md

6. AC-4 / AC-7 / AC-9 — the record shapes in `journal-template.md`

Added after the lead's follow-up brief (see the second STRUGGLE entry). Target file:
plugin/skills/_shared/procedures/journal-template.md.

Matched CASE-SENSITIVELY, unlike the six prose anchors above — these are YAML keys
and values, which are literal. It matters: the file already says "the YAML dispatch
(type: complete…)" in prose at line 98, so a case-insensitive DISPATCH would pass on
text that defines nothing.

Gate tokens — the entry types (AC-9), which also gate everything below:

type: dispatch
type: release

If either is absent the gate reports one finding and suppresses the rest — same
suppression pattern as the canonical document.

Discriminating keys — each must appear once both entry types are defined:

Token	Why this one
`claims:`	DISPATCH shape
`concurrent_with:`	DISPATCH shape
`remedy:`	AC-4 — required DISPATCH key
`distinct-resources`	AC-4 — proves the `none / serialized / distinct-resources` enumeration was written, without gating a whitespace-fragile `a \| b \| c` string
`ended_by:`	RELEASE shape
`overran_claim:`	RELEASE shape
`death-check`	AC-7 — positive half

type:, timestamp: and actor: are deliberately not gated: the file's existing
entry types already carry them, so requiring them would pass no matter what.
waited_ms: is not gated either — the SREQ marks it optional.

The driver journal's named home (AC-9) — must appear verbatim, $FEATURE_FOLDER
prefix included:

$FEATURE_FOLDER/dispatch-journal.md

AC-7's negative half: no line containing ended_by: may also contain timeout,
elapsed, or silence. A silent actor is released only on a positive death check;
one word in an enumeration would undo that.

Uniqueness is deliberately NOT asserted for any of these tokens, unlike the six
prose anchors. run-resource-claims.md legitimately names overran_claim (an actor
that used a resource beyond its claim voids its own result) and claims: (the block a
dispatched brief carries), so a "stated once" rule would fire on correct prose. What is
asserted is that the shape is defined in journal-template.md — that is the only file
the keys are required to appear in.

7. AC-5 / AC-6 — what must NOT be added

These two files must contain none of run-resource-claims, run_resource_claims,
resource claim(s) / resource_claim(s) / resource-claim(s), or a claims: key:

plugin/skills/_shared/procedures/readiness-check.md
plugin/skills/setup/SKILL.md

i.e. do not mention this feature on a readiness or setup surface at all. A project
that declares nothing still gets the four suite-owned classes, so its silence must never
surface as a gap or a prompt. (The English word "claiming" is fine — the ban on claims:
requires the colon. setup/SKILL.md line 273 already says "migrate work by claiming",
and the harness pins that it stays legal.)

And nowhere in plugin/skills/**/*.md may a run_resource_claims: or resource_claims:
declaration block appear.

[2026-08-25] DISCOVERY: what the SREQ left to me, and what I chose

where: the AC table's "Mechanical" rows
claude_md_gap: none

The SREQ says AC-14's check asserts "the normative sentences appear in exactly one file"
but never says which sentences. That is the whole judgement call in this unit, and there
was no way to look it up without reading the prose I am supposed to be judging
independently. What I chose, and why:

Definitional, not operational. Every anchor states what something is
(the default, the meaning of an absent key, the two overlap tests, the
no-declaration default, the no-new-block guarantee). None states what an actor
does. That distinction is load-bearing: a consumer legitimately has to write
operational sentences — "a void result is re-run under sole ownership before
classification, see " — and a gate that banned those everywhere would force
WU-43-3-3 to write unreadable prose or to weaken the gate. Banning the definitions
costs a consumer nothing, because a consumer has no reason to define anything.
Six, not two and not twenty. Each of AC-1/AC-3/the two overlap kinds/AC-5/AC-6
gets exactly one anchor. Fewer would leave a rule restateable without tripping
anything; more would turn conformance into a copying exercise.
claims: itself is deliberately NOT an anchor. Both consumers must emit a
claims block in a dispatched brief, so the token legitimately appears in their text.

Also underspecified: AC-6's "no new mandatory block" has no mechanical definition
anywhere. I read it as two assertions — nothing about this feature appears on a
readiness/setup surface (where a requirement would have to land to take effect), and no
run_resource_claims:/resource_claims: block appears anywhere in the shipped tree.

~~Not covered by this gate, deliberately~~ — SUPERSEDED. AC-4 and AC-9 were
originally out of scope: the brief assigned this unit AC-5/6/14/15/16 only, and
inventing anchors for WU-43-3-2's file without a brief to carry them would have been an
unhonoured contract. The lead's follow-up brief closed that gap (it was a brief omission,
not a scope decision) and asked for them, plus AC-7, while the blind property still held.
They are now gated — see §6 of the anchors entry. AC-7 was offered as optional and I
took it: ended_by admitting no timeout is one line to check and is the load-bearing
half of "elapsed silence never releases a claim".

[2026-08-25] DISCOVERY: the fence tracker is the wrong tool for these rules

where: scripts/lint-conventions.sh, the contract section's header comment
claude_md_gap: none — CLAUDE.md's rule is about scans whose meaning changes by
context, and it says so ("Rules differ by context")

The brief said to reuse the fence tracker rather than line-regex skill markdown. I did
not, and the reason is written into the code so a reviewer meets it before the checks.
The tier-1 $scratch extraction yields shell-fence bodies only. Every rule in this
section is prose-level — does this document cite that one; does this sentence live in
exactly one file — and running them over $scratch would restrict them to looking
inside shell fences, which is the exact opposite of what they need.

The concern the CLAUDE.md rule protects against does not arise here, and that is not an
accident of the checks — it is a property they were designed to have:

The one rule that genuinely differs by context is D12's ${CLAUDE_PLUGIN_ROOT}
quoting (double-quoted in a fence, bare in prose). Every citation check here matches
the path as a substring, which both spellings contain, so there is nothing to
disambiguate.
The anchor-uniqueness rule has the same meaning in both contexts on purpose: a fenced
example that restates the rule is a restatement.

If a future check in this section ever does depend on quoting or on command position,
it must switch to $scratch — the tracker is right there and the tier-1 checks show how.

[2026-08-25] STRUGGLE: the harness asserted the very thing this unit had to break

attempts: 2

scenario_control_clean_tree (scenario 2, from #57's QA) runs the real
lint-conventions.sh against the real repo and requires exit 0. This unit's entire
purpose is to make that exit 1. Two options:

Loosen it to "no unexpected violations" permanently. Cheap, but it permanently
retires the strictest assertion in the suite to buy a few days of in-flight red.
Loosen it conditionally, keyed on the thing that makes the red legitimate.

Took 2. The scenario now accepts a non-zero exit only while
plugin/skills/_shared/procedures/run-resource-claims.md does not exist, and even
then only if every violation line mentions run-resource-claims — any other check going
red still fails the suite, which is what this scenario was actually protecting. The
moment WU-43-3-3 lands the document, the strict rc == 0 branch takes over again with no
edit. Nobody has to remember to tighten it back. That property is why option 2 was
worth the extra branch.

This is also the trick that let the whole unit satisfy its verification bar: lint is red
by design, and the harness is green, at the same time, without either one lying.

[2026-08-25] DISCOVERY: `scripts/test-plugin-gates.sh` goes red too, and it is not mine

where: scripts/test-plugin-gates.sh — outside this work unit's file boundary
claude_md_gap: none

The number is 6 FAIL / 11 PASS out of 17. I first reported 3, and the lead caught it.
Both measurements were real; the difference is when they were taken, and that turns out
to be the useful part of this entry.

Baseline, with the original lint-conventions.sh restored: 17 PASS / 0 FAIL.
With this unit's version committed: 11 passed, 6 failed, 0 skipped, 17 total.

Scenario	Why it fails
`lint_nonvacuity_on_real_tree`	"exited 1 on the real, committed tree"
`scenario_24_scan_negative_controls`	"post-cleanup scan not clean (rc=1)"
`scenario_34_class1_outside_markdown`	"lint copy was not clean before seeding (rc=1)"
`positive_control_release_dry_run`	reaches `release: gate 1/4 — scripts/lint-conventions.sh` and stops
`scenario_28_release_bump_path`	same — bumps 0.2.0 → 0.99.0, then dies at gate 1/4
`scenario_29_release_first_run_not_resume`	same

The release chain matters more than the count. scripts/release.sh runs
lint-conventions.sh as gate 1/4 (release.sh:182-185) before it will tag anything, so
a red lint blocks releasing outright. /dev:promote is blocked until the contract lands,
not merely three harness scenarios.

Why I measured 3, and it is not flakiness. Those three release scenarios operate on a
clone, so they see HEAD, not the working tree. My first run was taken before I
committed: the clone carried the old, clean lint script and all three passed. The lead's
run and my re-measurement were taken after the commit, so the clone carries the red
lint and all three reach gate 1/4. There is a second contributing refusal in the same
direction — release.sh's Refusal 1: dirty tree (release.sh:96-100) fires before the
gates, so a dirty tree short-circuits ahead of lint either way. Neither is order- nor
state-dependent: run this suite against a committed tree or the numbers lie. That is
the lesson worth keeping.

This is the same in-flight red as scenario 2, in a file this unit may not touch. It should
clear itself when the documents land — those scenarios' clones come from the real tree, so
a conforming tree makes conforming clones. It needs a re-run after WU-43-3-3, not a
fix, and the baseline to compare against is 17 PASS / 0 FAIL. If anything is still
red then, the cause is real.

Left as-is deliberately rather than reaching outside the assigned file boundary.

[2026-08-25] COMPLETE: WU-43-3-1

variant: development
iterations: 2 (the first commit covered AC-5/6/14/15/16; the second added AC-4/7/9 on the
lead's follow-up brief. Each was green on its first full run; the eight mutation runs were
verification, not repair — the one genuine repair was a fixture bug, see below)

What landed

scripts/lint-conventions.sh gains one section, "Run-resource-claims contract (#43)",
placed after the route-through scan and before the tally, plus a paragraph in the file
header. Sixteen checks and one non-vacuity guard, all reporting messages that contain the
literal run-resource-claims so the in-flight allowance can filter on them.

scripts/test-lint-conventions.sh gains seventeen scenarios (5-21), a conforming-fixture
builder covering all six target files, and the conditional rewrite of scenario 2.

The one real repair: scenario_rrc_ac4_remedy_key_absent first broke its fixture with
grep -v 'remedy:', which deleted the whole line and took distinct-resources with it —
two keys missing for one intended edit, and the count assertion caught it. Changed to
sed 's/remedy:/reason:/', which is also the likelier real-world drift: the enumeration
survives, the key does not. The count assertion is what found this — rrc_expect
alone would have passed on a fixture that was testing something other than what it said.

Current red set — 5 violations, all expected

run-resource-claims.md:1  canonical run-resource-claims.md is missing
qa-playbook.md:1          consumer does not cite run-resource-claims.md by path
develop/SKILL.md:1        consumer does not cite run-resource-claims.md by path
test-plan.v1.md:1         test-plan.v1.md does not cross-reference run-resource-claims.md
journal-template.md:1     does not define both the DISPATCH and the RELEASE entry types

No pre-existing check newly fails (baseline was lint-conventions: clean). The AC-5/AC-6
guards and the anchor-uniqueness rule are green today, correctly — they assert an absence
that currently holds. The per-anchor and per-content rules are suppressed while the
document is missing, so one absent file is one finding rather than ten.

Hardest part

Choosing the anchors without reading the prose. Everything else in this unit is
mechanical; that one decision is the unit. The temptation is to pick phrases that are
easy to grep, which produces a gate that is easy to satisfy and catches nothing. The
discipline that helped was asking, for each candidate: would a consumer that
legitimately references the rule ever need to write this sentence? If yes, it is
operational and cannot be an anchor. If no, it is definitional and belongs to the
canonical document alone.

If I did this again

I would mutation-test earlier. Twenty-one scenarios passing on the first run is not
evidence that they discriminate — it is equally consistent with assertions that can
never fail. Eight targeted mutations settled it, each caught by exactly the scenario that
should have caught it and by no other:

Mutation	Caught by
neuter the anchor-presence test	`rrc_anchor_absent_from_canonical_doc`
neuter the derivation regex	`rrc_ac15_derivation_restated`
drop the canonical-file exclusion from the uniqueness scan	`rrc_conforming_tree_is_silent`
neuter the declaration-surface regex	`rrc_ac5_readiness_gains_required_item`
neuter the record-key loop	`rrc_ac4_remedy_key_absent`, `rrc_ac7_death_check_value_absent`
neuter the `ended_by` timeout ban	`rrc_ac7_timeout_based_release`
neuter the driver-journal-name check	`rrc_ac9_driver_journal_unnamed`
break the entry-types suppression guard	`rrc_ac9_entry_types_undefined`

That took about ten minutes total and is the only reason I would sign off on a suite whose
first run was all-green. Run it before believing the greens, not after.

The second thing I would do differently: commit before measuring anything that clones
the repo. My test-plugin-gates.sh count was wrong by half because three of its
scenarios clone HEAD and I measured with my changes still uncommitted. The run was honest
and the number was still wrong — "which tree did this actually read?" is a question worth
asking of every harness before quoting its output.

# Development journal — WU-43-3-1 (mechanical gate for the run-resource-claims contract) Files owned: `scripts/lint-conventions.sh`, `scripts/test-lint-conventions.sh`. Authored blind: the documents this gate judges did not exist while it was written. --- ## [2026-08-25] DISCOVERY: the anchors every other work unit must honour **where:** `scripts/lint-conventions.sh`, section "Run-resource-claims contract (#43)" **claude_md_gap:** none — this is the contract direction the brief asked for (the gate names the shape; the prose conforms to it). This is the mandatory entry. **WU-43-3-2 and WU-43-3-3 must honour every item below verbatim, or the gate stays red against correct-looking prose.** ### 1. The canonical document Exact path, nothing else will satisfy the gate: ``` plugin/skills/_shared/procedures/run-resource-claims.md ``` ### 2. The six normative anchors Each of these six literal fragments **must appear in `run-resource-claims.md`**, and **must not appear in any other `*.md` under `plugin/skills/` or `.claude/skills/`.** | # | Anchor (exact substring) | | --- | --- | | 1 | `serialize by default` | | 2 | `an absent key means unknown` | | 3 | `non-empty set intersection` | | 4 | `sum of concurrently-claimed workers` | | 5 | `a project that declares nothing` | | 6 | `no new mandatory block` | Matching rules — these are the things that actually bite: - **Case-insensitive** (`grep -iF`), so sentence-initial capitals are fine: "An absent key means unknown…" satisfies anchor 2. - **Literal substring**, so the surrounding sentence is the author's to write. Only the fragment is fixed. - **Each anchor must sit on ONE line.** A fragment wrapped across a line break reads as absent. This is the single most likely way to fail this gate by accident — an editor reflowing a paragraph at 100 columns will silently break anchor 4, which is 36 characters long and easy to land on a wrap point. - The scan covers **both** skills roots and **all** markdown, prose and fences alike. A fenced example that restates the rule is a restatement just the same. Zero pre-existing occurrences of any anchor exist in the tree today (verified before choosing them), so the uniqueness half is currently green and only a new restatement can turn it red. ### 3. The two AC-14 consumers must cite by path These two files must each contain this exact string: ``` ${CLAUDE_PLUGIN_ROOT}/skills/_shared/procedures/run-resource-claims.md ``` - `plugin/skills/_shared/procedures/qa-playbook.md` - `plugin/skills/develop/SKILL.md` The match is a plain substring, so the quoted in-fence spelling (`"${CLAUDE_PLUGIN_ROOT}/…/run-resource-claims.md"`) and the bare prose spelling in backticks both satisfy it. The `${CLAUDE_PLUGIN_ROOT}/skills/` prefix is **not optional** — tier 3's class-2 rule already requires it for every `_shared/` reference in shipped markdown, so this anchor is forced by an existing rule rather than invented here. **Only these two are required to cite.** `validate-workflow.md`, `fix-workflow.md` and `worktree-discipline.md` are free to cite as well (and should), but the gate does not require it — AC-14 names only the QA playbook and `/dev:develop`. What the gate *does* enforce on them is anchor uniqueness: they may reference the rule, never restate it. ### 4. AC-15 — `run-resource-claims.md` defers, never derives **Must contain both:** - the literal `${CLAUDE_PLUGIN_ROOT}/skills/_shared/procedures/slot-isolation.md` - the literal `§7.2` (the section sign, not "section 7.2") **Must NOT contain any of** (this is the derivation ban, matched as an ERE against the whole file): - `derived_suffixes` - `SLOT_PORT_BASE`, `SLOT_PORT_BLOCK`, `SLOT_PORT_END` - `base_port` / `base port` / `Base Port` / `BASE_PORT` - `PORT_OFFSET`, `SLOT_OFFSET`, `port offset` / `Port offset` - slot arithmetic in either direction: `slot… * N` / `slot… + N`, or `N * slot` / `N + slot` **Explicitly still legal**, because naming a value source is not restating a derivation: `SLOT_DB`, `SLOT_DB_<SUFFIX>`, `.slot.env`, and a port-range literal such as `"4080-4089"`. The SREQ's own vocabulary table uses all four; the conforming fixture in the harness carries all four precisely so a future edit cannot tighten the ban onto them without a scenario going red. ### 5. AC-16 — the cross-reference is mutual - `run-resource-claims.md` must contain `${CLAUDE_PLUGIN_ROOT}/skills/_shared/schemas/test-plan.v1.md` - `plugin/skills/_shared/schemas/test-plan.v1.md` must contain `${CLAUDE_PLUGIN_ROOT}/skills/_shared/procedures/run-resource-claims.md` ### 6. AC-4 / AC-7 / AC-9 — the record shapes in `journal-template.md` Added after the lead's follow-up brief (see the second STRUGGLE entry). Target file: `plugin/skills/_shared/procedures/journal-template.md`. **Matched CASE-SENSITIVELY**, unlike the six prose anchors above — these are YAML keys and values, which are literal. It matters: the file already says "the YAML dispatch (`type: complete`…)" in prose at line 98, so a case-insensitive `DISPATCH` would pass on text that defines nothing. **Gate tokens — the entry types (AC-9), which also gate everything below:** - `type: dispatch` - `type: release` If either is absent the gate reports **one** finding and suppresses the rest — same suppression pattern as the canonical document. **Discriminating keys — each must appear once both entry types are defined:** | Token | Why this one | | --- | --- | | `claims:` | DISPATCH shape | | `concurrent_with:` | DISPATCH shape | | `remedy:` | **AC-4** — required DISPATCH key | | `distinct-resources` | AC-4 — proves the `none / serialized / distinct-resources` enumeration was written, without gating a whitespace-fragile `a \| b \| c` string | | `ended_by:` | RELEASE shape | | `overran_claim:` | RELEASE shape | | `death-check` | **AC-7** — positive half | `type:`, `timestamp:` and `actor:` are deliberately **not** gated: the file's existing entry types already carry them, so requiring them would pass no matter what. `waited_ms:` is not gated either — the SREQ marks it optional. **The driver journal's named home (AC-9)** — must appear verbatim, `$FEATURE_FOLDER` prefix included: ``` $FEATURE_FOLDER/dispatch-journal.md ``` **AC-7's negative half:** no line containing `ended_by:` may also contain `timeout`, `elapsed`, or `silence`. A silent actor is released only on a positive death check; one word in an enumeration would undo that. **Uniqueness is deliberately NOT asserted for any of these tokens**, unlike the six prose anchors. `run-resource-claims.md` legitimately names `overran_claim` (an actor that used a resource beyond its claim voids its own result) and `claims:` (the block a dispatched brief carries), so a "stated once" rule would fire on correct prose. What is asserted is that the *shape* is defined in `journal-template.md` — that is the only file the keys are required to appear in. ### 7. AC-5 / AC-6 — what must NOT be added These two files must contain **none** of `run-resource-claims`, `run_resource_claims`, `resource claim(s)` / `resource_claim(s)` / `resource-claim(s)`, or a `claims:` key: - `plugin/skills/_shared/procedures/readiness-check.md` - `plugin/skills/setup/SKILL.md` i.e. **do not mention this feature on a readiness or setup surface at all.** A project that declares nothing still gets the four suite-owned classes, so its silence must never surface as a gap or a prompt. (The English word "claiming" is fine — the ban on `claims:` requires the colon. `setup/SKILL.md` line 273 already says "migrate work by claiming", and the harness pins that it stays legal.) And nowhere in `plugin/skills/**/*.md` may a `run_resource_claims:` or `resource_claims:` declaration block appear. --- ## [2026-08-25] DISCOVERY: what the SREQ left to me, and what I chose **where:** the AC table's "Mechanical" rows **claude_md_gap:** none The SREQ says AC-14's check asserts "the normative sentences appear in exactly one file" but never says which sentences. That is the whole judgement call in this unit, and there was no way to look it up without reading the prose I am supposed to be judging independently. What I chose, and why: - **Definitional, not operational.** Every anchor states what something *is* (the default, the meaning of an absent key, the two overlap tests, the no-declaration default, the no-new-block guarantee). None states what an actor *does*. That distinction is load-bearing: a consumer legitimately has to write operational sentences — "a void result is re-run under sole ownership before classification, see <path>" — and a gate that banned those everywhere would force WU-43-3-3 to write unreadable prose or to weaken the gate. Banning the definitions costs a consumer nothing, because a consumer has no reason to define anything. - **Six, not two and not twenty.** Each of AC-1/AC-3/the two overlap kinds/AC-5/AC-6 gets exactly one anchor. Fewer would leave a rule restateable without tripping anything; more would turn conformance into a copying exercise. - **`claims:` itself is deliberately NOT an anchor.** Both consumers must *emit* a claims block in a dispatched brief, so the token legitimately appears in their text. Also underspecified: AC-6's "no new mandatory block" has no mechanical definition anywhere. I read it as two assertions — nothing about this feature appears on a readiness/setup surface (where a requirement would have to land to take effect), and no `run_resource_claims:`/`resource_claims:` block appears anywhere in the shipped tree. **~~Not covered by this gate, deliberately~~ — SUPERSEDED.** AC-4 and AC-9 were originally out of scope: the brief assigned this unit AC-5/6/14/15/16 only, and inventing anchors for WU-43-3-2's file without a brief to carry them would have been an unhonoured contract. The lead's follow-up brief closed that gap (it was a brief omission, not a scope decision) and asked for them, plus AC-7, while the blind property still held. They are now gated — see §6 of the anchors entry. AC-7 was offered as optional and I took it: `ended_by` admitting no timeout is one line to check and is the load-bearing half of "elapsed silence never releases a claim". --- ## [2026-08-25] DISCOVERY: the fence tracker is the wrong tool for these rules **where:** `scripts/lint-conventions.sh`, the contract section's header comment **claude_md_gap:** none — CLAUDE.md's rule is about scans whose *meaning* changes by context, and it says so ("Rules differ by context") The brief said to reuse the fence tracker rather than line-regex skill markdown. I did not, and the reason is written into the code so a reviewer meets it before the checks. The tier-1 `$scratch` extraction yields **shell-fence bodies only**. Every rule in this section is prose-level — does this document cite that one; does this sentence live in exactly one file — and running them over `$scratch` would restrict them to looking *inside shell fences*, which is the exact opposite of what they need. The concern the CLAUDE.md rule protects against does not arise here, and that is not an accident of the checks — it is a property they were designed to have: - The one rule that genuinely differs by context is D12's `${CLAUDE_PLUGIN_ROOT}` quoting (double-quoted in a fence, bare in prose). Every citation check here matches the **path as a substring**, which both spellings contain, so there is nothing to disambiguate. - The anchor-uniqueness rule has the same meaning in both contexts on purpose: a fenced example that restates the rule is a restatement. If a future check in this section ever *does* depend on quoting or on command position, it must switch to `$scratch` — the tracker is right there and the tier-1 checks show how. --- ## [2026-08-25] STRUGGLE: the harness asserted the very thing this unit had to break **attempts:** 2 `scenario_control_clean_tree` (scenario 2, from #57's QA) runs the real `lint-conventions.sh` against the real repo and requires exit 0. This unit's entire purpose is to make that exit 1. Two options: 1. Loosen it to "no unexpected violations" permanently. Cheap, but it permanently retires the strictest assertion in the suite to buy a few days of in-flight red. 2. Loosen it *conditionally*, keyed on the thing that makes the red legitimate. Took 2. The scenario now accepts a non-zero exit **only while `plugin/skills/_shared/procedures/run-resource-claims.md` does not exist**, and even then only if every violation line mentions `run-resource-claims` — any other check going red still fails the suite, which is what this scenario was actually protecting. The moment WU-43-3-3 lands the document, the strict `rc == 0` branch takes over again with no edit. **Nobody has to remember to tighten it back.** That property is why option 2 was worth the extra branch. This is also the trick that let the whole unit satisfy its verification bar: lint is red by design, and the harness is green, at the same time, without either one lying. --- ## [2026-08-25] DISCOVERY: `scripts/test-plugin-gates.sh` goes red too, and it is not mine **where:** `scripts/test-plugin-gates.sh` — outside this work unit's file boundary **claude_md_gap:** none **The number is 6 FAIL / 11 PASS out of 17.** I first reported 3, and the lead caught it. Both measurements were real; the difference is *when* they were taken, and that turns out to be the useful part of this entry. Baseline, with the original `lint-conventions.sh` restored: **17 PASS / 0 FAIL**. With this unit's version committed: **11 passed, 6 failed, 0 skipped, 17 total.** | Scenario | Why it fails | | --- | --- | | `lint_nonvacuity_on_real_tree` | "exited 1 on the real, committed tree" | | `scenario_24_scan_negative_controls` | "post-cleanup scan not clean (rc=1)" | | `scenario_34_class1_outside_markdown` | "lint copy was not clean before seeding (rc=1)" | | `positive_control_release_dry_run` | reaches `release: gate 1/4 — scripts/lint-conventions.sh` and stops | | `scenario_28_release_bump_path` | same — bumps 0.2.0 → 0.99.0, then dies at gate 1/4 | | `scenario_29_release_first_run_not_resume` | same | **The release chain matters more than the count.** `scripts/release.sh` runs `lint-conventions.sh` as **gate 1/4** (release.sh:182-185) before it will tag anything, so a red lint blocks releasing outright. `/dev:promote` is blocked until the contract lands, not merely three harness scenarios. **Why I measured 3, and it is not flakiness.** Those three release scenarios operate on a **clone**, so they see HEAD, not the working tree. My first run was taken *before* I committed: the clone carried the old, clean lint script and all three passed. The lead's run and my re-measurement were taken *after* the commit, so the clone carries the red lint and all three reach gate 1/4. There is a second contributing refusal in the same direction — `release.sh`'s **Refusal 1: dirty tree** (release.sh:96-100) fires before the gates, so a dirty tree short-circuits ahead of lint either way. Neither is order- nor state-dependent: **run this suite against a committed tree or the numbers lie.** That is the lesson worth keeping. This is the same in-flight red as scenario 2, in a file this unit may not touch. It should clear itself when the documents land — those scenarios' clones come from the real tree, so a conforming tree makes conforming clones. **It needs a re-run after WU-43-3-3, not a fix**, and the baseline to compare against is **17 PASS / 0 FAIL**. If anything is still red then, the cause is real. Left as-is deliberately rather than reaching outside the assigned file boundary. --- ## [2026-08-25] COMPLETE: WU-43-3-1 variant: development iterations: 2 (the first commit covered AC-5/6/14/15/16; the second added AC-4/7/9 on the lead's follow-up brief. Each was green on its first full run; the eight mutation runs were verification, not repair — the one genuine repair was a *fixture* bug, see below) **What landed** `scripts/lint-conventions.sh` gains one section, "Run-resource-claims contract (#43)", placed after the route-through scan and before the tally, plus a paragraph in the file header. Sixteen checks and one non-vacuity guard, all reporting messages that contain the literal `run-resource-claims` so the in-flight allowance can filter on them. `scripts/test-lint-conventions.sh` gains seventeen scenarios (5-21), a conforming-fixture builder covering all six target files, and the conditional rewrite of scenario 2. **The one real repair:** `scenario_rrc_ac4_remedy_key_absent` first broke its fixture with `grep -v 'remedy:'`, which deleted the whole line and took `distinct-resources` with it — two keys missing for one intended edit, and the count assertion caught it. Changed to `sed 's/remedy:/reason:/'`, which is also the likelier real-world drift: the enumeration survives, the key does not. **The count assertion is what found this** — `rrc_expect` alone would have passed on a fixture that was testing something other than what it said. **Current red set — 5 violations, all expected** ``` run-resource-claims.md:1 canonical run-resource-claims.md is missing qa-playbook.md:1 consumer does not cite run-resource-claims.md by path develop/SKILL.md:1 consumer does not cite run-resource-claims.md by path test-plan.v1.md:1 test-plan.v1.md does not cross-reference run-resource-claims.md journal-template.md:1 does not define both the DISPATCH and the RELEASE entry types ``` No pre-existing check newly fails (baseline was `lint-conventions: clean`). The AC-5/AC-6 guards and the anchor-uniqueness rule are green today, correctly — they assert an absence that currently holds. The per-anchor and per-content rules are suppressed while the document is missing, so one absent file is one finding rather than ten. **Hardest part** Choosing the anchors without reading the prose. Everything else in this unit is mechanical; that one decision is the unit. The temptation is to pick phrases that are easy to grep, which produces a gate that is easy to satisfy and catches nothing. The discipline that helped was asking, for each candidate: *would a consumer that legitimately references the rule ever need to write this sentence?* If yes, it is operational and cannot be an anchor. If no, it is definitional and belongs to the canonical document alone. **If I did this again** I would mutation-test earlier. Twenty-one scenarios passing on the first run is not evidence that they discriminate — it is equally consistent with assertions that can never fail. Eight targeted mutations settled it, each caught by exactly the scenario that should have caught it and by no other: | Mutation | Caught by | | --- | --- | | neuter the anchor-presence test | `rrc_anchor_absent_from_canonical_doc` | | neuter the derivation regex | `rrc_ac15_derivation_restated` | | drop the canonical-file exclusion from the uniqueness scan | `rrc_conforming_tree_is_silent` | | neuter the declaration-surface regex | `rrc_ac5_readiness_gains_required_item` | | neuter the record-key loop | `rrc_ac4_remedy_key_absent`, `rrc_ac7_death_check_value_absent` | | neuter the `ended_by` timeout ban | `rrc_ac7_timeout_based_release` | | neuter the driver-journal-name check | `rrc_ac9_driver_journal_unnamed` | | break the entry-types suppression guard | `rrc_ac9_entry_types_undefined` | That took about ten minutes total and is the only reason I would sign off on a suite whose first run was all-green. Run it before believing the greens, not after. The second thing I would do differently: **commit before measuring anything that clones the repo.** My `test-plugin-gates.sh` count was wrong by half because three of its scenarios clone HEAD and I measured with my changes still uncommitted. The run was honest and the number was still wrong — "which tree did this actually read?" is a question worth asking of every harness before quoting its output.

jbr870 commented

2026-08-25 12:10:30 +00:00

Author

Owner

{
  "outcome": "complete",
  "summary": "The mechanical gate for the run-resource-claims contract, authored blind from the AC text before any of the documents it judges existed: 18 checks + 2 non-vacuity guards in scripts/lint-conventions.sh, 17 new harness scenarios in scripts/test-lint-conventions.sh. No Test Writer was spawned — under the wu-plan's inversion (comment 1372) this unit IS the test-writing half of the feature, and a Test Writer for it would be a test of a test. Gate is red by design (5 violations, all on absent content) until WU-43-3-3 lands; harness is green at 21 PASS / 0 FAIL.",
  "commit_refs": ["55af016", "3b9a91c"],
  "journal_ref": "1373",
  "dependencies_satisfied": [],
  "dependencies_violated": []
}

Verification, independently re-run by the lead

Not taken from the teammate's report — every number below was re-measured on the committed tree:

Gate	Result
`bash scripts/lint-conventions.sh`	rc 1, 5 violations — all name genuinely-absent content (`run-resource-claims.md` missing; two consumers not yet citing; `test-plan.v1.md` not yet cross-referencing; `journal-template.md` not yet defining the entry types). No pre-existing check newly fails.
`bash scripts/test-lint-conventions.sh`	rc 0, 21 PASS / 0 FAIL (4 pre-existing + 17 new)
`bash -n`, exec bits, file boundary	clean; both files `-rwxrwxr-x`; commits touch these two files only
Non-vacuity	every scan printed a real population (117 helper scripts, 693 fence lines, 202 shipped files, 48 route-through, 83 markdown) — nothing passes by scanning nothing

Eight mutation tests across the two commits: the teammate neutered one part of the gate at a time and confirmed each was caught by exactly the scenario that should catch it, and no other. Sixteen — or twenty-one — green tests on a first run is not evidence a gate discriminates; this is.

One repair inside that process is worth recording as a general lesson: a fixture built with grep -v 'remedy:' deleted the whole line and took a second required key with it, so the scenario was testing something other than what it claimed. The count assertion caught it (expected 1, got 2); a plain did-it-fire check would have passed. Fixtures now mutate with sed 's/remedy:/reason:/', which is also the likelier real-world drift.

Scope correction made during the unit

The unit's original brief scoped it to AC-5/6/14/15/16. The teammate flagged that AC-4, AC-7 and AC-9 are also marked Mechanical in the SREQ and were missing from that list — a gap in the lead's brief, not in the work. It was sent back to close them while journal-template.md's new entries still did not exist, which is the only window in which the blind-authoring property holds. It declined to invent those anchors unbriefed, which was the right call: an anchor no brief carries is an anchor no author honours, and the check would then fail against correct prose.

AC-7 was taken mechanically rather than left to code-domain inspection, on the reasoning that "death-check present, and no ended_by line admitting timeout/elapsed/silence" is two greps and guards the load-bearing half of elapsed silence never releases a claim — a single word added to that enumeration would undo the rule silently.

Carry-forward for cross-unit verification (3.7)

scripts/test-plugin-gates.sh is 11 PASS / 6 FAIL on the committed tree, against a baseline of 17 PASS / 0 FAIL. All six trace to the in-flight red lint; three of them are the release path, because release.sh runs lint-conventions.sh as gate 1/4 — so /dev:promote is blocked until the contract's documents land, which is a wider blast radius than a harness-only failure.

The teammate first reported this as 3 failures; the lead's re-measurement found 6. The mechanism is now understood and is itself a reusable rule: the three release scenarios operate on a clone, so they read HEAD, not the working tree — the first measurement was taken pre-commit, when the clone still carried the clean lint script. Measure this harness against a committed tree or the numbers lie. Not order- or state-dependence.

This needs a re-run after WU-43-3-3, not a fix. If it is still red once the lint is green, the cause is real.

```json { "outcome": "complete", "summary": "The mechanical gate for the run-resource-claims contract, authored blind from the AC text before any of the documents it judges existed: 18 checks + 2 non-vacuity guards in scripts/lint-conventions.sh, 17 new harness scenarios in scripts/test-lint-conventions.sh. No Test Writer was spawned — under the wu-plan's inversion (comment 1372) this unit IS the test-writing half of the feature, and a Test Writer for it would be a test of a test. Gate is red by design (5 violations, all on absent content) until WU-43-3-3 lands; harness is green at 21 PASS / 0 FAIL.", "commit_refs": ["55af016", "3b9a91c"], "journal_ref": "1373", "dependencies_satisfied": [], "dependencies_violated": [] } ``` ## Verification, independently re-run by the lead Not taken from the teammate's report — every number below was re-measured on the committed tree: | Gate | Result | |---|---| | `bash scripts/lint-conventions.sh` | **rc 1, 5 violations** — all name genuinely-absent content (`run-resource-claims.md` missing; two consumers not yet citing; `test-plan.v1.md` not yet cross-referencing; `journal-template.md` not yet defining the entry types). No pre-existing check newly fails. | | `bash scripts/test-lint-conventions.sh` | **rc 0, 21 PASS / 0 FAIL** (4 pre-existing + 17 new) | | `bash -n`, exec bits, file boundary | clean; both files `-rwxrwxr-x`; commits touch these two files only | | Non-vacuity | every scan printed a real population (117 helper scripts, 693 fence lines, 202 shipped files, 48 route-through, 83 markdown) — nothing passes by scanning nothing | **Eight mutation tests** across the two commits: the teammate neutered one part of the gate at a time and confirmed each was caught by exactly the scenario that should catch it, and no other. Sixteen — or twenty-one — green tests on a first run is not evidence a gate discriminates; this is. One repair inside that process is worth recording as a general lesson: a fixture built with `grep -v 'remedy:'` deleted the whole line and took a second required key with it, so the scenario was testing something other than what it claimed. The **count** assertion caught it (`expected 1, got 2`); a plain did-it-fire check would have passed. Fixtures now mutate with `sed 's/remedy:/reason:/'`, which is also the likelier real-world drift. ## Scope correction made during the unit The unit's original brief scoped it to AC-5/6/14/15/16. The teammate flagged that **AC-4, AC-7 and AC-9 are also marked Mechanical in the SREQ** and were missing from that list — a gap in the lead's brief, not in the work. It was sent back to close them while `journal-template.md`'s new entries still did not exist, which is the only window in which the blind-authoring property holds. It declined to invent those anchors unbriefed, which was the right call: an anchor no brief carries is an anchor no author honours, and the check would then fail against correct prose. AC-7 was taken mechanically rather than left to `code`-domain inspection, on the reasoning that "`death-check` present, and no `ended_by` line admitting `timeout`/`elapsed`/`silence`" is two greps and guards the load-bearing half of *elapsed silence never releases a claim* — a single word added to that enumeration would undo the rule silently. ## Carry-forward for cross-unit verification (3.7) `scripts/test-plugin-gates.sh` is **11 PASS / 6 FAIL** on the committed tree, against a baseline of **17 PASS / 0 FAIL**. All six trace to the in-flight red lint; three of them are the release path, because `release.sh` runs `lint-conventions.sh` as gate 1/4 — so **`/dev:promote` is blocked** until the contract's documents land, which is a wider blast radius than a harness-only failure. The teammate first reported this as 3 failures; the lead's re-measurement found 6. The mechanism is now understood and is itself a reusable rule: the three release scenarios operate on a **clone**, so they read `HEAD`, not the working tree — the first measurement was taken pre-commit, when the clone still carried the clean lint script. **Measure this harness against a committed tree or the numbers lie.** Not order- or state-dependence. This needs a **re-run after WU-43-3-3, not a fix**. If it is still red once the lint is green, the cause is real.

jbr870 referenced this issue

2026-08-25 12:19:12 +00:00

wait-discipline: an idle signal is not completion — name the tree-state check #44

jbr870 commented

2026-08-25 12:21:14 +00:00

Author

Owner

Dev Journal — WU-43-3-2 (run-resource-claims contract + record shapes)

[2026-08-25T10:05] DISCOVERY: the AC-15 derivation ban forbids the SREQ's own risk wording

type: discovery
timestamp: 2026-08-25T10:05
where: scripts/lint-conventions.sh
tags: [ac-15, anchors]

Context: AC-15's RRC_DERIV_RE bans the literal token derived_suffixes inside
run-resource-claims.md. The SREQ's Technical Risks table names exactly that field as the lever a
project pulls to widen its database pool, and the brief asks me to state that risk in the document.
Pattern: name the lever by description — "the recipe's per-database suffix list (slot-isolation
§1)" — rather than by field name. The reference still lands the reader on the right field; the document
does not restate the derivation.
Why it matters: the two instructions only look like a conflict. The ban is on restating a
derivation, not on pointing at where one lives. Same reasoning applies to the port half: "the port block
the slot owns" is a value source; the arithmetic that produces it is slot-isolation's.

[2026-08-25T10:40] DISCOVERY: the harness's in-flight allowance retires one work unit too early

type: discovery
timestamp: 2026-08-25T10:40
where: scripts/test-lint-conventions.sh
claude_md_gap: false
tags: [ordering, harness, wu-43-3-1]

Context: scenario_control_clean_tree tolerates the #43 contract's own violations only while the
contract is "in flight", and retires that allowance via rrc_contract_landed(), which is keyed on
exactly two artefacts — run-resource-claims.md existing, and type: dispatch in
journal-template.md. Both are WU-43-3-2's. The moment my unit lands, the allowance lifts, but the
gate is still legitimately red on WU-43-3-3's three consumer citations, so the control test fails.
Pattern: the predicate needs the consumer half too — the two citations plus the test-plan.v1.md
cross-reference. Keyed on all five artefacts it would stay green across every landing order.
Why it matters: verified by simulation rather than argued: a scratch copy of the tree with the
three WU-3 citations appended gives lint-conventions: clean (rc 0) and 21 PASS / 0 FAIL. So the
FAIL is an ordering artefact of the predicate, not a defect in this unit's text — and it self-resolves
the moment WU-43-3-3 commits. scripts/ is outside my boundary, so this is reported, not fixed.

[2026-08-25T10:55] COMPLETE

type: complete
variant: development
timestamp: 2026-08-25T10:55
iterations: 2

Hardest part: honouring AC-15's derivation ban while still stating the SREQ's single-database
ceiling risk, whose lever the SREQ names by the one field token the gate forbids — resolved by naming
the lever descriptively and pointing at slot-isolation §1 for the field itself.
If I did this again: I would grep each anchor for a line break as I wrote it rather than at the
end. One of the six ("a project that declares nothing") landed wrapped across a 100-column break on
the first draft and would have read as absent, exactly as the brief predicted for anchor 4.

# Dev Journal — WU-43-3-2 (run-resource-claims contract + record shapes) ## [2026-08-25T10:05] DISCOVERY: the AC-15 derivation ban forbids the SREQ's own risk wording ```yaml type: discovery timestamp: 2026-08-25T10:05 where: scripts/lint-conventions.sh tags: [ac-15, anchors] ``` **Context:** AC-15's `RRC_DERIV_RE` bans the literal token `derived_suffixes` inside `run-resource-claims.md`. The SREQ's Technical Risks table names exactly that field as the lever a project pulls to widen its database pool, and the brief asks me to state that risk in the document. **Pattern:** name the lever by *description* — "the recipe's per-database suffix list (slot-isolation §1)" — rather than by field name. The reference still lands the reader on the right field; the document does not restate the derivation. **Why it matters:** the two instructions only look like a conflict. The ban is on restating a derivation, not on pointing at where one lives. Same reasoning applies to the port half: "the port block the slot owns" is a value *source*; the arithmetic that produces it is slot-isolation's. ## [2026-08-25T10:40] DISCOVERY: the harness's in-flight allowance retires one work unit too early ```yaml type: discovery timestamp: 2026-08-25T10:40 where: scripts/test-lint-conventions.sh claude_md_gap: false tags: [ordering, harness, wu-43-3-1] ``` **Context:** `scenario_control_clean_tree` tolerates the #43 contract's own violations only while the contract is "in flight", and retires that allowance via `rrc_contract_landed()`, which is keyed on exactly two artefacts — `run-resource-claims.md` existing, and `type: dispatch` in `journal-template.md`. Both are WU-43-3-2's. The moment my unit lands, the allowance lifts, but the gate is still legitimately red on WU-43-3-3's three consumer citations, so the control test fails. **Pattern:** the predicate needs the consumer half too — the two citations plus the `test-plan.v1.md` cross-reference. Keyed on all five artefacts it would stay green across every landing order. **Why it matters:** verified by simulation rather than argued: a scratch copy of the tree with the three WU-3 citations appended gives `lint-conventions: clean` (rc 0) and `21 PASS / 0 FAIL`. So the FAIL is an ordering artefact of the predicate, not a defect in this unit's text — and it self-resolves the moment WU-43-3-3 commits. `scripts/` is outside my boundary, so this is reported, not fixed. ## [2026-08-25T10:55] COMPLETE ```yaml type: complete variant: development timestamp: 2026-08-25T10:55 iterations: 2 ``` **Hardest part:** honouring AC-15's derivation ban while still stating the SREQ's single-database ceiling risk, whose lever the SREQ names by the one field token the gate forbids — resolved by naming the lever descriptively and pointing at slot-isolation §1 for the field itself. **If I did this again:** I would grep each anchor for a line break *as I wrote it* rather than at the end. One of the six ("a project that declares nothing") landed wrapped across a 100-column break on the first draft and would have read as absent, exactly as the brief predicted for anchor 4.

jbr870 commented

2026-08-25 12:21:44 +00:00

Author

Owner

{
  "outcome": "complete",
  "summary": "The canonical intra-run resource-claim contract: plugin/skills/_shared/procedures/run-resource-claims.md (new, 300 lines — 11 sections plus Consumers) and the DISPATCH/RELEASE append-only entry types in journal-template.md, with the driver journal named as $FEATURE_FOLDER/dispatch-journal.md. No Test Writer was spawned — artifact-shape unit per /dev:develop §3.2; its acceptance criteria are assertions about skill-markdown text, verified by the gate WU-43-3-1 authored blind and by code-domain inspection.",
  "commit_refs": ["a0ce85e"],
  "journal_ref": "1379",
  "dependencies_satisfied": ["WU-43-3-1"],
  "dependencies_violated": []
}

Verification, independently re-run by the lead

Gate	Result
`bash scripts/lint-conventions.sh`	rc 1, 3 violations — down from 5. Both of this unit's violations are gone, and every check they were suppressing now runs and passes: all six normative anchors present and unique tree-wide, `slot-isolation.md` cited by path, `§7.2` named, zero derivation-token hits, `test-plan.v1.md` cross-referenced, all seven journal discriminating keys present, driver journal named verbatim, no timeout-admitting `ended_by`.
Remaining red	All three belong to WU-43-3-3: `qa-playbook.md` and `develop/SKILL.md` not yet citing by path (AC-14), `test-plan.v1.md` not yet cross-referencing (AC-16).
File boundary	`a0ce85e` touches exactly the two owned files. `scripts/` untouched, exec bits intact.
Tree	clean

The gate was authored before this document existed and was not modified to fit it. The unit reported judging none of the six anchors wrong and made no edit to scripts/lint-conventions.sh — confirmed by the diff. That is the property the wu-plan's inversion (comment 1372) was for: the checks are an independent assertion, not a description of the prose.

Carry-forward — a defect this feature introduced in its own harness

bash scripts/test-lint-conventions.sh → rc 1, 20 PASS / 1 FAIL (control_clean_tree_no_planted_file).

Cause, diagnosed and verified by the unit rather than argued: WU-43-3-1's in-flight allowance retires via rrc_contract_landed() (scripts/test-lint-conventions.sh:144), which is keyed on only two of the artefacts the gate judges — run-resource-claims.md existing, and type: dispatch present in journal-template.md. Both landed with this unit, so the allowance lifted while the gate is still legitimately red on WU-43-3-3's three citations. The predicate is missing the consumer half.

The unit verified the resolution by copying the tree to scratch, appending the three WU-43-3-3 citations, and running both gates against the copy: lint-conventions clean (rc 0) and the harness 21/21. So this self-resolves the instant WU-43-3-3 commits; no edit to scripts/ is required for the feature to go green. Re-verified at 3.7.

Left unfixed deliberately. The delivered artefact is correct once WU-43-3-3 lands, and the allowance branch exists only for the transitional window that then closes. Pulling scripts/test-lint-conventions.sh into WU-43-3-3 would dilute the unit that carries the AC-14 restate-vs-reference discipline — the one place in this feature where that error is most likely. Recorded as a finding on the terminal Phase Outcome instead. The generalisable form: an in-flight allowance keyed on a subset of the artefacts its gate judges will go red on a correct intermediate state.

Underspecifications resolved by the unit

AC-15's ban list vs the SREQ's own risk text. The SREQ names derived_suffixes as the lever for the single-database ceiling, but the gate forbids that literal token in this file. Resolved descriptively — "the project's own per-database suffix list in its parallel_dev: recipe (slot-isolation §1)" — which points the reader at the field without restating the derivation. Same treatment for the port half.
Flow-style YAML is not JSON. The SREQ requires claims to be jq-readable, but {database: [...]} has unquoted keys. The bridge is pinned explicitly in the triage recipe: one sed quoting the bare keys, after which jq reads it directly. Both that transform and the intersection filter (including "4080-4089" range expansion) were executed, not just written.
Port-range expansion representation. Expanded to strings (map(tostring)) so the intersection is one type throughout.
workers pool source. The project's runner default concurrency; the budget test is a sum over everything dispatched and not yet released — not pairwise, which the SREQ's phrasing could be misread as.

Authoring note for the next unit

The lead's warning that a long anchor can wrap across a 100-column break and then read as absent was right in principle but aimed at the wrong anchor: a project that declares nothing wrapped in the first draft, while the 36-character anchor 4 had been placed at line start deliberately. Check every anchor for a line break, not only the longest one.

```json { "outcome": "complete", "summary": "The canonical intra-run resource-claim contract: plugin/skills/_shared/procedures/run-resource-claims.md (new, 300 lines — 11 sections plus Consumers) and the DISPATCH/RELEASE append-only entry types in journal-template.md, with the driver journal named as $FEATURE_FOLDER/dispatch-journal.md. No Test Writer was spawned — artifact-shape unit per /dev:develop §3.2; its acceptance criteria are assertions about skill-markdown text, verified by the gate WU-43-3-1 authored blind and by code-domain inspection.", "commit_refs": ["a0ce85e"], "journal_ref": "1379", "dependencies_satisfied": ["WU-43-3-1"], "dependencies_violated": [] } ``` ## Verification, independently re-run by the lead | Gate | Result | |---|---| | `bash scripts/lint-conventions.sh` | **rc 1, 3 violations** — down from 5. Both of this unit's violations are gone, and every check they were suppressing now runs and **passes**: all six normative anchors present and unique tree-wide, `slot-isolation.md` cited by path, `§7.2` named, zero derivation-token hits, `test-plan.v1.md` cross-referenced, all seven journal discriminating keys present, driver journal named verbatim, no timeout-admitting `ended_by`. | | Remaining red | All three belong to **WU-43-3-3**: `qa-playbook.md` and `develop/SKILL.md` not yet citing by path (AC-14), `test-plan.v1.md` not yet cross-referencing (AC-16). | | File boundary | `a0ce85e` touches exactly the two owned files. `scripts/` untouched, exec bits intact. | | Tree | clean | **The gate was authored before this document existed and was not modified to fit it.** The unit reported judging none of the six anchors wrong and made no edit to `scripts/lint-conventions.sh` — confirmed by the diff. That is the property the wu-plan's inversion (comment 1372) was for: the checks are an independent assertion, not a description of the prose. ## Carry-forward — a defect this feature introduced in its own harness `bash scripts/test-lint-conventions.sh` → **rc 1, 20 PASS / 1 FAIL** (`control_clean_tree_no_planted_file`). **Cause, diagnosed and verified by the unit rather than argued:** WU-43-3-1's in-flight allowance retires via `rrc_contract_landed()` (`scripts/test-lint-conventions.sh:144`), which is keyed on **only two of the artefacts the gate judges** — `run-resource-claims.md` existing, and `type: dispatch` present in `journal-template.md`. Both landed with this unit, so the allowance lifted while the gate is still legitimately red on WU-43-3-3's three citations. The predicate is missing the consumer half. The unit verified the resolution by copying the tree to scratch, appending the three WU-43-3-3 citations, and running both gates against the copy: `lint-conventions` clean (rc 0) and the harness 21/21. **So this self-resolves the instant WU-43-3-3 commits; no edit to `scripts/` is required for the feature to go green.** Re-verified at 3.7. **Left unfixed deliberately.** The delivered artefact is correct once WU-43-3-3 lands, and the allowance branch exists only for the transitional window that then closes. Pulling `scripts/test-lint-conventions.sh` into WU-43-3-3 would dilute the unit that carries the AC-14 restate-vs-reference discipline — the one place in this feature where that error is most likely. Recorded as a finding on the terminal Phase Outcome instead. The generalisable form: **an in-flight allowance keyed on a subset of the artefacts its gate judges will go red on a correct intermediate state.** ## Underspecifications resolved by the unit 1. **AC-15's ban list vs the SREQ's own risk text.** The SREQ names `derived_suffixes` as the lever for the single-database ceiling, but the gate forbids that literal token in this file. Resolved descriptively — "the project's own per-database suffix list in its `parallel_dev:` recipe (slot-isolation §1)" — which points the reader at the field without restating the derivation. Same treatment for the port half. 2. **Flow-style YAML is not JSON.** The SREQ requires claims to be `jq`-readable, but `{database: [...]}` has unquoted keys. The bridge is pinned explicitly in the triage recipe: one `sed` quoting the bare keys, after which `jq` reads it directly. Both that transform and the intersection filter (including `"4080-4089"` range expansion) were **executed**, not just written. 3. **Port-range expansion representation.** Expanded to strings (`map(tostring)`) so the intersection is one type throughout. 4. **`workers` pool source.** The project's runner default concurrency; the budget test is a sum over everything dispatched and not yet released — **not pairwise**, which the SREQ's phrasing could be misread as. ## Authoring note for the next unit The lead's warning that a long anchor can wrap across a 100-column break and then read as absent was right in principle but aimed at the wrong anchor: `a project that declares nothing` wrapped in the first draft, while the 36-character anchor 4 had been placed at line start deliberately. **Check every anchor for a line break, not only the longest one.**

jbr870 commented

2026-08-25 12:30:19 +00:00

Author

Owner

Dev journal — WU-43-3-3 (route the QA and develop consumers through the claims contract)

Feature: qa-intra-run-lane-ownership (issue #43). Final work unit.
Owned files: qa-playbook.md, validate-workflow.md, fix-workflow.md, develop/SKILL.md,
worktree-discipline.md, test-plan.v1.md.

2026-08-25T10:05 DISCOVERY: the gate's anchor list is a floor, not the discipline

type: discovery
timestamp: 2026-08-25T10:05
where: scripts/lint-conventions.sh
tags: [ac-14, canonical-doc, restatement]

Context: reading the six normative anchors before writing a word of consumer prose.
Pattern: the anchors are matched as case-insensitive substrings tree-wide, so they catch a
copy-paste but not a paraphrase. Writing each consumer paragraph as an obligation owed to the
canonical document ("what this stage owes it", "read them there") rather than as a summary of it
takes the paraphrase pressure off entirely — there is nothing to summarise if every sentence is a
duty rather than a definition.
Why it matters: the drift AC-14 exists to prevent is a paraphrase, not a copy. The linter cannot
see one; the sentence shape can prevent one.

2026-08-25T10:40 DISCOVERY: the contract has no actor-side disclosure duty

type: discovery
timestamp: 2026-08-25T10:40
where: plugin/skills/_shared/procedures/run-resource-claims.md
tags: [gap, overran-claim, declared-and-honoured]

Context: writing the fixer's re-run rule, which is read by a dispatched actor, not the driver.
Pattern: every section of the canonical document addresses the driver — it resolves, compares,
dispatches, records, releases. The one place the actor is load-bearing is the overran_claim
detection: "the declared-and-honoured model has no enforcement, so the report is the detection."
But nothing in the tree tells an actor to disclose use beyond its claim. A grep for
overran_claim finds it only in the contract and in journal-template.md's entry shape — never in
a consumer an actor actually reads.
Why it matters: the only detection mechanism in a model with no enforcement depends on a
disclosure the contract never asks for. Reported to the lead; the fix belongs in
run-resource-claims.md §5, which is not this unit's file.

2026-08-25T10:45 COMPLETE

type: complete
variant: development
timestamp: 2026-08-25T10:45
iterations: 1

Hardest part: writing six paragraphs about a rule without ever stating the rule — the temptation
to define "void" inline was strongest in validate-workflow.md, where the reader is mid-triage and a
pointer feels like an interruption. Resolved by making each bullet an obligation ("ask the run
record, not the result") whose definition lives elsewhere, so the paragraph is complete as guidance
and empty as doctrine.
If I did this again: read the gate's anchor list before drafting rather than after — it fixes the
vocabulary you must avoid, and the sentences come out shaped correctly the first time.

# Dev journal — WU-43-3-3 (route the QA and develop consumers through the claims contract) Feature: qa-intra-run-lane-ownership (issue #43). Final work unit. Owned files: `qa-playbook.md`, `validate-workflow.md`, `fix-workflow.md`, `develop/SKILL.md`, `worktree-discipline.md`, `test-plan.v1.md`. ## 2026-08-25T10:05 DISCOVERY: the gate's anchor list is a floor, not the discipline ```yaml type: discovery timestamp: 2026-08-25T10:05 where: scripts/lint-conventions.sh tags: [ac-14, canonical-doc, restatement] ``` **Context:** reading the six normative anchors before writing a word of consumer prose. **Pattern:** the anchors are matched as case-insensitive substrings tree-wide, so they catch a copy-paste but not a paraphrase. Writing each consumer paragraph as an *obligation owed to* the canonical document ("what this stage owes it", "read them there") rather than as a *summary of* it takes the paraphrase pressure off entirely — there is nothing to summarise if every sentence is a duty rather than a definition. **Why it matters:** the drift AC-14 exists to prevent is a paraphrase, not a copy. The linter cannot see one; the sentence shape can prevent one. ## 2026-08-25T10:40 DISCOVERY: the contract has no actor-side disclosure duty ```yaml type: discovery timestamp: 2026-08-25T10:40 where: plugin/skills/_shared/procedures/run-resource-claims.md tags: [gap, overran-claim, declared-and-honoured] ``` **Context:** writing the fixer's re-run rule, which is read by a *dispatched actor*, not the driver. **Pattern:** every section of the canonical document addresses the driver — it resolves, compares, dispatches, records, releases. The one place the actor is load-bearing is the `overran_claim` detection: "the declared-and-honoured model has no enforcement, so the report **is** the detection." But nothing in the tree tells an actor to *disclose* use beyond its claim. A grep for `overran_claim` finds it only in the contract and in `journal-template.md`'s entry shape — never in a consumer an actor actually reads. **Why it matters:** the only detection mechanism in a model with no enforcement depends on a disclosure the contract never asks for. Reported to the lead; the fix belongs in `run-resource-claims.md` §5, which is not this unit's file. ## 2026-08-25T10:45 COMPLETE ```yaml type: complete variant: development timestamp: 2026-08-25T10:45 iterations: 1 ``` **Hardest part:** writing six paragraphs about a rule without ever stating the rule — the temptation to define "void" inline was strongest in `validate-workflow.md`, where the reader is mid-triage and a pointer feels like an interruption. Resolved by making each bullet an obligation ("ask the run record, not the result") whose *definition* lives elsewhere, so the paragraph is complete as guidance and empty as doctrine. **If I did this again:** read the gate's anchor list before drafting rather than after — it fixes the vocabulary you must avoid, and the sentences come out shaped correctly the first time.

jbr870 commented

2026-08-25 12:30:51 +00:00

Author

Owner

{
  "outcome": "complete",
  "summary": "Routed the six consumers through the claims contract by reference: qa-playbook.md (deferral-table row, precondition 5, the spawn-prompt rule), validate-workflow.md (Step 3 triage, Step 4 late withdrawal), fix-workflow.md (the fixer's scoped re-run is itself a suite run), develop/SKILL.md §3.1 (disjoint files are only half of isolation), worktree-discipline.md (void has one home and it is not this file), test-plan.v1.md (a lane is a scenario property, a claim is an actor property). 53 insertions, no deletions. No Test Writer was spawned — artifact-shape unit per /dev:develop §3.2. This is the unit that turns the gate green.",
  "commit_refs": ["de498e6"],
  "journal_ref": "1381",
  "dependencies_satisfied": ["WU-43-3-1", "WU-43-3-2"],
  "dependencies_violated": []
}

Verification, independently re-run by the lead on the committed tree

Gate	rc	Result
`bash scripts/lint-conventions.sh`	0	`lint-conventions: clean` — fully green, no documented-red remainder
`bash scripts/test-lint-conventions.sh`	0	21 PASS / 0 FAIL
`bash scripts/test-plugin-gates.sh`	0	17 passed, 0 failed, 0 skipped, 17 total — the pre-feature baseline, restored
File boundary	—	`de498e6` touches exactly the six owned files; `scripts/` unmodified, exec bits intact; tree clean

The harness defect recorded against WU-43-3-2 self-resolved, exactly as that unit predicted by experiment: control_clean_tree_no_planted_file went green the moment the citations landed, and test-plugin-gates.sh returned to 17/0 — which also unblocks release.sh, since it runs lint as gate 1/4. No fix to scripts/ was needed, and none was made. Carried forward only as the generalisable lesson, not as an open defect.

The gate was never edited to fit the prose. Across all three units, scripts/lint-conventions.sh was written once — blind, before any of the documents existed — and never touched again. That is the property the wu-plan's inversion (comment 1372) existed to buy, and it held end to end.

The restate-vs-reference discipline, which is what this unit was for

The unit reported nine distinct citation sites and, at each, what it wrote instead of a restatement. Two are worth preserving:

In qa-playbook.md the citation was added as a row in the existing "What this file owns, and what it defers to" table — which is immediately followed by that file's own "Do not restate any of those here." The reference lands inside an existing no-restatement contract rather than beside one.
In validate-workflow.md the temptation was real and named: a reader mid-triage experiences a pointer as an interruption, so an inline definition of void reads better locally. Resolved by making every bullet an obligation whose definition lives elsewhere — "complete as guidance and empty as doctrine." That phrasing is the operational form of AC-14 and is worth reusing.

Anchor uniqueness confirms it mechanically: none of the six normative anchors appears outside run-resource-claims.md.

Gap found in a file this unit could not edit — carried to the Phase Outcome

The contract's only detection mechanism has no producer. run-resource-claims.md §5 states that an actor whose report shows use beyond its claim (overran_claim: true) voids its own result, and that — because the model is declared-and-honoured with no enforcement — the report is the detection. But grep -rn overran_claim plugin/skills/ finds the token only in run-resource-claims.md itself and in journal-template.md's entry shape. No document a dispatched actor actually reads asks it to disclose an overrun.

The gap is inherited from the SREQ, which specifies the consequence and the RELEASE field but never the actor-side duty — so it is a spec-level hole, not an authoring miss.

The unit deliberately did not patch it in its own consumers, and the reasoning is correct: putting an actor-side duty in qa-playbook.md or fix-workflow.md while the canonical document is silent would be a consumer originating a rule the contract does not hold — precisely the drift AC-14 exists to prevent. Raised as a finding on the terminal Phase Outcome instead.

Product observations raised for the Phase Outcome

The domain files' structural-cause enumerations do not include contention. validate-workflow.md Step 3 now routes unattainable isolation to structural, but the lists that actually define structural causes live in _shared/domains/* and name only missing tooling/credentials, config variants and human-only judgment. A validator matching against its domain file may not recognise the new route — which turns a routed finding back into a bare skipped count, the exact failure that routing exists to prevent.
qa-playbook.md precondition 5 now carries five distinct obligations (sibling-slot ownership, the slot identity surface, the end-to-end assertion, the run-time port guard, and the intra-run case). Correct and cohesive, but the longest precondition by a wide margin. A split was considered and rejected because other documents cite preconditions by number and splitting renumbers them.

```json { "outcome": "complete", "summary": "Routed the six consumers through the claims contract by reference: qa-playbook.md (deferral-table row, precondition 5, the spawn-prompt rule), validate-workflow.md (Step 3 triage, Step 4 late withdrawal), fix-workflow.md (the fixer's scoped re-run is itself a suite run), develop/SKILL.md §3.1 (disjoint files are only half of isolation), worktree-discipline.md (void has one home and it is not this file), test-plan.v1.md (a lane is a scenario property, a claim is an actor property). 53 insertions, no deletions. No Test Writer was spawned — artifact-shape unit per /dev:develop §3.2. This is the unit that turns the gate green.", "commit_refs": ["de498e6"], "journal_ref": "1381", "dependencies_satisfied": ["WU-43-3-1", "WU-43-3-2"], "dependencies_violated": [] } ``` ## Verification, independently re-run by the lead on the committed tree | Gate | rc | Result | |---|---|---| | `bash scripts/lint-conventions.sh` | **0** | `lint-conventions: clean` — fully green, no documented-red remainder | | `bash scripts/test-lint-conventions.sh` | **0** | **21 PASS / 0 FAIL** | | `bash scripts/test-plugin-gates.sh` | **0** | **17 passed, 0 failed, 0 skipped, 17 total** — the pre-feature baseline, restored | | File boundary | — | `de498e6` touches exactly the six owned files; `scripts/` unmodified, exec bits intact; tree clean | **The harness defect recorded against WU-43-3-2 self-resolved**, exactly as that unit predicted by experiment: `control_clean_tree_no_planted_file` went green the moment the citations landed, and `test-plugin-gates.sh` returned to 17/0 — which also unblocks `release.sh`, since it runs lint as gate 1/4. No fix to `scripts/` was needed, and none was made. Carried forward only as the generalisable lesson, not as an open defect. **The gate was never edited to fit the prose.** Across all three units, `scripts/lint-conventions.sh` was written once — blind, before any of the documents existed — and never touched again. That is the property the wu-plan's inversion (comment 1372) existed to buy, and it held end to end. ## The restate-vs-reference discipline, which is what this unit was for The unit reported nine distinct citation sites and, at each, what it wrote *instead* of a restatement. Two are worth preserving: - In `qa-playbook.md` the citation was added as a row in the existing **"What this file owns, and what it defers to"** table — which is immediately followed by that file's own *"Do not restate any of those here."* The reference lands inside an existing no-restatement contract rather than beside one. - In `validate-workflow.md` the temptation was real and named: a reader mid-triage experiences a pointer as an interruption, so an inline definition of *void* reads better locally. Resolved by making every bullet an **obligation** whose definition lives elsewhere — *"complete as guidance and empty as doctrine."* That phrasing is the operational form of AC-14 and is worth reusing. Anchor uniqueness confirms it mechanically: none of the six normative anchors appears outside `run-resource-claims.md`. ## Gap found in a file this unit could not edit — carried to the Phase Outcome **The contract's only detection mechanism has no producer.** `run-resource-claims.md` §5 states that an actor whose report shows use beyond its claim (`overran_claim: true`) voids its own result, and that — because the model is declared-and-honoured with no enforcement — *the report is the detection*. But `grep -rn overran_claim plugin/skills/` finds the token only in `run-resource-claims.md` itself and in `journal-template.md`'s entry shape. **No document a dispatched actor actually reads asks it to disclose an overrun.** The gap is inherited from the SREQ, which specifies the consequence and the RELEASE field but never the actor-side duty — so it is a spec-level hole, not an authoring miss. The unit deliberately did **not** patch it in its own consumers, and the reasoning is correct: putting an actor-side duty in `qa-playbook.md` or `fix-workflow.md` while the canonical document is silent would be a consumer originating a rule the contract does not hold — precisely the drift AC-14 exists to prevent. Raised as a finding on the terminal Phase Outcome instead. ## Product observations raised for the Phase Outcome - **The domain files' structural-cause enumerations do not include contention.** `validate-workflow.md` Step 3 now routes unattainable isolation to *structural*, but the lists that actually define structural causes live in `_shared/domains/*` and name only missing tooling/credentials, config variants and human-only judgment. A validator matching against its domain file may not recognise the new route — which turns a routed finding back into a bare skipped count, the exact failure that routing exists to prevent. - **`qa-playbook.md` precondition 5 now carries five distinct obligations** (sibling-slot ownership, the slot identity surface, the end-to-end assertion, the run-time port guard, and the intra-run case). Correct and cohesive, but the longest precondition by a wide margin. A split was considered and rejected because other documents cite preconditions by number and splitting renumbers them.

jbr870 commented

2026-08-25 12:32:33 +00:00

Author

Owner

{
  "phase": "develop",
  "learnings": [
    {
      "id": "L-1",
      "scope": "project",
      "status": "applied",
      "summary": "scripts/test-plugin-gates.sh measures HEAD, not the working tree — three release scenarios drive release.sh against a clone, so a pre-commit run reports the previous commit's state.",
      "evidence": "WU-43-3-1 DISCOVERY 'scripts/test-plugin-gates.sh goes red too, and it is not mine' — reported 3 failures pre-commit; the committed reality was 6. The three missed were the release path, because release.sh runs lint-conventions.sh as gate 1/4, so a red lint blocks /dev:promote outright.",
      "source_ref": "comment:1373",
      "applied_to": "CLAUDE.md"
    },
    {
      "id": "L-2",
      "scope": "project",
      "status": "applied",
      "summary": "A gate's in-flight allowance must be keyed on every artefact the gate judges, not a subset — otherwise it flips to strict on a correct intermediate state.",
      "evidence": "WU-43-3-2: rrc_contract_landed() keyed on 2 of the 5 artefacts, so the clean-tree control failed once the canonical document landed while the citations were still outstanding. Self-resolved at WU-43-3-3, but symptom and cause sat in different files.",
      "source_ref": "comment:1379",
      "applied_to": "CLAUDE.md"
    },
    {
      "id": "L-3",
      "scope": "project",
      "status": "applied",
      "summary": "A grep-based content check reads a wrapped phrase as absent, so hard-wrap is a correctness concern for any phrase a gate greps for.",
      "evidence": "Both #43 authoring units hit this, and each hit a different anchor than the one it had been warned about — the long anchor gets placed deliberately while a shorter one drifts to a line end and wraps.",
      "source_ref": "comment:1379",
      "applied_to": "CLAUDE.md"
    },
    {
      "id": "L-4",
      "scope": "devwork",
      "status": "unhomed",
      "summary": "For a documentation feature, authoring the mechanical gate FIRST and blind — from the acceptance-criteria text, before the documents exist — restores the 2-phase TDD split that /dev:develop's artifact-shape exception otherwise deletes entirely.",
      "evidence": "The SREQ sequenced the lint checks last, reasoning that a check written before its target 'fails for the wrong reason'. That is false: a check asserting a sentence appears in exactly one file, against a tree where it appears in zero, has failed for the right reason. Inverting it (wu-plan comment 1372) made the gate an independent assertion rather than a description of whatever prose was written — which is what AC-14 needed, since its stated failure mode is a consumer restating the rule in a way that 'reads correct in isolation and drifts silently'. Verified end to end: lint-conventions.sh was written once, blind, and never edited again across all three units.",
      "source_ref": "comment:1373",
      "applied_to": null
    },
    {
      "id": "L-5",
      "scope": "devwork",
      "status": "unhomed",
      "summary": "wait-discipline.md's liveness guidance needs the transcript path: in-process subagents write to <lead-session-id>/subagents/agent-*.jsonl, not to a sibling transcript in the project directory.",
      "evidence": "A lead watchdog globbing the project dir measured an unrelated session's mtime and fired STALE while the agent was mid-work with a growing transcript. §1a routes a STALE toward the stall path, and the stall path spawns a replacement Implementer onto a worktree whose writer is still live — the single-writer rule broken by the recovery mechanism. Three further notifications in the same run were stale in the other direction (idle signals arriving after the work was reported and the agent retired). Related to the already-filed #58.",
      "source_ref": "comment:1381",
      "applied_to": null
    }
  ]
}

```json { "phase": "develop", "learnings": [ { "id": "L-1", "scope": "project", "status": "applied", "summary": "scripts/test-plugin-gates.sh measures HEAD, not the working tree — three release scenarios drive release.sh against a clone, so a pre-commit run reports the previous commit's state.", "evidence": "WU-43-3-1 DISCOVERY 'scripts/test-plugin-gates.sh goes red too, and it is not mine' — reported 3 failures pre-commit; the committed reality was 6. The three missed were the release path, because release.sh runs lint-conventions.sh as gate 1/4, so a red lint blocks /dev:promote outright.", "source_ref": "comment:1373", "applied_to": "CLAUDE.md" }, { "id": "L-2", "scope": "project", "status": "applied", "summary": "A gate's in-flight allowance must be keyed on every artefact the gate judges, not a subset — otherwise it flips to strict on a correct intermediate state.", "evidence": "WU-43-3-2: rrc_contract_landed() keyed on 2 of the 5 artefacts, so the clean-tree control failed once the canonical document landed while the citations were still outstanding. Self-resolved at WU-43-3-3, but symptom and cause sat in different files.", "source_ref": "comment:1379", "applied_to": "CLAUDE.md" }, { "id": "L-3", "scope": "project", "status": "applied", "summary": "A grep-based content check reads a wrapped phrase as absent, so hard-wrap is a correctness concern for any phrase a gate greps for.", "evidence": "Both #43 authoring units hit this, and each hit a different anchor than the one it had been warned about — the long anchor gets placed deliberately while a shorter one drifts to a line end and wraps.", "source_ref": "comment:1379", "applied_to": "CLAUDE.md" }, { "id": "L-4", "scope": "devwork", "status": "unhomed", "summary": "For a documentation feature, authoring the mechanical gate FIRST and blind — from the acceptance-criteria text, before the documents exist — restores the 2-phase TDD split that /dev:develop's artifact-shape exception otherwise deletes entirely.", "evidence": "The SREQ sequenced the lint checks last, reasoning that a check written before its target 'fails for the wrong reason'. That is false: a check asserting a sentence appears in exactly one file, against a tree where it appears in zero, has failed for the right reason. Inverting it (wu-plan comment 1372) made the gate an independent assertion rather than a description of whatever prose was written — which is what AC-14 needed, since its stated failure mode is a consumer restating the rule in a way that 'reads correct in isolation and drifts silently'. Verified end to end: lint-conventions.sh was written once, blind, and never edited again across all three units.", "source_ref": "comment:1373", "applied_to": null }, { "id": "L-5", "scope": "devwork", "status": "unhomed", "summary": "wait-discipline.md's liveness guidance needs the transcript path: in-process subagents write to <lead-session-id>/subagents/agent-*.jsonl, not to a sibling transcript in the project directory.", "evidence": "A lead watchdog globbing the project dir measured an unrelated session's mtime and fired STALE while the agent was mid-work with a growing transcript. §1a routes a STALE toward the stall path, and the stall path spawns a replacement Implementer onto a worktree whose writer is still live — the single-writer rule broken by the recovery mechanism. Three further notifications in the same run were stale in the other direction (idle signals arriving after the work was reported and the agent retired). Related to the already-filed #58.", "source_ref": "comment:1381", "applied_to": null } ] } ```

jbr870 commented

2026-08-25 12:34:32 +00:00

Author

Owner

{
  "next_state": "qa",
  "produced": [
    {
      "kind": "wu-plan",
      "ref": "1372",
      "summary": "3 units in 3 sequential waves; gate authored first and blind (supersedes 1369)"
    },
    {
      "kind": "work-unit-outcome",
      "ref": "1375",
      "summary": "WU-43-3-1: the mechanical gate, authored blind — 18 checks + 17 harness scenarios"
    },
    {
      "kind": "work-unit-outcome",
      "ref": "1380",
      "summary": "WU-43-3-2: run-resource-claims.md (new, 300 lines) + DISPATCH/RELEASE entry types"
    },
    {
      "kind": "work-unit-outcome",
      "ref": "1382",
      "summary": "WU-43-3-3: the six consumers routed through the contract by reference"
    },
    {
      "kind": "dev-journal",
      "ref": "1373",
      "summary": "WU-43-3-1 development journal"
    },
    {
      "kind": "dev-journal",
      "ref": "1379",
      "summary": "WU-43-3-2 development journal"
    },
    {
      "kind": "dev-journal",
      "ref": "1381",
      "summary": "WU-43-3-3 development journal"
    },
    {
      "kind": "learning",
      "ref": "comment:1383",
      "summary": "5 learnings (3 applied to CLAUDE.md, 2 unhomed)"
    }
  ],
  "findings": [
    {
      "category": "in-scope-deferrable",
      "severity": "medium",
      "summary": "The claims contract's only overrun-detection mechanism has no producer: nothing asks a dispatched actor to disclose use beyond its claim.",
      "reasoning": "run-resource-claims.md §5 states that an actor whose report shows use beyond its claim (overran_claim: true) voids its own result, and that — because the model is declared-and-honoured with no enforcement — the report IS the detection. But `grep -rn overran_claim plugin/skills/` finds the token only in run-resource-claims.md itself and in journal-template.md's RELEASE entry shape. No document a dispatched actor actually reads asks it to disclose an overrun, so the mechanism cannot fire. The gap is inherited from the SREQ, which specifies the consequence and the RELEASE field but never the actor-side duty — a spec-level hole, not an authoring miss. It breaks no acceptance criterion: AC-8's void-on-overlap is driver-detected from claims and works; this is the additional self-void safety net. WU-43-3-3 deliberately did not patch it in its consumers, because a consumer originating a duty the canonical document does not hold is precisely the drift AC-14 exists to prevent. The fix is one sentence in §5 of a file no work unit now owns.",
      "proposed_action": "fix-in-this-feature",
      "fix_cost": "trivial",
      "feature_value": "core",
      "adjacent_to_blocking": false,
      "requires_product_decision": true,
      "id": "F-PO-43-3-1"
    },
    {
      "category": "in-scope-deferrable",
      "severity": "low",
      "summary": "The QA domain files' structural-cause enumerations do not include contention, so a validator may not recognise the new unattainable-isolation route.",
      "reasoning": "validate-workflow.md Step 3 now routes an unattainable-isolation case to a structural finding (AC-10). But the enumerations that actually define structural causes live in _shared/domains/* and name only missing tooling/credentials, config variants and human-only judgment. A validator reading its own domain file and matching against that list may not recognise the route, which turns a routed finding back into a bare skipped count — the exact failure that routing exists to prevent. Those six domain files were outside every work unit's boundary in this feature. Developer-decidable: adding a cause to an enumeration completes a route this feature already built and changes nothing about what the feature does.",
      "proposed_action": "defer-to-issue",
      "target": null,
      "fix_cost": "small",
      "feature_value": "incidental",
      "adjacent_to_blocking": false,
      "requires_product_decision": false,
      "applied_disposition": "defer-to-issue",
      "id": "F-PO-43-3-2"
    },
    {
      "category": "pre-existing",
      "severity": "low",
      "summary": "The readiness guard demands a parallel_dev: recipe on any multi-worktree layout, which a services-free project cannot satisfy — it blocked this run's own readiness check.",
      "reasoning": "This repo now has two linked worktrees, which makes parallel_dev: conditionally required per readiness-check.md. slot-recipe-validate.sh exits 10 because the recipe schema mandates port and database axes and this repo provisions neither — CLAUDE.md §Parallel sessions declares the slot machinery deliberately unused here. The run recorded it as a reasoned non-blocking gap in the readiness report and proceeded rather than hard-stopping. Already filed as issue #62 and named in this feature's own SREQ as the reason Approach C was rejected, so it is tracked and needs no new sibling.",
      "proposed_action": "accept",
      "fix_cost": "substantial",
      "feature_value": "none",
      "adjacent_to_blocking": false,
      "requires_product_decision": false,
      "applied_disposition": "accept",
      "id": "F-PO-43-3-3"
    },
    {
      "category": "out-of-scope",
      "severity": "info",
      "summary": "qa-playbook.md precondition 5 now carries five distinct obligations and is the longest precondition by a wide margin.",
      "reasoning": "It now covers sibling-slot ownership, the slot identity surface, the end-to-end assertion, the run-time port guard, and the intra-run claims case. The pieces are correct and cohesive, but a future edit to any one of them reads past three others. A split into 'own your environment' / 'own it against the round's own actors' would read better and was considered during WU-43-3-3, then rejected because other documents cite preconditions by number and splitting renumbers them. Recorded so the readability cost is visible rather than discovered later; no action proposed, since the renumbering cost currently exceeds the benefit.",
      "proposed_action": "accept",
      "fix_cost": "small",
      "feature_value": "none",
      "adjacent_to_blocking": false,
      "requires_product_decision": false,
      "applied_disposition": "accept",
      "id": "F-PO-43-3-4"
    }
  ],
  "pending_decisions": [
    {
      "type": "scope-disposition",
      "blocking": false,
      "finding_ref": "F-PO-43-3-1",
      "question": "run-resource-claims.md §5 makes an actor's report the sole detection for an overrun, but no document a dispatched actor reads asks it to disclose one — so the rule cannot fire. Fix now (one sentence in §5), spawn a sibling issue, or accept as-is?",
      "options": [
        "fix-now",
        "defer-to-issue",
        "accept"
      ],
      "recommended": "fix-now",
      "reasoning": "Recommending fix-now on three grounds. It is one sentence in a file this feature owns and no work unit now holds, so the marginal cost is trivial. Left as-is, the feature ships a stated rule with no path to ever trigger — the SREQ committed to 'the detection is the report' as a deliberate substitute for enforcement, and without a disclosure duty that substitute is empty. And it is cheaper here than after merge: the same edit later means re-opening a canonical document whose consumers have by then been reviewed against it. Against fix-now: it breaks no acceptance criterion (AC-8's void-on-overlap is driver-detected and works), and adding an actor-side duty is a genuine behaviour addition rather than a typo fix, which is why this is a product call and not one the run made on its own authority.",
      "id": "D-PO-43-3-1"
    }
  ],
  "suite": {
    "source": "git",
    "sha": "cda2366a4ad8a98958f5aa4f35f5ba7c9622c2a8",
    "dirty": false
  }
}

```json { "next_state": "qa", "produced": [ { "kind": "wu-plan", "ref": "1372", "summary": "3 units in 3 sequential waves; gate authored first and blind (supersedes 1369)" }, { "kind": "work-unit-outcome", "ref": "1375", "summary": "WU-43-3-1: the mechanical gate, authored blind — 18 checks + 17 harness scenarios" }, { "kind": "work-unit-outcome", "ref": "1380", "summary": "WU-43-3-2: run-resource-claims.md (new, 300 lines) + DISPATCH/RELEASE entry types" }, { "kind": "work-unit-outcome", "ref": "1382", "summary": "WU-43-3-3: the six consumers routed through the contract by reference" }, { "kind": "dev-journal", "ref": "1373", "summary": "WU-43-3-1 development journal" }, { "kind": "dev-journal", "ref": "1379", "summary": "WU-43-3-2 development journal" }, { "kind": "dev-journal", "ref": "1381", "summary": "WU-43-3-3 development journal" }, { "kind": "learning", "ref": "comment:1383", "summary": "5 learnings (3 applied to CLAUDE.md, 2 unhomed)" } ], "findings": [ { "category": "in-scope-deferrable", "severity": "medium", "summary": "The claims contract's only overrun-detection mechanism has no producer: nothing asks a dispatched actor to disclose use beyond its claim.", "reasoning": "run-resource-claims.md §5 states that an actor whose report shows use beyond its claim (overran_claim: true) voids its own result, and that — because the model is declared-and-honoured with no enforcement — the report IS the detection. But `grep -rn overran_claim plugin/skills/` finds the token only in run-resource-claims.md itself and in journal-template.md's RELEASE entry shape. No document a dispatched actor actually reads asks it to disclose an overrun, so the mechanism cannot fire. The gap is inherited from the SREQ, which specifies the consequence and the RELEASE field but never the actor-side duty — a spec-level hole, not an authoring miss. It breaks no acceptance criterion: AC-8's void-on-overlap is driver-detected from claims and works; this is the additional self-void safety net. WU-43-3-3 deliberately did not patch it in its consumers, because a consumer originating a duty the canonical document does not hold is precisely the drift AC-14 exists to prevent. The fix is one sentence in §5 of a file no work unit now owns.", "proposed_action": "fix-in-this-feature", "fix_cost": "trivial", "feature_value": "core", "adjacent_to_blocking": false, "requires_product_decision": true, "id": "F-PO-43-3-1" }, { "category": "in-scope-deferrable", "severity": "low", "summary": "The QA domain files' structural-cause enumerations do not include contention, so a validator may not recognise the new unattainable-isolation route.", "reasoning": "validate-workflow.md Step 3 now routes an unattainable-isolation case to a structural finding (AC-10). But the enumerations that actually define structural causes live in _shared/domains/* and name only missing tooling/credentials, config variants and human-only judgment. A validator reading its own domain file and matching against that list may not recognise the route, which turns a routed finding back into a bare skipped count — the exact failure that routing exists to prevent. Those six domain files were outside every work unit's boundary in this feature. Developer-decidable: adding a cause to an enumeration completes a route this feature already built and changes nothing about what the feature does.", "proposed_action": "defer-to-issue", "target": null, "fix_cost": "small", "feature_value": "incidental", "adjacent_to_blocking": false, "requires_product_decision": false, "applied_disposition": "defer-to-issue", "id": "F-PO-43-3-2" }, { "category": "pre-existing", "severity": "low", "summary": "The readiness guard demands a parallel_dev: recipe on any multi-worktree layout, which a services-free project cannot satisfy — it blocked this run's own readiness check.", "reasoning": "This repo now has two linked worktrees, which makes parallel_dev: conditionally required per readiness-check.md. slot-recipe-validate.sh exits 10 because the recipe schema mandates port and database axes and this repo provisions neither — CLAUDE.md §Parallel sessions declares the slot machinery deliberately unused here. The run recorded it as a reasoned non-blocking gap in the readiness report and proceeded rather than hard-stopping. Already filed as issue #62 and named in this feature's own SREQ as the reason Approach C was rejected, so it is tracked and needs no new sibling.", "proposed_action": "accept", "fix_cost": "substantial", "feature_value": "none", "adjacent_to_blocking": false, "requires_product_decision": false, "applied_disposition": "accept", "id": "F-PO-43-3-3" }, { "category": "out-of-scope", "severity": "info", "summary": "qa-playbook.md precondition 5 now carries five distinct obligations and is the longest precondition by a wide margin.", "reasoning": "It now covers sibling-slot ownership, the slot identity surface, the end-to-end assertion, the run-time port guard, and the intra-run claims case. The pieces are correct and cohesive, but a future edit to any one of them reads past three others. A split into 'own your environment' / 'own it against the round's own actors' would read better and was considered during WU-43-3-3, then rejected because other documents cite preconditions by number and splitting renumbers them. Recorded so the readability cost is visible rather than discovered later; no action proposed, since the renumbering cost currently exceeds the benefit.", "proposed_action": "accept", "fix_cost": "small", "feature_value": "none", "adjacent_to_blocking": false, "requires_product_decision": false, "applied_disposition": "accept", "id": "F-PO-43-3-4" } ], "pending_decisions": [ { "type": "scope-disposition", "blocking": false, "finding_ref": "F-PO-43-3-1", "question": "run-resource-claims.md §5 makes an actor's report the sole detection for an overrun, but no document a dispatched actor reads asks it to disclose one — so the rule cannot fire. Fix now (one sentence in §5), spawn a sibling issue, or accept as-is?", "options": [ "fix-now", "defer-to-issue", "accept" ], "recommended": "fix-now", "reasoning": "Recommending fix-now on three grounds. It is one sentence in a file this feature owns and no work unit now holds, so the marginal cost is trivial. Left as-is, the feature ships a stated rule with no path to ever trigger — the SREQ committed to 'the detection is the report' as a deliberate substitute for enforcement, and without a disclosure duty that substitute is empty. And it is cheaper here than after merge: the same edit later means re-opening a canonical document whose consumers have by then been reviewed against it. Against fix-now: it breaks no acceptance criterion (AC-8's void-on-overlap is driver-detected and works), and adding an actor-side duty is a genuine behaviour addition rather than a typo fix, which is why this is a product call and not one the run made on its own authority.", "id": "D-PO-43-3-1" } ], "suite": { "source": "git", "sha": "cda2366a4ad8a98958f5aa4f35f5ba7c9622c2a8", "dirty": false } } ```

jbr870 added

phase/qa

and removed

phase/developing

labels

2026-08-25 12:34:33 +00:00

jbr870 commented

2026-08-25 13:17:09 +00:00

Author

Owner

{
  "status": "resolved",
  "chosen_option": "fix-now",
  "rationale": "The contract named the actor's report as the sole detection for an overrun — a deliberate substitute for the locking and enforcement the requirements phase ruled out — but no document a dispatched actor reads asked it to disclose one, so §8's overrun consequence could never fire. Chosen fix-now on cost and reachability: the edit is one paragraph in a file no work unit still owns, it makes a rule the feature already commits to actually operable, and doing it after merge means re-opening a canonical document whose consumers QA will by then have reviewed against it. Applied during /dev:develop rather than deferred to a QA fix round, so the finding needs no promotion back to in-scope-blocking. Landed as b2848fe; all three gates re-run green afterwards (lint clean, test-lint-conventions 21/0, test-plugin-gates 17/0).",
  "rejected_alternative": "defer-to-issue was the serious alternative, and the case for it was real: the gap breaks no acceptance criterion — AC-8's void-on-overlap is driver-detected from the claims and works without any actor cooperation — so the feature was shippable as it stood, and adding an actor-side duty is a genuine behaviour addition rather than a typo fix, which is why it was escalated as a product call instead of applied on the run's own authority. It was turned down because the marginal cost of doing it now is minutes against a follow-up issue's full re-entry cost, and because shipping a written rule that provably cannot trigger invites a later reader to assume the mechanism works. accept was not seriously in play: it would have kept the sentence in §5 while conceding it can never fire."
}

```json { "status": "resolved", "chosen_option": "fix-now", "rationale": "The contract named the actor's report as the sole detection for an overrun — a deliberate substitute for the locking and enforcement the requirements phase ruled out — but no document a dispatched actor reads asked it to disclose one, so §8's overrun consequence could never fire. Chosen fix-now on cost and reachability: the edit is one paragraph in a file no work unit still owns, it makes a rule the feature already commits to actually operable, and doing it after merge means re-opening a canonical document whose consumers QA will by then have reviewed against it. Applied during /dev:develop rather than deferred to a QA fix round, so the finding needs no promotion back to in-scope-blocking. Landed as b2848fe; all three gates re-run green afterwards (lint clean, test-lint-conventions 21/0, test-plugin-gates 17/0).", "rejected_alternative": "defer-to-issue was the serious alternative, and the case for it was real: the gap breaks no acceptance criterion — AC-8's void-on-overlap is driver-detected from the claims and works without any actor cooperation — so the feature was shippable as it stood, and adding an actor-side duty is a genuine behaviour addition rather than a typo fix, which is why it was escalated as a product call instead of applied on the run's own authority. It was turned down because the marginal cost of doing it now is minutes against a follow-up issue's full re-entry cost, and because shipping a written rule that provably cannot trigger invites a later reader to assume the mechanism works. accept was not seriously in play: it would have kept the sentence in §5 while conceding it can never fire." } ```

jbr870 commented

Author

Owner

{
  "outcome": "skipped",
  "summary": "No application or browser surface to drive end-to-end.",
  "findings": [],
  "not_applicable_reason": "markdown+shell skill suite — no application or browser surface to drive end-to-end; validation is the shell test harness plus dogfooding"
}

```json { "outcome": "skipped", "summary": "No application or browser surface to drive end-to-end.", "findings": [], "not_applicable_reason": "markdown+shell skill suite — no application or browser surface to drive end-to-end; validation is the shell test harness plus dogfooding" } ```

jbr870 commented

Author

Owner

{
  "outcome": "skipped",
  "summary": "No rendered UI in this project.",
  "findings": [],
  "not_applicable_reason": "no rendered UI — the deliverables are markdown skill text and shell helpers"
}

```json { "outcome": "skipped", "summary": "No rendered UI in this project.", "findings": [], "not_applicable_reason": "no rendered UI — the deliverables are markdown skill text and shell helpers" } ```

jbr870 commented

Author

Owner

{
  "outcome": "skipped",
  "summary": "No browser surface is served or rendered.",
  "findings": [],
  "not_applicable_reason": "no browser surface — nothing is served or rendered"
}

```json { "outcome": "skipped", "summary": "No browser surface is served or rendered.", "findings": [], "not_applicable_reason": "no browser surface — nothing is served or rendered" } ```

jbr870 commented

2026-08-25 13:27:02 +00:00

Author

Owner

{
  "outcome": "skipped",
  "summary": "Project declares api_invocation: mode: none.",
  "findings": [],
  "not_applicable_reason": "project declares api_invocation: { mode: none } — no API — markdown+shell skill suite"
}

```json { "outcome": "skipped", "summary": "Project declares api_invocation: mode: none.", "findings": [], "not_applicable_reason": "project declares api_invocation: { mode: none } — no API — markdown+shell skill suite" } ```

jbr870 commented

Author

Owner

{
  "outcome": "skipped",
  "summary": "Project declares api_invocation: mode: none — no endpoints to attack.",
  "findings": [],
  "not_applicable_reason": "project declares api_invocation: { mode: none } — no API — markdown+shell skill suite"
}

```json { "outcome": "skipped", "summary": "Project declares api_invocation: mode: none — no endpoints to attack.", "findings": [], "not_applicable_reason": "project declares api_invocation: { mode: none } — no API — markdown+shell skill suite" } ```

jbr870 commented

2026-08-25 13:45:36 +00:00

Author

Owner

{
  "outcome": "issues-found",
  "summary": "25 verified findings, 6 blocking. The contract's three executable mechanisms each fail toward the permissive answer: the §7 triage recipe extracts nothing, the §4 overlap filter reports disjoint when it cannot tell, and the overrun-disclosure duty reaches no actor. Every mechanical gate was green over all six.",
  "findings": [
    {
      "id": "CR-1",
      "category": "in-scope-blocking",
      "severity": "Critical",
      "summary": "§7's triage recipe extracts nothing: `grep -nE` prefixes every line with `LINENUM:`, which the `^claims:` sed anchor can never match.",
      "reasoning": "Reproduced by the driver against this QA round's own dispatch-journal.md (43 captured lines, one real claims entry): the documented step 3 emits 0 lines and exits 0. Dropping `-n` from step 1, changing nothing else, emits {\"database\": [], \"port\": [], \"workers\": 1, \"external\": []}, which `jq -e .` accepts and the §4 filter consumes. The failure is silent — `sed -n` prints nothing and returns success — so a driver following the recipe reads 'no claims in the record' and concludes 'nothing overlapped'. That is a confident false negative, the exact failure mode §7's own prose warns about two paragraphs earlier for `concurrent_with`. AC-9 ('was it contended?' is answered from the run record) rests entirely on this recipe, and its stated verification approach — 'a reader executes the triage scan recipe against a real run's journal' — was evidently never performed. Found independently by the Dependency Verifier and the Bug Hunter."
    },
    {
      "id": "CR-2",
      "category": "in-scope-blocking",
      "severity": "Critical",
      "summary": "§4's overlap filter returns `[]` — the 'provably disjoint, dispatch concurrently' signal — for four distinct input classes it cannot actually judge.",
      "reasoning": "Executed by the driver against the filter as published. All four return []: (a) two actors claiming the IDENTICAL reversed range \"4080-4079\" (range(4080;4080) is empty, so the claim expands to nothing); (b) two actors claiming the IDENTICAL database identity \"2024-01\" (expand is applied to every identity set, not only `port` as the prose says, so any range-shaped name vanishes); (c) two actors claiming the IDENTICAL project-named class `redis`, which §2 and §4's prose explicitly say is claimable and tested as an identity set, but the filter hardcodes [\"database\",\"port\",\"external\"]; (d) a class present on one side only, which §3 calls unknown-⇒-serialize but the snippet reads as disjoint. The controls pass — genuinely overlapping databases and overlapping port ranges are both reported correctly — which is why this survived. The root is one defect, not four: `[]` is overloaded to mean both 'disjoint' and 'I could not tell', and §1's serialize-by-default posture is inverted by the snippet, which defaults to the permissive answer. This is the dispatch decision itself (AC-1, AC-4). Bug Hunter M1/M7(a)/M7(b)/L12, merged and verified."
    },
    {
      "id": "CR-3",
      "category": "in-scope-blocking",
      "severity": "High",
      "summary": "The overrun-disclosure duty reaches no actor: the contract asserts consumers carry it, and no consumer does.",
      "reasoning": "§5 says 'Drivers put the duty in the brief they dispatch (`qa-playbook.md`, `/dev:develop` §3.1)'. Verified by grep: `overran_claim`, 'overrun', 'beyond its claim' and 'disclos' appear nowhere in qa-playbook.md, develop/SKILL.md, fix-workflow.md or validate-workflow.md — the token exists only in run-resource-claims.md itself, journal-template.md's record shape, and the two lint scripts. So the contract makes a claim about documents that do not say what it claims. This is the same gap as F-PO-43-3-1, whose resolution D-PO-43-3-1 chose fix-now and landed b2848fe — but b2848fe added the duty to the contract only; the consumer half of that fix is missing, and the contract's own assertion makes the omission invisible. Corroborated live: this round's driver assembled its spawn briefs from qa-playbook and carried no disclosure duty in any of them, including for its own suite-running actor. Breaking scenario: an actor's suite falls back to the default database when its assigned one is unreachable, reports green, discloses nothing (it was never asked), overran_claim is recorded false, §8.4 never fires, and the contaminated result is citable — with every document obeyed to the letter."
    },
    {
      "id": "CR-4",
      "category": "in-scope-blocking",
      "severity": "High",
      "summary": "The in-flight allowance re-arms on regression: with the canonical document deleted, the harness reports 21/21 pass, rc=0.",
      "reasoning": "`rrc_contract_landed()` (test-lint-conventions.sh:144-149) keys on the EXISTENCE of the artefacts the gate judges. Its comment claims it is 'self-retiring with no edit here' — true forwards, false backwards. Delete the canonical doc and the predicate flips back to not-landed; every resulting violation message contains the substring 'run-resource-claims', so the `grep -Fv 'run-resource-claims'` filter finds nothing unexpected and the control PASSES. Measured, not reasoned: copied the real tree to scratch, deleted plugin/skills/_shared/procedures/run-resource-claims.md, ran the harness — 21 passed, 0 failed, rc=0, with the control reporting the in-flight note. Same result for removing `type: dispatch` from journal-template.md. A control planting an UNRELATED violation still fails loudly (20/1, rc=1), so the masking is scoped precisely to this feature's own artefacts — the wrong scope exactly. Mitigating, and why this is High rather than Critical: lint-conventions.sh itself still goes red on the deletion, and it is gate 1/4 of release.sh, so a real deletion still blocks a release; the false green is confined to the self-test tier. The contract has landed, so the predicate and its lenient branch are now dead code whose only reachable behaviour is this masking — delete both and restore the unconditional rc==0 assertion. This also retires the misleading docstring (it says 'every artefact the gate judges' while keying on 2 of ~7) and the over-broad in-flight filter."
    },
    {
      "id": "CR-5",
      "category": "in-scope-blocking",
      "severity": "High",
      "summary": "The `workers` budget test has no denominator: nothing in the suite declares the runner pool it compares against.",
      "reasoning": "§4 makes a collision 'sum of concurrently-claimed workers exceeds the project's runner pool'; §2 sources the value as 'the project's runner default concurrency'. Verified by grep: the phrase appears only inside run-resource-claims.md (three times), and no declaration surface anywhere — slot-isolation.md, dev-server-lifecycle.md, readiness-check.md, setup — declares a pool. §2 simultaneously promises that a project declaring nothing is fully supported and never blocked. Three names for the same number ('runner pool', 'runner default concurrency', 'the project's runner default') with no statement they are the same. Breaking scenario: two actors at `workers: 4` on a project that declares nothing — one agent guesses pool = CPU count and dispatches both, another treats the unknown pool as §1's 'an unknown' and serializes. Two competent agents, opposite dispatch decisions from the same text; §3's absent-key rule covers an unknown CLAIM, not an unknown POOL. Corroborated live: this round's driver wrote `workers: 1` 'against a pool of 32', having guessed the pool from `nproc` — exactly the guess the finding predicts."
    },
    {
      "id": "CR-6",
      "category": "in-scope-blocking",
      "severity": "Medium",
      "summary": "§7's YAML→JSON step quotes only keys, so a conforming claim block with unquoted values produces invalid JSON.",
      "reasoning": "Executed: `claims: {database: [app_test], port: [4080-4089], workers: 1, external: []}` — flat-YAML-safe by the contract's own definition (scalars and flat string lists; nothing mandates quoting), and journal-template.md's template shows bare `[...]` placeholders rather than quoted examples — converts to {\"database\": [app_test], ...} and jq reports 'Invalid numeric literal at line 1, column 23'. The recipe therefore works only when every value happens to be double-quoted, which no document requires. At least this failure is loud, unlike CR-1. Same section and same fix pass as CR-1, which is why it is grouped as blocking rather than demoted."
    },
    {
      "id": "CR-7",
      "category": "in-scope-deferrable",
      "severity": "Medium",
      "summary": "`SCAN=/tmp/dispatch-scan.txt` — a fixed, predictable path in a normative recipe whose own subject guarantees concurrent execution.",
      "reasoning": "Written with plain `>`, which follows a pre-existing symlink rather than refusing on one (CWE-377/CWE-59). The concurrency half matters more than the symlink half: two actors triaging in the same run — which this document exists to make routine — race on one scan file, so the anti-contention procedure's own tooling is contended. The fixed-/tmp idiom is a house pattern (10 other sites across promote, integrate, rebase-onto-base, requirements-from-deferred), but those are single-writer moments — one skill writing one payload for one helper call — so this is not the house pattern replicated and does not qualify as pre-existing. scripts/lint-conventions.sh in this same diff does it correctly: scratch=\"$(mktemp)\" with a trap. Found by both Static Security and the Bug Hunter.",
      "proposed_action": "fix-in-this-feature",
      "fix_cost": "trivial",
      "feature_value": "core",
      "adjacent_to_blocking": true
    },
    {
      "id": "CR-8",
      "category": "in-scope-deferrable",
      "severity": "Medium",
      "summary": "The record shape specifies a timestamp FORMAT but never says to read the clock, and does not pin a single UTC offset.",
      "reasoning": "DISPATCH and RELEASE both say `timestamp: [ISO 8601]`. An LLM driver composing journal entries as prose estimates the value, and nothing detects the drift. Demonstrated live in this round: four entries were hand-estimated, three landed 2-6 minutes ahead of the real clock, and the mutation battery's DISPATCH/RELEASE pair is inverted against wall time — a negative-length window. It surfaced only because the driver ran `date` for an unrelated reason. §7 computes each actor's window as [DISPATCH ts, RELEASE ts) and answers contention by intersecting windows, so estimated stamps give wrong answers in both directions. The journal is append-only by contract, so drift cannot be corrected in place — prevention is the whole of the fix. Bug Hunter L11 adds the second half: ISO 8601 permits mixed UTC offsets, which do not compare lexically, and nothing pins the journal to one.",
      "proposed_action": "fix-in-this-feature",
      "fix_cost": "trivial",
      "feature_value": "core",
      "adjacent_to_blocking": false
    },
    {
      "id": "CR-9",
      "category": "in-scope-deferrable",
      "severity": "Medium",
      "summary": "The `/dev:develop` consumer omits the solo-actor claim rule AC-2 requires of it, and never mentions the dispatch record at all.",
      "reasoning": "develop/SKILL.md:110's added sentence triggers only on concurrency ('before dispatching units concurrently, resolve what each one will own'). qa-playbook.md:50 requires the claims block 'including when it is the only actor the round dispatches', and AC-2's verification approach names BOTH consumers for exactly that property. A single-unit wave — or the single-worktree sequential fallback, which §3.1's own text makes the majority case — therefore dispatches suite-running Implementers with no claims and no DISPATCH entries, so a later 'was anything else running?' against a develop-phase result has no record to ask. The Spec Checker judged this acceptable on the grounds that the contract's own rule is unconditional and restating it would risk AC-14; the Bug Hunter judged it a gap. The lead sides with the Bug Hunter: AC-2 names both consumers explicitly, and a citation that scopes itself to the concurrent case is narrower than the rule it cites — the fix is to widen the trigger, which needs no restatement.",
      "proposed_action": "fix-in-this-feature",
      "fix_cost": "trivial",
      "feature_value": "core",
      "adjacent_to_blocking": false
    },
    {
      "id": "CR-10",
      "category": "in-scope-deferrable",
      "severity": "Medium",
      "summary": "`overran_claim` is a bare boolean, so the durable record never says WHAT was overrun — and §7 step 4's scope for it is ambiguous.",
      "reasoning": "§5 puts the naming of overrun resources in the actor's REPORT, but triage (§7) reads the JOURNAL, and §9's whole point is triage happening late, after transient reports are gone. The consequence is visible in §7 step 4's blanket rule — 'any RELEASE carrying overran_claim: true means the result was contended' — which is blanket precisely because a boolean cannot support a resource-overlap test. The optional free-prose Note is not a contract. Second half: is that 'any' bounded by step 3's window intersection, or global to a journal explicitly 'carried across every phase of the feature'? The global reading voids results against overruns that provably could not have touched them; the window reading contradicts the plain text. Both readings are defensible, which is the defect.",
      "proposed_action": "fix-in-this-feature",
      "fix_cost": "small",
      "feature_value": "core",
      "adjacent_to_blocking": false
    },
    {
      "id": "CR-11",
      "category": "in-scope-deferrable",
      "severity": "Medium",
      "summary": "The scope sentence promises 'any set of concurrent actors', but the mechanism is strictly intra-driver and cannot see a second driver.",
      "reasoning": "Claims live in briefs one driver writes, comparison happens inside that driver, and the record is per-feature ($FEATURE_FOLDER/dispatch-journal.md). Two feature sessions running in parallel on one project — this repo's own documented operating model, per CLAUDE.md §Parallel sessions — each dispatch actors claiming the same unslotted default test database. Each driver compares only its own dispatches, finds no overlap, and each journal's §7 scan later certifies 'uncontended': a false negative produced BY the record rather than despite it. This is not in the Non-Goals list; the nearest exclusion is 'contention by actors that never claimed anything', and these actors did claim, in another journal. The honest fix is to narrow the scope sentence or name the cross-driver case as a non-goal — not to build cross-driver machinery, which requirements ruled out.",
      "proposed_action": "fix-in-this-feature",
      "fix_cost": "small",
      "feature_value": "core",
      "adjacent_to_blocking": false
    },
    {
      "id": "CR-12",
      "category": "in-scope-deferrable",
      "severity": "Medium",
      "summary": "§5 equates 'the actor's report arrives' with the resources being free, which is false when the suite leaves stragglers.",
      "reasoning": "A suite that spawns a watch-mode runner or orphans a dev server leaves the child holding the port or database after RELEASE has been honestly written with ended_by: report. The next actor is dispatched onto 'released' resources, contends, and §7 later finds beautifully serialized windows — the record certifies as uncontended a contention the model itself created. The server half is arguably covered by dev-server-lifecycle re-verification; runner stragglers are not, and nothing in §5 makes release conditional on the resources actually being quiesced.",
      "proposed_action": "fix-in-this-feature",
      "fix_cost": "small",
      "feature_value": "incidental",
      "adjacent_to_blocking": false
    },
    {
      "id": "CR-13",
      "category": "in-scope-deferrable",
      "severity": "Medium",
      "summary": "Who obtains 'sole ownership' for a void re-run is unassigned, and the three documents that mention it point at three different actors.",
      "reasoning": "validate-workflow.md tells the domain VALIDATOR to re-run under sole ownership before classifying; run-resource-claims §8.1 states it agentlessly; fix-workflow gives the re-run to the FIXER. But only the DRIVER controls dispatch, holds the journal, and can guarantee nothing else is in flight — a validator cannot serialize its siblings. Breaking scenario: the validator scans the journal, sees the other actor released, re-runs — while the driver, following its own half of the contract, dispatches the next round's fixer whose claims were compared only against dispatched actors, the validator's re-run being invisible because its DISPATCH belongs to the original run. A second contended result, produced by the remedy.",
      "proposed_action": "fix-in-this-feature",
      "fix_cost": "small",
      "feature_value": "core",
      "adjacent_to_blocking": false
    },
    {
      "id": "CR-14",
      "category": "in-scope-deferrable",
      "severity": "Medium",
      "summary": "The new gate section is deliberately not fence-aware, contradicting an explicit SREQ constraint and a CLAUDE.md convention.",
      "reasoning": "The SREQ's Constraints say 'scripts/lint-conventions.sh is repo-local and fence-aware; new checks must reuse its existing fence tracker rather than line-regexing', and CLAUDE.md carries the same rule with the #50 evidence behind it. The implementation line-regexes and argues its way out in a code comment. The comment's reasoning is genuinely good for the citation checks — a fenced example that restates the rule is a restatement just the same — but the anchor-UNIQUENESS scan is the half where it bites: an anchor phrase appearing inside a fenced counter-example or a quoted 'do NOT write this' illustration in a consumer would be flagged, which is the false-positive class the fence tracker exists to prevent. Worth a recorded decision either way; the deviation currently lives only in a code comment, so a future reader cannot tell it was considered.",
      "proposed_action": "defer-to-issue",
      "fix_cost": "substantial",
      "feature_value": "incidental",
      "adjacent_to_blocking": false
    },
    {
      "id": "CR-15",
      "category": "in-scope-deferrable",
      "severity": "Low",
      "summary": "All 17 contract scenarios build synthetic fixture documents instead of copying and mutating the real, already-landed ones.",
      "reasoning": "make_claims_tree and its write_rrc_* helpers hand-author minimal fake versions of seven documents that already exist in the repo with real, much longer prose. None of the 17 scenarios copies-and-mutates the real files the way test-plugin-gates.sh's make_lint_copy does. This is the pattern CLAUDE.md calls the worst case — a fixture standing in for content the repo already holds — and it is exactly the shape that would miss a wrapped anchor in the REAL document, which is this feature's own recorded learning. Partly answered empirically this round: the driver's 20-mutation battery mutated the REAL documents and every check fired correctly with the specific message, so today's fixtures happen to encode the right assumptions. That is evidence about today, not about the design. The existing clean-tree control does run against the real tree, but that protection is coincidental to this design rather than provided by it — and per CR-4 it is one file-deletion from being defeated.",
      "proposed_action": "defer-to-issue",
      "fix_cost": "substantial",
      "feature_value": "incidental",
      "adjacent_to_blocking": false
    },
    {
      "id": "CR-16",
      "category": "in-scope-deferrable",
      "severity": "Low",
      "summary": "Three defensive 'file is missing' guards in the gate are exercised in neither direction.",
      "reasoning": "lint-conventions.sh's 'AC-14 consumer file is missing', 'test-plan.v1.md is missing' and 'readiness/setup surface is missing' branches have no MSG_ constant and no scenario. No scenario deletes qa-playbook.md, develop/SKILL.md, test-plan.v1.md, readiness-check.md or setup/SKILL.md; the AC-16 inbound scenario overwrites content rather than deleting the file, so only the elif branch is reached. A bug making one of these guards wrongly fire, or wrongly stay silent on a genuinely missing file, goes undetected in both directions. The driver's own mutation battery covers the canonical-doc deletion case but not these three.",
      "proposed_action": "fix-in-this-feature",
      "fix_cost": "small",
      "feature_value": "incidental",
      "adjacent_to_blocking": false
    },
    {
      "id": "CR-17",
      "category": "in-scope-deferrable",
      "severity": "Low",
      "summary": "Two consumers paraphrase the rule they cite, and the paraphrases carry no gate anchor — so they run under AC-14's mechanical floor.",
      "reasoning": "qa-playbook.md restates the remedy pair and the void classification; worktree-discipline.md restates both void causes while declaring itself 'a pointer, not a second copy'. Neither paraphrase contains one of the six anchors, so the uniqueness check cannot see them — this is precisely the drift channel the SREQ says the gate exists for, operating below the gate's floor. The paraphrases have already drifted slightly: qa-playbook's version triggers on 'where they would overlap', omitting the unknown-and-malformed ⇒ serialize half of §1. The Spec Checker independently flagged validate-workflow.md:54 as the same shape. Whether summary-then-cite is a defect or good writing is a judgement call, but the measured drift is not.",
      "proposed_action": "fix-in-this-feature",
      "fix_cost": "small",
      "feature_value": "core",
      "adjacent_to_blocking": false
    },
    {
      "id": "CR-18",
      "category": "in-scope-deferrable",
      "severity": "Low",
      "summary": "The `ended_by` timeout check is line-scoped and value-literal, so a reformat or a new third value passes it.",
      "reasoning": "The check inspects only lines containing `ended_by:` and greps for timeout|elapsed|silence. Reformat journal-template.md so the enum wraps with `timeout` on the following line and the gate passes a document that admits a timeout — the inverse of this repo's own wrapped-anchor learning, which was recorded from this very feature. Equally, a new third value that is not literally one of those three words (`assumed-dead`, `gave-up`) passes. AC-7 is the criterion this weakens.",
      "proposed_action": "fix-in-this-feature",
      "fix_cost": "small",
      "feature_value": "incidental",
      "adjacent_to_blocking": false
    },
    {
      "id": "CR-19",
      "category": "in-scope-deferrable",
      "severity": "Low",
      "summary": "Actor ids are not required to be unique per dispatch, so RELEASE-to-DISPATCH pairing is undefined for a repeated role.",
      "reasoning": "RELEASE's actor 'must match an earlier DISPATCH entry', but nothing requires ids unique per dispatch. A fixer dispatched in rounds 1 and 3 under the same role name yields two DISPATCH entries and two RELEASEs, and the pairing rule — nearest-following, first-unmatched, something else — is unstated. A mispaired window flips a contention verdict. Observable in this round's own journal, where role names are stable strings.",
      "proposed_action": "fix-in-this-feature",
      "fix_cost": "small",
      "feature_value": "incidental",
      "adjacent_to_blocking": false
    },
    {
      "id": "CR-20",
      "category": "in-scope-deferrable",
      "severity": "Low",
      "summary": "`ended_by` has no value for a deliberate driver-initiated termination.",
      "reasoning": "Both permitted values are positive events about the actor's own fate — a report, or a death check. A driver that kills a runaway actor must either record the kill as death-check (defensible if kill-then-verify counts, but unstated) or leave the claim held forever. The enum's deliberate two-value design is load-bearing for AC-7, so the fix is a sentence saying which, not a third value.",
      "proposed_action": "fix-in-this-feature",
      "fix_cost": "trivial",
      "feature_value": "incidental",
      "adjacent_to_blocking": false
    },
    {
      "id": "CR-21",
      "category": "in-scope-deferrable",
      "severity": "Low",
      "summary": "The four-class vocabulary omits shared writable scratch and cache surfaces, which collide near-universally when two suites run in one checkout.",
      "reasoning": "Coverage output directories, bundler and test-runner caches (.vite, .next, node_modules/.cache) are not database, port, workers or external. The model's answer is 'the project declares it', but this is precisely the resource nobody thinks to name — no project declares its cache until it has already lost a day to it, which is the same shape as the 18 minutes and five hours this feature was written for. A sentence naming shared writable caches as a candidate class closes it without a new mandatory block.",
      "proposed_action": "fix-in-this-feature",
      "fix_cost": "trivial",
      "feature_value": "incidental",
      "adjacent_to_blocking": false
    },
    {
      "id": "CR-22",
      "category": "in-scope-deferrable",
      "severity": "Low",
      "summary": "The late-withdrawal rule assigns the re-post to a domain agent that has usually exited by the time contention is established.",
      "reasoning": "validate-workflow.md says 'the domain re-posts its report', but §9's whole premise is contention established LATE — after the domain agent released and exited at report time. Whether the driver may re-post on the domain's behalf is unstated, and an agent taking the sentence literally waits for a dead actor. qa-report:v1 is latest-wins, so the mechanism works whoever posts; only the assignment is missing.",
      "proposed_action": "fix-in-this-feature",
      "fix_cost": "trivial",
      "feature_value": "core",
      "adjacent_to_blocking": false
    },
    {
      "id": "CR-23",
      "category": "in-scope-deferrable",
      "severity": "Low",
      "summary": "§7 step 1 conflates a missing journal with a journal that has no entries, and lets grep's error text land in the scan file as data.",
      "reasoning": "grep exits 2 for a missing file and 1 for no matches, and the redirection is `> \"$SCAN\" 2>&1`, so the error message is written INTO the scan file. The same 'no dispatch record' line prints for both cases, then execution continues with a scan file that may contain a grep error line the later sed would treat as data. Cosmetic given CR-1 makes the extraction return nothing anyway, but it is in the same block and should be fixed in the same pass.",
      "proposed_action": "fix-in-this-feature",
      "fix_cost": "trivial",
      "feature_value": "incidental",
      "adjacent_to_blocking": true
    },
    {
      "id": "CR-24",
      "category": "in-scope-deferrable",
      "severity": "Low",
      "summary": "The remedy preference is stated in opposite orders in §1 and §4.",
      "reasoning": "§1 lists serialize first, as the default: 'run the actors one after another, or reassign one of them'. §4 lists the opposite preference: 'reassign one actor onto a different identity, and failing that, serialize'. The two are reconcilable — a default action versus a preference once remediating — but nothing says so, and two agents can read the priority differently. Low impact because both outcomes are safe; it is a legibility defect in a document whose whole job is to be executed identically by different readers.",
      "proposed_action": "fix-in-this-feature",
      "fix_cost": "trivial",
      "feature_value": "incidental",
      "adjacent_to_blocking": false
    },
    {
      "id": "CR-25",
      "category": "in-scope-deferrable",
      "severity": "Low",
      "summary": "The QA playbook's control flow has no step at which the dispatch journal is written.",
      "reasoning": "The DISPATCH/RELEASE duty reaches the QA driver only transitively, through the referenced contract's §6. No numbered playbook step sequences 'append DISPATCH before spawning' or 'append RELEASE once wait-discipline concludes'. This is consistent with the do-not-restate discipline, and a citation is the correct mechanism — but the playbook self-describes as 'the control flow', and a driver working its steps in order never reaches a step where the record gets written. Observed in this round: the driver wrote the journal because it had read the contract directly, not because any playbook step told it to.",
      "proposed_action": "fix-in-this-feature",
      "fix_cost": "small",
      "feature_value": "core",
      "adjacent_to_blocking": false
    }
  ],
  "artifacts": {
    "report_path": ".devwork/feature-qa-intra-run-lane-ownership/code-report.md",
    "journal_path": ".devwork/feature-qa-intra-run-lane-ownership/code-journal.md",
    "dispatch_journal": ".devwork/feature-qa-intra-run-lane-ownership/dispatch-journal.md"
  }
}

```json { "outcome": "issues-found", "summary": "25 verified findings, 6 blocking. The contract's three executable mechanisms each fail toward the permissive answer: the §7 triage recipe extracts nothing, the §4 overlap filter reports disjoint when it cannot tell, and the overrun-disclosure duty reaches no actor. Every mechanical gate was green over all six.", "findings": [ { "id": "CR-1", "category": "in-scope-blocking", "severity": "Critical", "summary": "§7's triage recipe extracts nothing: `grep -nE` prefixes every line with `LINENUM:`, which the `^claims:` sed anchor can never match.", "reasoning": "Reproduced by the driver against this QA round's own dispatch-journal.md (43 captured lines, one real claims entry): the documented step 3 emits 0 lines and exits 0. Dropping `-n` from step 1, changing nothing else, emits {\"database\": [], \"port\": [], \"workers\": 1, \"external\": []}, which `jq -e .` accepts and the §4 filter consumes. The failure is silent — `sed -n` prints nothing and returns success — so a driver following the recipe reads 'no claims in the record' and concludes 'nothing overlapped'. That is a confident false negative, the exact failure mode §7's own prose warns about two paragraphs earlier for `concurrent_with`. AC-9 ('was it contended?' is answered from the run record) rests entirely on this recipe, and its stated verification approach — 'a reader executes the triage scan recipe against a real run's journal' — was evidently never performed. Found independently by the Dependency Verifier and the Bug Hunter." }, { "id": "CR-2", "category": "in-scope-blocking", "severity": "Critical", "summary": "§4's overlap filter returns `[]` — the 'provably disjoint, dispatch concurrently' signal — for four distinct input classes it cannot actually judge.", "reasoning": "Executed by the driver against the filter as published. All four return []: (a) two actors claiming the IDENTICAL reversed range \"4080-4079\" (range(4080;4080) is empty, so the claim expands to nothing); (b) two actors claiming the IDENTICAL database identity \"2024-01\" (expand is applied to every identity set, not only `port` as the prose says, so any range-shaped name vanishes); (c) two actors claiming the IDENTICAL project-named class `redis`, which §2 and §4's prose explicitly say is claimable and tested as an identity set, but the filter hardcodes [\"database\",\"port\",\"external\"]; (d) a class present on one side only, which §3 calls unknown-⇒-serialize but the snippet reads as disjoint. The controls pass — genuinely overlapping databases and overlapping port ranges are both reported correctly — which is why this survived. The root is one defect, not four: `[]` is overloaded to mean both 'disjoint' and 'I could not tell', and §1's serialize-by-default posture is inverted by the snippet, which defaults to the permissive answer. This is the dispatch decision itself (AC-1, AC-4). Bug Hunter M1/M7(a)/M7(b)/L12, merged and verified." }, { "id": "CR-3", "category": "in-scope-blocking", "severity": "High", "summary": "The overrun-disclosure duty reaches no actor: the contract asserts consumers carry it, and no consumer does.", "reasoning": "§5 says 'Drivers put the duty in the brief they dispatch (`qa-playbook.md`, `/dev:develop` §3.1)'. Verified by grep: `overran_claim`, 'overrun', 'beyond its claim' and 'disclos' appear nowhere in qa-playbook.md, develop/SKILL.md, fix-workflow.md or validate-workflow.md — the token exists only in run-resource-claims.md itself, journal-template.md's record shape, and the two lint scripts. So the contract makes a claim about documents that do not say what it claims. This is the same gap as F-PO-43-3-1, whose resolution D-PO-43-3-1 chose fix-now and landed b2848fe — but b2848fe added the duty to the contract only; the consumer half of that fix is missing, and the contract's own assertion makes the omission invisible. Corroborated live: this round's driver assembled its spawn briefs from qa-playbook and carried no disclosure duty in any of them, including for its own suite-running actor. Breaking scenario: an actor's suite falls back to the default database when its assigned one is unreachable, reports green, discloses nothing (it was never asked), overran_claim is recorded false, §8.4 never fires, and the contaminated result is citable — with every document obeyed to the letter." }, { "id": "CR-4", "category": "in-scope-blocking", "severity": "High", "summary": "The in-flight allowance re-arms on regression: with the canonical document deleted, the harness reports 21/21 pass, rc=0.", "reasoning": "`rrc_contract_landed()` (test-lint-conventions.sh:144-149) keys on the EXISTENCE of the artefacts the gate judges. Its comment claims it is 'self-retiring with no edit here' — true forwards, false backwards. Delete the canonical doc and the predicate flips back to not-landed; every resulting violation message contains the substring 'run-resource-claims', so the `grep -Fv 'run-resource-claims'` filter finds nothing unexpected and the control PASSES. Measured, not reasoned: copied the real tree to scratch, deleted plugin/skills/_shared/procedures/run-resource-claims.md, ran the harness — 21 passed, 0 failed, rc=0, with the control reporting the in-flight note. Same result for removing `type: dispatch` from journal-template.md. A control planting an UNRELATED violation still fails loudly (20/1, rc=1), so the masking is scoped precisely to this feature's own artefacts — the wrong scope exactly. Mitigating, and why this is High rather than Critical: lint-conventions.sh itself still goes red on the deletion, and it is gate 1/4 of release.sh, so a real deletion still blocks a release; the false green is confined to the self-test tier. The contract has landed, so the predicate and its lenient branch are now dead code whose only reachable behaviour is this masking — delete both and restore the unconditional rc==0 assertion. This also retires the misleading docstring (it says 'every artefact the gate judges' while keying on 2 of ~7) and the over-broad in-flight filter." }, { "id": "CR-5", "category": "in-scope-blocking", "severity": "High", "summary": "The `workers` budget test has no denominator: nothing in the suite declares the runner pool it compares against.", "reasoning": "§4 makes a collision 'sum of concurrently-claimed workers exceeds the project's runner pool'; §2 sources the value as 'the project's runner default concurrency'. Verified by grep: the phrase appears only inside run-resource-claims.md (three times), and no declaration surface anywhere — slot-isolation.md, dev-server-lifecycle.md, readiness-check.md, setup — declares a pool. §2 simultaneously promises that a project declaring nothing is fully supported and never blocked. Three names for the same number ('runner pool', 'runner default concurrency', 'the project's runner default') with no statement they are the same. Breaking scenario: two actors at `workers: 4` on a project that declares nothing — one agent guesses pool = CPU count and dispatches both, another treats the unknown pool as §1's 'an unknown' and serializes. Two competent agents, opposite dispatch decisions from the same text; §3's absent-key rule covers an unknown CLAIM, not an unknown POOL. Corroborated live: this round's driver wrote `workers: 1` 'against a pool of 32', having guessed the pool from `nproc` — exactly the guess the finding predicts." }, { "id": "CR-6", "category": "in-scope-blocking", "severity": "Medium", "summary": "§7's YAML→JSON step quotes only keys, so a conforming claim block with unquoted values produces invalid JSON.", "reasoning": "Executed: `claims: {database: [app_test], port: [4080-4089], workers: 1, external: []}` — flat-YAML-safe by the contract's own definition (scalars and flat string lists; nothing mandates quoting), and journal-template.md's template shows bare `[...]` placeholders rather than quoted examples — converts to {\"database\": [app_test], ...} and jq reports 'Invalid numeric literal at line 1, column 23'. The recipe therefore works only when every value happens to be double-quoted, which no document requires. At least this failure is loud, unlike CR-1. Same section and same fix pass as CR-1, which is why it is grouped as blocking rather than demoted." }, { "id": "CR-7", "category": "in-scope-deferrable", "severity": "Medium", "summary": "`SCAN=/tmp/dispatch-scan.txt` — a fixed, predictable path in a normative recipe whose own subject guarantees concurrent execution.", "reasoning": "Written with plain `>`, which follows a pre-existing symlink rather than refusing on one (CWE-377/CWE-59). The concurrency half matters more than the symlink half: two actors triaging in the same run — which this document exists to make routine — race on one scan file, so the anti-contention procedure's own tooling is contended. The fixed-/tmp idiom is a house pattern (10 other sites across promote, integrate, rebase-onto-base, requirements-from-deferred), but those are single-writer moments — one skill writing one payload for one helper call — so this is not the house pattern replicated and does not qualify as pre-existing. scripts/lint-conventions.sh in this same diff does it correctly: scratch=\"$(mktemp)\" with a trap. Found by both Static Security and the Bug Hunter.", "proposed_action": "fix-in-this-feature", "fix_cost": "trivial", "feature_value": "core", "adjacent_to_blocking": true }, { "id": "CR-8", "category": "in-scope-deferrable", "severity": "Medium", "summary": "The record shape specifies a timestamp FORMAT but never says to read the clock, and does not pin a single UTC offset.", "reasoning": "DISPATCH and RELEASE both say `timestamp: [ISO 8601]`. An LLM driver composing journal entries as prose estimates the value, and nothing detects the drift. Demonstrated live in this round: four entries were hand-estimated, three landed 2-6 minutes ahead of the real clock, and the mutation battery's DISPATCH/RELEASE pair is inverted against wall time — a negative-length window. It surfaced only because the driver ran `date` for an unrelated reason. §7 computes each actor's window as [DISPATCH ts, RELEASE ts) and answers contention by intersecting windows, so estimated stamps give wrong answers in both directions. The journal is append-only by contract, so drift cannot be corrected in place — prevention is the whole of the fix. Bug Hunter L11 adds the second half: ISO 8601 permits mixed UTC offsets, which do not compare lexically, and nothing pins the journal to one.", "proposed_action": "fix-in-this-feature", "fix_cost": "trivial", "feature_value": "core", "adjacent_to_blocking": false }, { "id": "CR-9", "category": "in-scope-deferrable", "severity": "Medium", "summary": "The `/dev:develop` consumer omits the solo-actor claim rule AC-2 requires of it, and never mentions the dispatch record at all.", "reasoning": "develop/SKILL.md:110's added sentence triggers only on concurrency ('before dispatching units concurrently, resolve what each one will own'). qa-playbook.md:50 requires the claims block 'including when it is the only actor the round dispatches', and AC-2's verification approach names BOTH consumers for exactly that property. A single-unit wave — or the single-worktree sequential fallback, which §3.1's own text makes the majority case — therefore dispatches suite-running Implementers with no claims and no DISPATCH entries, so a later 'was anything else running?' against a develop-phase result has no record to ask. The Spec Checker judged this acceptable on the grounds that the contract's own rule is unconditional and restating it would risk AC-14; the Bug Hunter judged it a gap. The lead sides with the Bug Hunter: AC-2 names both consumers explicitly, and a citation that scopes itself to the concurrent case is narrower than the rule it cites — the fix is to widen the trigger, which needs no restatement.", "proposed_action": "fix-in-this-feature", "fix_cost": "trivial", "feature_value": "core", "adjacent_to_blocking": false }, { "id": "CR-10", "category": "in-scope-deferrable", "severity": "Medium", "summary": "`overran_claim` is a bare boolean, so the durable record never says WHAT was overrun — and §7 step 4's scope for it is ambiguous.", "reasoning": "§5 puts the naming of overrun resources in the actor's REPORT, but triage (§7) reads the JOURNAL, and §9's whole point is triage happening late, after transient reports are gone. The consequence is visible in §7 step 4's blanket rule — 'any RELEASE carrying overran_claim: true means the result was contended' — which is blanket precisely because a boolean cannot support a resource-overlap test. The optional free-prose Note is not a contract. Second half: is that 'any' bounded by step 3's window intersection, or global to a journal explicitly 'carried across every phase of the feature'? The global reading voids results against overruns that provably could not have touched them; the window reading contradicts the plain text. Both readings are defensible, which is the defect.", "proposed_action": "fix-in-this-feature", "fix_cost": "small", "feature_value": "core", "adjacent_to_blocking": false }, { "id": "CR-11", "category": "in-scope-deferrable", "severity": "Medium", "summary": "The scope sentence promises 'any set of concurrent actors', but the mechanism is strictly intra-driver and cannot see a second driver.", "reasoning": "Claims live in briefs one driver writes, comparison happens inside that driver, and the record is per-feature ($FEATURE_FOLDER/dispatch-journal.md). Two feature sessions running in parallel on one project — this repo's own documented operating model, per CLAUDE.md §Parallel sessions — each dispatch actors claiming the same unslotted default test database. Each driver compares only its own dispatches, finds no overlap, and each journal's §7 scan later certifies 'uncontended': a false negative produced BY the record rather than despite it. This is not in the Non-Goals list; the nearest exclusion is 'contention by actors that never claimed anything', and these actors did claim, in another journal. The honest fix is to narrow the scope sentence or name the cross-driver case as a non-goal — not to build cross-driver machinery, which requirements ruled out.", "proposed_action": "fix-in-this-feature", "fix_cost": "small", "feature_value": "core", "adjacent_to_blocking": false }, { "id": "CR-12", "category": "in-scope-deferrable", "severity": "Medium", "summary": "§5 equates 'the actor's report arrives' with the resources being free, which is false when the suite leaves stragglers.", "reasoning": "A suite that spawns a watch-mode runner or orphans a dev server leaves the child holding the port or database after RELEASE has been honestly written with ended_by: report. The next actor is dispatched onto 'released' resources, contends, and §7 later finds beautifully serialized windows — the record certifies as uncontended a contention the model itself created. The server half is arguably covered by dev-server-lifecycle re-verification; runner stragglers are not, and nothing in §5 makes release conditional on the resources actually being quiesced.", "proposed_action": "fix-in-this-feature", "fix_cost": "small", "feature_value": "incidental", "adjacent_to_blocking": false }, { "id": "CR-13", "category": "in-scope-deferrable", "severity": "Medium", "summary": "Who obtains 'sole ownership' for a void re-run is unassigned, and the three documents that mention it point at three different actors.", "reasoning": "validate-workflow.md tells the domain VALIDATOR to re-run under sole ownership before classifying; run-resource-claims §8.1 states it agentlessly; fix-workflow gives the re-run to the FIXER. But only the DRIVER controls dispatch, holds the journal, and can guarantee nothing else is in flight — a validator cannot serialize its siblings. Breaking scenario: the validator scans the journal, sees the other actor released, re-runs — while the driver, following its own half of the contract, dispatches the next round's fixer whose claims were compared only against dispatched actors, the validator's re-run being invisible because its DISPATCH belongs to the original run. A second contended result, produced by the remedy.", "proposed_action": "fix-in-this-feature", "fix_cost": "small", "feature_value": "core", "adjacent_to_blocking": false }, { "id": "CR-14", "category": "in-scope-deferrable", "severity": "Medium", "summary": "The new gate section is deliberately not fence-aware, contradicting an explicit SREQ constraint and a CLAUDE.md convention.", "reasoning": "The SREQ's Constraints say 'scripts/lint-conventions.sh is repo-local and fence-aware; new checks must reuse its existing fence tracker rather than line-regexing', and CLAUDE.md carries the same rule with the #50 evidence behind it. The implementation line-regexes and argues its way out in a code comment. The comment's reasoning is genuinely good for the citation checks — a fenced example that restates the rule is a restatement just the same — but the anchor-UNIQUENESS scan is the half where it bites: an anchor phrase appearing inside a fenced counter-example or a quoted 'do NOT write this' illustration in a consumer would be flagged, which is the false-positive class the fence tracker exists to prevent. Worth a recorded decision either way; the deviation currently lives only in a code comment, so a future reader cannot tell it was considered.", "proposed_action": "defer-to-issue", "fix_cost": "substantial", "feature_value": "incidental", "adjacent_to_blocking": false }, { "id": "CR-15", "category": "in-scope-deferrable", "severity": "Low", "summary": "All 17 contract scenarios build synthetic fixture documents instead of copying and mutating the real, already-landed ones.", "reasoning": "make_claims_tree and its write_rrc_* helpers hand-author minimal fake versions of seven documents that already exist in the repo with real, much longer prose. None of the 17 scenarios copies-and-mutates the real files the way test-plugin-gates.sh's make_lint_copy does. This is the pattern CLAUDE.md calls the worst case — a fixture standing in for content the repo already holds — and it is exactly the shape that would miss a wrapped anchor in the REAL document, which is this feature's own recorded learning. Partly answered empirically this round: the driver's 20-mutation battery mutated the REAL documents and every check fired correctly with the specific message, so today's fixtures happen to encode the right assumptions. That is evidence about today, not about the design. The existing clean-tree control does run against the real tree, but that protection is coincidental to this design rather than provided by it — and per CR-4 it is one file-deletion from being defeated.", "proposed_action": "defer-to-issue", "fix_cost": "substantial", "feature_value": "incidental", "adjacent_to_blocking": false }, { "id": "CR-16", "category": "in-scope-deferrable", "severity": "Low", "summary": "Three defensive 'file is missing' guards in the gate are exercised in neither direction.", "reasoning": "lint-conventions.sh's 'AC-14 consumer file is missing', 'test-plan.v1.md is missing' and 'readiness/setup surface is missing' branches have no MSG_ constant and no scenario. No scenario deletes qa-playbook.md, develop/SKILL.md, test-plan.v1.md, readiness-check.md or setup/SKILL.md; the AC-16 inbound scenario overwrites content rather than deleting the file, so only the elif branch is reached. A bug making one of these guards wrongly fire, or wrongly stay silent on a genuinely missing file, goes undetected in both directions. The driver's own mutation battery covers the canonical-doc deletion case but not these three.", "proposed_action": "fix-in-this-feature", "fix_cost": "small", "feature_value": "incidental", "adjacent_to_blocking": false }, { "id": "CR-17", "category": "in-scope-deferrable", "severity": "Low", "summary": "Two consumers paraphrase the rule they cite, and the paraphrases carry no gate anchor — so they run under AC-14's mechanical floor.", "reasoning": "qa-playbook.md restates the remedy pair and the void classification; worktree-discipline.md restates both void causes while declaring itself 'a pointer, not a second copy'. Neither paraphrase contains one of the six anchors, so the uniqueness check cannot see them — this is precisely the drift channel the SREQ says the gate exists for, operating below the gate's floor. The paraphrases have already drifted slightly: qa-playbook's version triggers on 'where they would overlap', omitting the unknown-and-malformed ⇒ serialize half of §1. The Spec Checker independently flagged validate-workflow.md:54 as the same shape. Whether summary-then-cite is a defect or good writing is a judgement call, but the measured drift is not.", "proposed_action": "fix-in-this-feature", "fix_cost": "small", "feature_value": "core", "adjacent_to_blocking": false }, { "id": "CR-18", "category": "in-scope-deferrable", "severity": "Low", "summary": "The `ended_by` timeout check is line-scoped and value-literal, so a reformat or a new third value passes it.", "reasoning": "The check inspects only lines containing `ended_by:` and greps for timeout|elapsed|silence. Reformat journal-template.md so the enum wraps with `timeout` on the following line and the gate passes a document that admits a timeout — the inverse of this repo's own wrapped-anchor learning, which was recorded from this very feature. Equally, a new third value that is not literally one of those three words (`assumed-dead`, `gave-up`) passes. AC-7 is the criterion this weakens.", "proposed_action": "fix-in-this-feature", "fix_cost": "small", "feature_value": "incidental", "adjacent_to_blocking": false }, { "id": "CR-19", "category": "in-scope-deferrable", "severity": "Low", "summary": "Actor ids are not required to be unique per dispatch, so RELEASE-to-DISPATCH pairing is undefined for a repeated role.", "reasoning": "RELEASE's actor 'must match an earlier DISPATCH entry', but nothing requires ids unique per dispatch. A fixer dispatched in rounds 1 and 3 under the same role name yields two DISPATCH entries and two RELEASEs, and the pairing rule — nearest-following, first-unmatched, something else — is unstated. A mispaired window flips a contention verdict. Observable in this round's own journal, where role names are stable strings.", "proposed_action": "fix-in-this-feature", "fix_cost": "small", "feature_value": "incidental", "adjacent_to_blocking": false }, { "id": "CR-20", "category": "in-scope-deferrable", "severity": "Low", "summary": "`ended_by` has no value for a deliberate driver-initiated termination.", "reasoning": "Both permitted values are positive events about the actor's own fate — a report, or a death check. A driver that kills a runaway actor must either record the kill as death-check (defensible if kill-then-verify counts, but unstated) or leave the claim held forever. The enum's deliberate two-value design is load-bearing for AC-7, so the fix is a sentence saying which, not a third value.", "proposed_action": "fix-in-this-feature", "fix_cost": "trivial", "feature_value": "incidental", "adjacent_to_blocking": false }, { "id": "CR-21", "category": "in-scope-deferrable", "severity": "Low", "summary": "The four-class vocabulary omits shared writable scratch and cache surfaces, which collide near-universally when two suites run in one checkout.", "reasoning": "Coverage output directories, bundler and test-runner caches (.vite, .next, node_modules/.cache) are not database, port, workers or external. The model's answer is 'the project declares it', but this is precisely the resource nobody thinks to name — no project declares its cache until it has already lost a day to it, which is the same shape as the 18 minutes and five hours this feature was written for. A sentence naming shared writable caches as a candidate class closes it without a new mandatory block.", "proposed_action": "fix-in-this-feature", "fix_cost": "trivial", "feature_value": "incidental", "adjacent_to_blocking": false }, { "id": "CR-22", "category": "in-scope-deferrable", "severity": "Low", "summary": "The late-withdrawal rule assigns the re-post to a domain agent that has usually exited by the time contention is established.", "reasoning": "validate-workflow.md says 'the domain re-posts its report', but §9's whole premise is contention established LATE — after the domain agent released and exited at report time. Whether the driver may re-post on the domain's behalf is unstated, and an agent taking the sentence literally waits for a dead actor. qa-report:v1 is latest-wins, so the mechanism works whoever posts; only the assignment is missing.", "proposed_action": "fix-in-this-feature", "fix_cost": "trivial", "feature_value": "core", "adjacent_to_blocking": false }, { "id": "CR-23", "category": "in-scope-deferrable", "severity": "Low", "summary": "§7 step 1 conflates a missing journal with a journal that has no entries, and lets grep's error text land in the scan file as data.", "reasoning": "grep exits 2 for a missing file and 1 for no matches, and the redirection is `> \"$SCAN\" 2>&1`, so the error message is written INTO the scan file. The same 'no dispatch record' line prints for both cases, then execution continues with a scan file that may contain a grep error line the later sed would treat as data. Cosmetic given CR-1 makes the extraction return nothing anyway, but it is in the same block and should be fixed in the same pass.", "proposed_action": "fix-in-this-feature", "fix_cost": "trivial", "feature_value": "incidental", "adjacent_to_blocking": true }, { "id": "CR-24", "category": "in-scope-deferrable", "severity": "Low", "summary": "The remedy preference is stated in opposite orders in §1 and §4.", "reasoning": "§1 lists serialize first, as the default: 'run the actors one after another, or reassign one of them'. §4 lists the opposite preference: 'reassign one actor onto a different identity, and failing that, serialize'. The two are reconcilable — a default action versus a preference once remediating — but nothing says so, and two agents can read the priority differently. Low impact because both outcomes are safe; it is a legibility defect in a document whose whole job is to be executed identically by different readers.", "proposed_action": "fix-in-this-feature", "fix_cost": "trivial", "feature_value": "incidental", "adjacent_to_blocking": false }, { "id": "CR-25", "category": "in-scope-deferrable", "severity": "Low", "summary": "The QA playbook's control flow has no step at which the dispatch journal is written.", "reasoning": "The DISPATCH/RELEASE duty reaches the QA driver only transitively, through the referenced contract's §6. No numbered playbook step sequences 'append DISPATCH before spawning' or 'append RELEASE once wait-discipline concludes'. This is consistent with the do-not-restate discipline, and a citation is the correct mechanism — but the playbook self-describes as 'the control flow', and a driver working its steps in order never reaches a step where the record gets written. Observed in this round: the driver wrote the journal because it had read the contract directly, not because any playbook step told it to.", "proposed_action": "fix-in-this-feature", "fix_cost": "small", "feature_value": "core", "adjacent_to_blocking": false } ], "artifacts": { "report_path": ".devwork/feature-qa-intra-run-lane-ownership/code-report.md", "journal_path": ".devwork/feature-qa-intra-run-lane-ownership/code-journal.md", "dispatch_journal": ".devwork/feature-qa-intra-run-lane-ownership/dispatch-journal.md" } } ```

jbr870 commented

2026-08-25 13:46:00 +00:00

Author

Owner

{
  "next_state": "qa",
  "produced": [
    {
      "kind": "qa-report",
      "ref": "1405",
      "summary": "code domain, phase=validate — 25 findings, 6 blocking"
    },
    {
      "kind": "qa-report",
      "ref": "1400",
      "summary": "e2e — skipped, project declaration"
    },
    {
      "kind": "qa-report",
      "ref": "1401",
      "summary": "a11y — skipped, project declaration"
    },
    {
      "kind": "qa-report",
      "ref": "1402",
      "summary": "security-browser — skipped, project declaration"
    },
    {
      "kind": "qa-report",
      "ref": "1403",
      "summary": "api — skipped, api_invocation: mode: none"
    },
    {
      "kind": "qa-report",
      "ref": "1404",
      "summary": "security-api — skipped, api_invocation: mode: none"
    }
  ],
  "findings": [
    {
      "category": "in-scope-blocking",
      "severity": "critical",
      "summary": "[code CR-1] §7's triage recipe extracts nothing: `grep -nE` prefixes every line with `LINENUM:`, which the `^claims:` sed anchor can never match.",
      "reasoning": "Reproduced by the driver against this QA round's own dispatch-journal.md (43 captured lines, one real claims entry): the documented step 3 emits 0 lines and exits 0. Dropping `-n` from step 1, changing nothing else, emits {\"database\": [], \"port\": [], \"workers\": 1, \"external\": []}, which `jq -e .` accepts and the §4 filter consumes. The failure is silent — `sed -n` prints nothing and returns success — so a driver following the recipe reads 'no claims in the record' and concludes 'nothing overlapped'. That is a confident false negative, the exact failure mode §7's own prose warns about two paragraphs earlier for `concurrent_with`. AC-9 ('was it contended?' is answered from the run record) rests entirely on this recipe, and its stated verification approach — 'a reader executes the triage scan recipe against a real run's journal' — was evidently never performed. Found independently by the Dependency Verifier and the Bug Hunter.",
      "id": "F-PO-43-4-1"
    },
    {
      "category": "in-scope-blocking",
      "severity": "critical",
      "summary": "[code CR-2] §4's overlap filter returns `[]` — the 'provably disjoint, dispatch concurrently' signal — for four distinct input classes it cannot actually judge.",
      "reasoning": "Executed by the driver against the filter as published. All four return []: (a) two actors claiming the IDENTICAL reversed range \"4080-4079\" (range(4080;4080) is empty, so the claim expands to nothing); (b) two actors claiming the IDENTICAL database identity \"2024-01\" (expand is applied to every identity set, not only `port` as the prose says, so any range-shaped name vanishes); (c) two actors claiming the IDENTICAL project-named class `redis`, which §2 and §4's prose explicitly say is claimable and tested as an identity set, but the filter hardcodes [\"database\",\"port\",\"external\"]; (d) a class present on one side only, which §3 calls unknown-⇒-serialize but the snippet reads as disjoint. The controls pass — genuinely overlapping databases and overlapping port ranges are both reported correctly — which is why this survived. The root is one defect, not four: `[]` is overloaded to mean both 'disjoint' and 'I could not tell', and §1's serialize-by-default posture is inverted by the snippet, which defaults to the permissive answer. This is the dispatch decision itself (AC-1, AC-4). Bug Hunter M1/M7(a)/M7(b)/L12, merged and verified.",
      "id": "F-PO-43-4-2"
    },
    {
      "category": "in-scope-blocking",
      "severity": "high",
      "summary": "[code CR-3] The overrun-disclosure duty reaches no actor: the contract asserts consumers carry it, and no consumer does.",
      "reasoning": "§5 says 'Drivers put the duty in the brief they dispatch (`qa-playbook.md`, `/dev:develop` §3.1)'. Verified by grep: `overran_claim`, 'overrun', 'beyond its claim' and 'disclos' appear nowhere in qa-playbook.md, develop/SKILL.md, fix-workflow.md or validate-workflow.md — the token exists only in run-resource-claims.md itself, journal-template.md's record shape, and the two lint scripts. So the contract makes a claim about documents that do not say what it claims. This is the same gap as F-PO-43-3-1, whose resolution D-PO-43-3-1 chose fix-now and landed b2848fe — but b2848fe added the duty to the contract only; the consumer half of that fix is missing, and the contract's own assertion makes the omission invisible. Corroborated live: this round's driver assembled its spawn briefs from qa-playbook and carried no disclosure duty in any of them, including for its own suite-running actor. Breaking scenario: an actor's suite falls back to the default database when its assigned one is unreachable, reports green, discloses nothing (it was never asked), overran_claim is recorded false, §8.4 never fires, and the contaminated result is citable — with every document obeyed to the letter.",
      "id": "F-PO-43-4-3"
    },
    {
      "category": "in-scope-blocking",
      "severity": "high",
      "summary": "[code CR-4] The in-flight allowance re-arms on regression: with the canonical document deleted, the harness reports 21/21 pass, rc=0.",
      "reasoning": "`rrc_contract_landed()` (test-lint-conventions.sh:144-149) keys on the EXISTENCE of the artefacts the gate judges. Its comment claims it is 'self-retiring with no edit here' — true forwards, false backwards. Delete the canonical doc and the predicate flips back to not-landed; every resulting violation message contains the substring 'run-resource-claims', so the `grep -Fv 'run-resource-claims'` filter finds nothing unexpected and the control PASSES. Measured, not reasoned: copied the real tree to scratch, deleted plugin/skills/_shared/procedures/run-resource-claims.md, ran the harness — 21 passed, 0 failed, rc=0, with the control reporting the in-flight note. Same result for removing `type: dispatch` from journal-template.md. A control planting an UNRELATED violation still fails loudly (20/1, rc=1), so the masking is scoped precisely to this feature's own artefacts — the wrong scope exactly. Mitigating, and why this is High rather than Critical: lint-conventions.sh itself still goes red on the deletion, and it is gate 1/4 of release.sh, so a real deletion still blocks a release; the false green is confined to the self-test tier. The contract has landed, so the predicate and its lenient branch are now dead code whose only reachable behaviour is this masking — delete both and restore the unconditional rc==0 assertion. This also retires the misleading docstring (it says 'every artefact the gate judges' while keying on 2 of ~7) and the over-broad in-flight filter.",
      "id": "F-PO-43-4-4"
    },
    {
      "category": "in-scope-blocking",
      "severity": "high",
      "summary": "[code CR-5] The `workers` budget test has no denominator: nothing in the suite declares the runner pool it compares against.",
      "reasoning": "§4 makes a collision 'sum of concurrently-claimed workers exceeds the project's runner pool'; §2 sources the value as 'the project's runner default concurrency'. Verified by grep: the phrase appears only inside run-resource-claims.md (three times), and no declaration surface anywhere — slot-isolation.md, dev-server-lifecycle.md, readiness-check.md, setup — declares a pool. §2 simultaneously promises that a project declaring nothing is fully supported and never blocked. Three names for the same number ('runner pool', 'runner default concurrency', 'the project's runner default') with no statement they are the same. Breaking scenario: two actors at `workers: 4` on a project that declares nothing — one agent guesses pool = CPU count and dispatches both, another treats the unknown pool as §1's 'an unknown' and serializes. Two competent agents, opposite dispatch decisions from the same text; §3's absent-key rule covers an unknown CLAIM, not an unknown POOL. Corroborated live: this round's driver wrote `workers: 1` 'against a pool of 32', having guessed the pool from `nproc` — exactly the guess the finding predicts.",
      "id": "F-PO-43-4-5"
    },
    {
      "category": "in-scope-blocking",
      "severity": "medium",
      "summary": "[code CR-6] §7's YAML→JSON step quotes only keys, so a conforming claim block with unquoted values produces invalid JSON.",
      "reasoning": "Executed: `claims: {database: [app_test], port: [4080-4089], workers: 1, external: []}` — flat-YAML-safe by the contract's own definition (scalars and flat string lists; nothing mandates quoting), and journal-template.md's template shows bare `[...]` placeholders rather than quoted examples — converts to {\"database\": [app_test], ...} and jq reports 'Invalid numeric literal at line 1, column 23'. The recipe therefore works only when every value happens to be double-quoted, which no document requires. At least this failure is loud, unlike CR-1. Same section and same fix pass as CR-1, which is why it is grouped as blocking rather than demoted.",
      "id": "F-PO-43-4-6"
    },
    {
      "category": "in-scope-deferrable",
      "severity": "medium",
      "summary": "[code CR-7] `SCAN=/tmp/dispatch-scan.txt` — a fixed, predictable path in a normative recipe whose own subject guarantees concurrent execution.",
      "reasoning": "Written with plain `>`, which follows a pre-existing symlink rather than refusing on one (CWE-377/CWE-59). The concurrency half matters more than the symlink half: two actors triaging in the same run — which this document exists to make routine — race on one scan file, so the anti-contention procedure's own tooling is contended. The fixed-/tmp idiom is a house pattern (10 other sites across promote, integrate, rebase-onto-base, requirements-from-deferred), but those are single-writer moments — one skill writing one payload for one helper call — so this is not the house pattern replicated and does not qualify as pre-existing. scripts/lint-conventions.sh in this same diff does it correctly: scratch=\"$(mktemp)\" with a trap. Found by both Static Security and the Bug Hunter.",
      "proposed_action": "fix-in-this-feature",
      "fix_cost": "trivial",
      "feature_value": "core",
      "adjacent_to_blocking": true,
      "id": "F-PO-43-4-7"
    },
    {
      "category": "in-scope-deferrable",
      "severity": "medium",
      "summary": "[code CR-8] The record shape specifies a timestamp FORMAT but never says to read the clock, and does not pin a single UTC offset.",
      "reasoning": "DISPATCH and RELEASE both say `timestamp: [ISO 8601]`. An LLM driver composing journal entries as prose estimates the value, and nothing detects the drift. Demonstrated live in this round: four entries were hand-estimated, three landed 2-6 minutes ahead of the real clock, and the mutation battery's DISPATCH/RELEASE pair is inverted against wall time — a negative-length window. It surfaced only because the driver ran `date` for an unrelated reason. §7 computes each actor's window as [DISPATCH ts, RELEASE ts) and answers contention by intersecting windows, so estimated stamps give wrong answers in both directions. The journal is append-only by contract, so drift cannot be corrected in place — prevention is the whole of the fix. Bug Hunter L11 adds the second half: ISO 8601 permits mixed UTC offsets, which do not compare lexically, and nothing pins the journal to one.",
      "proposed_action": "fix-in-this-feature",
      "fix_cost": "trivial",
      "feature_value": "core",
      "adjacent_to_blocking": false,
      "id": "F-PO-43-4-8"
    },
    {
      "category": "in-scope-deferrable",
      "severity": "medium",
      "summary": "[code CR-9] The `/dev:develop` consumer omits the solo-actor claim rule AC-2 requires of it, and never mentions the dispatch record at all.",
      "reasoning": "develop/SKILL.md:110's added sentence triggers only on concurrency ('before dispatching units concurrently, resolve what each one will own'). qa-playbook.md:50 requires the claims block 'including when it is the only actor the round dispatches', and AC-2's verification approach names BOTH consumers for exactly that property. A single-unit wave — or the single-worktree sequential fallback, which §3.1's own text makes the majority case — therefore dispatches suite-running Implementers with no claims and no DISPATCH entries, so a later 'was anything else running?' against a develop-phase result has no record to ask. The Spec Checker judged this acceptable on the grounds that the contract's own rule is unconditional and restating it would risk AC-14; the Bug Hunter judged it a gap. The lead sides with the Bug Hunter: AC-2 names both consumers explicitly, and a citation that scopes itself to the concurrent case is narrower than the rule it cites — the fix is to widen the trigger, which needs no restatement.",
      "proposed_action": "fix-in-this-feature",
      "fix_cost": "trivial",
      "feature_value": "core",
      "adjacent_to_blocking": false,
      "id": "F-PO-43-4-9"
    },
    {
      "category": "in-scope-deferrable",
      "severity": "medium",
      "summary": "[code CR-10] `overran_claim` is a bare boolean, so the durable record never says WHAT was overrun — and §7 step 4's scope for it is ambiguous.",
      "reasoning": "§5 puts the naming of overrun resources in the actor's REPORT, but triage (§7) reads the JOURNAL, and §9's whole point is triage happening late, after transient reports are gone. The consequence is visible in §7 step 4's blanket rule — 'any RELEASE carrying overran_claim: true means the result was contended' — which is blanket precisely because a boolean cannot support a resource-overlap test. The optional free-prose Note is not a contract. Second half: is that 'any' bounded by step 3's window intersection, or global to a journal explicitly 'carried across every phase of the feature'? The global reading voids results against overruns that provably could not have touched them; the window reading contradicts the plain text. Both readings are defensible, which is the defect.",
      "proposed_action": "fix-in-this-feature",
      "fix_cost": "small",
      "feature_value": "core",
      "adjacent_to_blocking": false,
      "id": "F-PO-43-4-10"
    },
    {
      "category": "in-scope-deferrable",
      "severity": "medium",
      "summary": "[code CR-11] The scope sentence promises 'any set of concurrent actors', but the mechanism is strictly intra-driver and cannot see a second driver.",
      "reasoning": "Claims live in briefs one driver writes, comparison happens inside that driver, and the record is per-feature ($FEATURE_FOLDER/dispatch-journal.md). Two feature sessions running in parallel on one project — this repo's own documented operating model, per CLAUDE.md §Parallel sessions — each dispatch actors claiming the same unslotted default test database. Each driver compares only its own dispatches, finds no overlap, and each journal's §7 scan later certifies 'uncontended': a false negative produced BY the record rather than despite it. This is not in the Non-Goals list; the nearest exclusion is 'contention by actors that never claimed anything', and these actors did claim, in another journal. The honest fix is to narrow the scope sentence or name the cross-driver case as a non-goal — not to build cross-driver machinery, which requirements ruled out.",
      "proposed_action": "fix-in-this-feature",
      "fix_cost": "small",
      "feature_value": "core",
      "adjacent_to_blocking": false,
      "id": "F-PO-43-4-11"
    },
    {
      "category": "in-scope-deferrable",
      "severity": "medium",
      "summary": "[code CR-12] §5 equates 'the actor's report arrives' with the resources being free, which is false when the suite leaves stragglers.",
      "reasoning": "A suite that spawns a watch-mode runner or orphans a dev server leaves the child holding the port or database after RELEASE has been honestly written with ended_by: report. The next actor is dispatched onto 'released' resources, contends, and §7 later finds beautifully serialized windows — the record certifies as uncontended a contention the model itself created. The server half is arguably covered by dev-server-lifecycle re-verification; runner stragglers are not, and nothing in §5 makes release conditional on the resources actually being quiesced.",
      "proposed_action": "fix-in-this-feature",
      "fix_cost": "small",
      "feature_value": "incidental",
      "adjacent_to_blocking": false,
      "id": "F-PO-43-4-12"
    },
    {
      "category": "in-scope-deferrable",
      "severity": "medium",
      "summary": "[code CR-13] Who obtains 'sole ownership' for a void re-run is unassigned, and the three documents that mention it point at three different actors.",
      "reasoning": "validate-workflow.md tells the domain VALIDATOR to re-run under sole ownership before classifying; run-resource-claims §8.1 states it agentlessly; fix-workflow gives the re-run to the FIXER. But only the DRIVER controls dispatch, holds the journal, and can guarantee nothing else is in flight — a validator cannot serialize its siblings. Breaking scenario: the validator scans the journal, sees the other actor released, re-runs — while the driver, following its own half of the contract, dispatches the next round's fixer whose claims were compared only against dispatched actors, the validator's re-run being invisible because its DISPATCH belongs to the original run. A second contended result, produced by the remedy.",
      "proposed_action": "fix-in-this-feature",
      "fix_cost": "small",
      "feature_value": "core",
      "adjacent_to_blocking": false,
      "id": "F-PO-43-4-13"
    },
    {
      "category": "in-scope-deferrable",
      "severity": "medium",
      "summary": "[code CR-14] The new gate section is deliberately not fence-aware, contradicting an explicit SREQ constraint and a CLAUDE.md convention.",
      "reasoning": "The SREQ's Constraints say 'scripts/lint-conventions.sh is repo-local and fence-aware; new checks must reuse its existing fence tracker rather than line-regexing', and CLAUDE.md carries the same rule with the #50 evidence behind it. The implementation line-regexes and argues its way out in a code comment. The comment's reasoning is genuinely good for the citation checks — a fenced example that restates the rule is a restatement just the same — but the anchor-UNIQUENESS scan is the half where it bites: an anchor phrase appearing inside a fenced counter-example or a quoted 'do NOT write this' illustration in a consumer would be flagged, which is the false-positive class the fence tracker exists to prevent. Worth a recorded decision either way; the deviation currently lives only in a code comment, so a future reader cannot tell it was considered.",
      "proposed_action": "defer-to-issue",
      "fix_cost": "substantial",
      "feature_value": "incidental",
      "adjacent_to_blocking": false,
      "id": "F-PO-43-4-14"
    },
    {
      "category": "in-scope-deferrable",
      "severity": "low",
      "summary": "[code CR-15] All 17 contract scenarios build synthetic fixture documents instead of copying and mutating the real, already-landed ones.",
      "reasoning": "make_claims_tree and its write_rrc_* helpers hand-author minimal fake versions of seven documents that already exist in the repo with real, much longer prose. None of the 17 scenarios copies-and-mutates the real files the way test-plugin-gates.sh's make_lint_copy does. This is the pattern CLAUDE.md calls the worst case — a fixture standing in for content the repo already holds — and it is exactly the shape that would miss a wrapped anchor in the REAL document, which is this feature's own recorded learning. Partly answered empirically this round: the driver's 20-mutation battery mutated the REAL documents and every check fired correctly with the specific message, so today's fixtures happen to encode the right assumptions. That is evidence about today, not about the design. The existing clean-tree control does run against the real tree, but that protection is coincidental to this design rather than provided by it — and per CR-4 it is one file-deletion from being defeated.",
      "proposed_action": "defer-to-issue",
      "fix_cost": "substantial",
      "feature_value": "incidental",
      "adjacent_to_blocking": false,
      "id": "F-PO-43-4-15"
    },
    {
      "category": "in-scope-deferrable",
      "severity": "low",
      "summary": "[code CR-16] Three defensive 'file is missing' guards in the gate are exercised in neither direction.",
      "reasoning": "lint-conventions.sh's 'AC-14 consumer file is missing', 'test-plan.v1.md is missing' and 'readiness/setup surface is missing' branches have no MSG_ constant and no scenario. No scenario deletes qa-playbook.md, develop/SKILL.md, test-plan.v1.md, readiness-check.md or setup/SKILL.md; the AC-16 inbound scenario overwrites content rather than deleting the file, so only the elif branch is reached. A bug making one of these guards wrongly fire, or wrongly stay silent on a genuinely missing file, goes undetected in both directions. The driver's own mutation battery covers the canonical-doc deletion case but not these three.",
      "proposed_action": "fix-in-this-feature",
      "fix_cost": "small",
      "feature_value": "incidental",
      "adjacent_to_blocking": false,
      "id": "F-PO-43-4-16"
    },
    {
      "category": "in-scope-deferrable",
      "severity": "low",
      "summary": "[code CR-17] Two consumers paraphrase the rule they cite, and the paraphrases carry no gate anchor — so they run under AC-14's mechanical floor.",
      "reasoning": "qa-playbook.md restates the remedy pair and the void classification; worktree-discipline.md restates both void causes while declaring itself 'a pointer, not a second copy'. Neither paraphrase contains one of the six anchors, so the uniqueness check cannot see them — this is precisely the drift channel the SREQ says the gate exists for, operating below the gate's floor. The paraphrases have already drifted slightly: qa-playbook's version triggers on 'where they would overlap', omitting the unknown-and-malformed ⇒ serialize half of §1. The Spec Checker independently flagged validate-workflow.md:54 as the same shape. Whether summary-then-cite is a defect or good writing is a judgement call, but the measured drift is not.",
      "proposed_action": "fix-in-this-feature",
      "fix_cost": "small",
      "feature_value": "core",
      "adjacent_to_blocking": false,
      "id": "F-PO-43-4-17"
    },
    {
      "category": "in-scope-deferrable",
      "severity": "low",
      "summary": "[code CR-18] The `ended_by` timeout check is line-scoped and value-literal, so a reformat or a new third value passes it.",
      "reasoning": "The check inspects only lines containing `ended_by:` and greps for timeout|elapsed|silence. Reformat journal-template.md so the enum wraps with `timeout` on the following line and the gate passes a document that admits a timeout — the inverse of this repo's own wrapped-anchor learning, which was recorded from this very feature. Equally, a new third value that is not literally one of those three words (`assumed-dead`, `gave-up`) passes. AC-7 is the criterion this weakens.",
      "proposed_action": "fix-in-this-feature",
      "fix_cost": "small",
      "feature_value": "incidental",
      "adjacent_to_blocking": false,
      "id": "F-PO-43-4-18"
    },
    {
      "category": "in-scope-deferrable",
      "severity": "low",
      "summary": "[code CR-19] Actor ids are not required to be unique per dispatch, so RELEASE-to-DISPATCH pairing is undefined for a repeated role.",
      "reasoning": "RELEASE's actor 'must match an earlier DISPATCH entry', but nothing requires ids unique per dispatch. A fixer dispatched in rounds 1 and 3 under the same role name yields two DISPATCH entries and two RELEASEs, and the pairing rule — nearest-following, first-unmatched, something else — is unstated. A mispaired window flips a contention verdict. Observable in this round's own journal, where role names are stable strings.",
      "proposed_action": "fix-in-this-feature",
      "fix_cost": "small",
      "feature_value": "incidental",
      "adjacent_to_blocking": false,
      "id": "F-PO-43-4-19"
    },
    {
      "category": "in-scope-deferrable",
      "severity": "low",
      "summary": "[code CR-20] `ended_by` has no value for a deliberate driver-initiated termination.",
      "reasoning": "Both permitted values are positive events about the actor's own fate — a report, or a death check. A driver that kills a runaway actor must either record the kill as death-check (defensible if kill-then-verify counts, but unstated) or leave the claim held forever. The enum's deliberate two-value design is load-bearing for AC-7, so the fix is a sentence saying which, not a third value.",
      "proposed_action": "fix-in-this-feature",
      "fix_cost": "trivial",
      "feature_value": "incidental",
      "adjacent_to_blocking": false,
      "id": "F-PO-43-4-20"
    },
    {
      "category": "in-scope-deferrable",
      "severity": "low",
      "summary": "[code CR-21] The four-class vocabulary omits shared writable scratch and cache surfaces, which collide near-universally when two suites run in one checkout.",
      "reasoning": "Coverage output directories, bundler and test-runner caches (.vite, .next, node_modules/.cache) are not database, port, workers or external. The model's answer is 'the project declares it', but this is precisely the resource nobody thinks to name — no project declares its cache until it has already lost a day to it, which is the same shape as the 18 minutes and five hours this feature was written for. A sentence naming shared writable caches as a candidate class closes it without a new mandatory block.",
      "proposed_action": "fix-in-this-feature",
      "fix_cost": "trivial",
      "feature_value": "incidental",
      "adjacent_to_blocking": false,
      "id": "F-PO-43-4-21"
    },
    {
      "category": "in-scope-deferrable",
      "severity": "low",
      "summary": "[code CR-22] The late-withdrawal rule assigns the re-post to a domain agent that has usually exited by the time contention is established.",
      "reasoning": "validate-workflow.md says 'the domain re-posts its report', but §9's whole premise is contention established LATE — after the domain agent released and exited at report time. Whether the driver may re-post on the domain's behalf is unstated, and an agent taking the sentence literally waits for a dead actor. qa-report:v1 is latest-wins, so the mechanism works whoever posts; only the assignment is missing.",
      "proposed_action": "fix-in-this-feature",
      "fix_cost": "trivial",
      "feature_value": "core",
      "adjacent_to_blocking": false,
      "id": "F-PO-43-4-22"
    },
    {
      "category": "in-scope-deferrable",
      "severity": "low",
      "summary": "[code CR-23] §7 step 1 conflates a missing journal with a journal that has no entries, and lets grep's error text land in the scan file as data.",
      "reasoning": "grep exits 2 for a missing file and 1 for no matches, and the redirection is `> \"$SCAN\" 2>&1`, so the error message is written INTO the scan file. The same 'no dispatch record' line prints for both cases, then execution continues with a scan file that may contain a grep error line the later sed would treat as data. Cosmetic given CR-1 makes the extraction return nothing anyway, but it is in the same block and should be fixed in the same pass.",
      "proposed_action": "fix-in-this-feature",
      "fix_cost": "trivial",
      "feature_value": "incidental",
      "adjacent_to_blocking": true,
      "id": "F-PO-43-4-23"
    },
    {
      "category": "in-scope-deferrable",
      "severity": "low",
      "summary": "[code CR-24] The remedy preference is stated in opposite orders in §1 and §4.",
      "reasoning": "§1 lists serialize first, as the default: 'run the actors one after another, or reassign one of them'. §4 lists the opposite preference: 'reassign one actor onto a different identity, and failing that, serialize'. The two are reconcilable — a default action versus a preference once remediating — but nothing says so, and two agents can read the priority differently. Low impact because both outcomes are safe; it is a legibility defect in a document whose whole job is to be executed identically by different readers.",
      "proposed_action": "fix-in-this-feature",
      "fix_cost": "trivial",
      "feature_value": "incidental",
      "adjacent_to_blocking": false,
      "id": "F-PO-43-4-24"
    },
    {
      "category": "in-scope-deferrable",
      "severity": "low",
      "summary": "[code CR-25] The QA playbook's control flow has no step at which the dispatch journal is written.",
      "reasoning": "The DISPATCH/RELEASE duty reaches the QA driver only transitively, through the referenced contract's §6. No numbered playbook step sequences 'append DISPATCH before spawning' or 'append RELEASE once wait-discipline concludes'. This is consistent with the do-not-restate discipline, and a citation is the correct mechanism — but the playbook self-describes as 'the control flow', and a driver working its steps in order never reaches a step where the record gets written. Observed in this round: the driver wrote the journal because it had read the contract directly, not because any playbook step told it to.",
      "proposed_action": "fix-in-this-feature",
      "fix_cost": "small",
      "feature_value": "core",
      "adjacent_to_blocking": false,
      "id": "F-PO-43-4-25"
    }
  ],
  "pending_decisions": [
    {
      "id": "D-PO-43-4-1",
      "type": "scope-disposition",
      "blocking": false,
      "question": "[CR-7] `SCAN=/tmp/dispatch-scan.txt` — a fixed, predictable path in a normative recipe whose own subject guarantees concurrent execution. — fix now, spawn a follow-up issue, or accept?",
      "options": [
        "fix-now",
        "defer-to-issue",
        "accept"
      ],
      "recommended": "fix-now",
      "finding_ref": "F-PO-43-4-7",
      "reasoning": "Computed by disposition-recommend.sh from fix_cost=trivial, feature_value=core, adjacent_to_blocking=true, category=in-scope-deferrable. See qa-report:v1 (domain=code, phase=validate) comment 1405 and .devwork/feature-qa-intra-run-lane-ownership/code-report.md for the full reasoning and the evidence behind this finding."
    },
    {
      "id": "D-PO-43-4-2",
      "type": "scope-disposition",
      "blocking": false,
      "question": "[CR-8] The record shape specifies a timestamp FORMAT but never says to read the clock, and does not pin a single UTC offset. — fix now, spawn a follow-up issue, or accept?",
      "options": [
        "fix-now",
        "defer-to-issue",
        "accept"
      ],
      "recommended": "fix-now",
      "finding_ref": "F-PO-43-4-8",
      "reasoning": "Computed by disposition-recommend.sh from fix_cost=trivial, feature_value=core, adjacent_to_blocking=false, category=in-scope-deferrable. See qa-report:v1 (domain=code, phase=validate) comment 1405 and .devwork/feature-qa-intra-run-lane-ownership/code-report.md for the full reasoning and the evidence behind this finding."
    },
    {
      "id": "D-PO-43-4-3",
      "type": "scope-disposition",
      "blocking": false,
      "question": "[CR-9] The `/dev:develop` consumer omits the solo-actor claim rule AC-2 requires of it, and never mentions the dispatch record at all. — fix now, spawn a follow-up issue, or accept?",
      "options": [
        "fix-now",
        "defer-to-issue",
        "accept"
      ],
      "recommended": "fix-now",
      "finding_ref": "F-PO-43-4-9",
      "reasoning": "Computed by disposition-recommend.sh from fix_cost=trivial, feature_value=core, adjacent_to_blocking=false, category=in-scope-deferrable. See qa-report:v1 (domain=code, phase=validate) comment 1405 and .devwork/feature-qa-intra-run-lane-ownership/code-report.md for the full reasoning and the evidence behind this finding."
    },
    {
      "id": "D-PO-43-4-4",
      "type": "scope-disposition",
      "blocking": false,
      "question": "[CR-10] `overran_claim` is a bare boolean, so the durable record never says WHAT was overrun — and §7 step 4's scope for it is ambiguous. — fix now, spawn a follow-up issue, or accept?",
      "options": [
        "fix-now",
        "defer-to-issue",
        "accept"
      ],
      "recommended": "fix-now",
      "finding_ref": "F-PO-43-4-10",
      "reasoning": "Computed by disposition-recommend.sh from fix_cost=small, feature_value=core, adjacent_to_blocking=false, category=in-scope-deferrable. See qa-report:v1 (domain=code, phase=validate) comment 1405 and .devwork/feature-qa-intra-run-lane-ownership/code-report.md for the full reasoning and the evidence behind this finding."
    },
    {
      "id": "D-PO-43-4-5",
      "type": "scope-disposition",
      "blocking": false,
      "question": "[CR-11] The scope sentence promises 'any set of concurrent actors', but the mechanism is strictly intra-driver and cannot see a second driver. — fix now, spawn a follow-up issue, or accept?",
      "options": [
        "fix-now",
        "defer-to-issue",
        "accept"
      ],
      "recommended": "fix-now",
      "finding_ref": "F-PO-43-4-11",
      "reasoning": "Computed by disposition-recommend.sh from fix_cost=small, feature_value=core, adjacent_to_blocking=false, category=in-scope-deferrable. See qa-report:v1 (domain=code, phase=validate) comment 1405 and .devwork/feature-qa-intra-run-lane-ownership/code-report.md for the full reasoning and the evidence behind this finding."
    },
    {
      "id": "D-PO-43-4-6",
      "type": "scope-disposition",
      "blocking": false,
      "question": "[CR-12] §5 equates 'the actor's report arrives' with the resources being free, which is false when the suite leaves stragglers. — fix now, spawn a follow-up issue, or accept?",
      "options": [
        "fix-now",
        "defer-to-issue",
        "accept"
      ],
      "recommended": "fix-now",
      "finding_ref": "F-PO-43-4-12",
      "reasoning": "Computed by disposition-recommend.sh from fix_cost=small, feature_value=incidental, adjacent_to_blocking=false, category=in-scope-deferrable. See qa-report:v1 (domain=code, phase=validate) comment 1405 and .devwork/feature-qa-intra-run-lane-ownership/code-report.md for the full reasoning and the evidence behind this finding."
    },
    {
      "id": "D-PO-43-4-7",
      "type": "scope-disposition",
      "blocking": false,
      "question": "[CR-13] Who obtains 'sole ownership' for a void re-run is unassigned, and the three documents that mention it point at three different actors. — fix now, spawn a follow-up issue, or accept?",
      "options": [
        "fix-now",
        "defer-to-issue",
        "accept"
      ],
      "recommended": "fix-now",
      "finding_ref": "F-PO-43-4-13",
      "reasoning": "Computed by disposition-recommend.sh from fix_cost=small, feature_value=core, adjacent_to_blocking=false, category=in-scope-deferrable. See qa-report:v1 (domain=code, phase=validate) comment 1405 and .devwork/feature-qa-intra-run-lane-ownership/code-report.md for the full reasoning and the evidence behind this finding."
    },
    {
      "id": "D-PO-43-4-8",
      "type": "scope-disposition",
      "blocking": false,
      "question": "[CR-14] The new gate section is deliberately not fence-aware, contradicting an explicit SREQ constraint and a CLAUDE.md convention. — fix now, spawn a follow-up issue, or accept?",
      "options": [
        "fix-now",
        "defer-to-issue",
        "accept"
      ],
      "recommended": "defer-to-issue",
      "finding_ref": "F-PO-43-4-14",
      "reasoning": "Computed by disposition-recommend.sh from fix_cost=substantial, feature_value=incidental, adjacent_to_blocking=false, category=in-scope-deferrable. See qa-report:v1 (domain=code, phase=validate) comment 1405 and .devwork/feature-qa-intra-run-lane-ownership/code-report.md for the full reasoning and the evidence behind this finding."
    },
    {
      "id": "D-PO-43-4-9",
      "type": "scope-disposition",
      "blocking": false,
      "question": "[CR-15] All 17 contract scenarios build synthetic fixture documents instead of copying and mutating the real, already-landed ones. — fix now, spawn a follow-up issue, or accept?",
      "options": [
        "fix-now",
        "defer-to-issue",
        "accept"
      ],
      "recommended": "defer-to-issue",
      "finding_ref": "F-PO-43-4-15",
      "reasoning": "Computed by disposition-recommend.sh from fix_cost=substantial, feature_value=incidental, adjacent_to_blocking=false, category=in-scope-deferrable. See qa-report:v1 (domain=code, phase=validate) comment 1405 and .devwork/feature-qa-intra-run-lane-ownership/code-report.md for the full reasoning and the evidence behind this finding."
    },
    {
      "id": "D-PO-43-4-10",
      "type": "scope-disposition",
      "blocking": false,
      "question": "[CR-16] Three defensive 'file is missing' guards in the gate are exercised in neither direction. — fix now, spawn a follow-up issue, or accept?",
      "options": [
        "fix-now",
        "defer-to-issue",
        "accept"
      ],
      "recommended": "fix-now",
      "finding_ref": "F-PO-43-4-16",
      "reasoning": "Computed by disposition-recommend.sh from fix_cost=small, feature_value=incidental, adjacent_to_blocking=false, category=in-scope-deferrable. See qa-report:v1 (domain=code, phase=validate) comment 1405 and .devwork/feature-qa-intra-run-lane-ownership/code-report.md for the full reasoning and the evidence behind this finding."
    },
    {
      "id": "D-PO-43-4-11",
      "type": "scope-disposition",
      "blocking": false,
      "question": "[CR-17] Two consumers paraphrase the rule they cite, and the paraphrases carry no gate anchor — so they run under AC-14's mechanical floor. — fix now, spawn a follow-up issue, or accept?",
      "options": [
        "fix-now",
        "defer-to-issue",
        "accept"
      ],
      "recommended": "fix-now",
      "finding_ref": "F-PO-43-4-17",
      "reasoning": "Computed by disposition-recommend.sh from fix_cost=small, feature_value=core, adjacent_to_blocking=false, category=in-scope-deferrable. See qa-report:v1 (domain=code, phase=validate) comment 1405 and .devwork/feature-qa-intra-run-lane-ownership/code-report.md for the full reasoning and the evidence behind this finding."
    },
    {
      "id": "D-PO-43-4-12",
      "type": "scope-disposition",
      "blocking": false,
      "question": "[CR-18] The `ended_by` timeout check is line-scoped and value-literal, so a reformat or a new third value passes it. — fix now, spawn a follow-up issue, or accept?",
      "options": [
        "fix-now",
        "defer-to-issue",
        "accept"
      ],
      "recommended": "fix-now",
      "finding_ref": "F-PO-43-4-18",
      "reasoning": "Computed by disposition-recommend.sh from fix_cost=small, feature_value=incidental, adjacent_to_blocking=false, category=in-scope-deferrable. See qa-report:v1 (domain=code, phase=validate) comment 1405 and .devwork/feature-qa-intra-run-lane-ownership/code-report.md for the full reasoning and the evidence behind this finding."
    },
    {
      "id": "D-PO-43-4-13",
      "type": "scope-disposition",
      "blocking": false,
      "question": "[CR-19] Actor ids are not required to be unique per dispatch, so RELEASE-to-DISPATCH pairing is undefined for a repeated role. — fix now, spawn a follow-up issue, or accept?",
      "options": [
        "fix-now",
        "defer-to-issue",
        "accept"
      ],
      "recommended": "fix-now",
      "finding_ref": "F-PO-43-4-19",
      "reasoning": "Computed by disposition-recommend.sh from fix_cost=small, feature_value=incidental, adjacent_to_blocking=false, category=in-scope-deferrable. See qa-report:v1 (domain=code, phase=validate) comment 1405 and .devwork/feature-qa-intra-run-lane-ownership/code-report.md for the full reasoning and the evidence behind this finding."
    },
    {
      "id": "D-PO-43-4-14",
      "type": "scope-disposition",
      "blocking": false,
      "question": "[CR-20] `ended_by` has no value for a deliberate driver-initiated termination. — fix now, spawn a follow-up issue, or accept?",
      "options": [
        "fix-now",
        "defer-to-issue",
        "accept"
      ],
      "recommended": "fix-now",
      "finding_ref": "F-PO-43-4-20",
      "reasoning": "Computed by disposition-recommend.sh from fix_cost=trivial, feature_value=incidental, adjacent_to_blocking=false, category=in-scope-deferrable. See qa-report:v1 (domain=code, phase=validate) comment 1405 and .devwork/feature-qa-intra-run-lane-ownership/code-report.md for the full reasoning and the evidence behind this finding."
    },
    {
      "id": "D-PO-43-4-15",
      "type": "scope-disposition",
      "blocking": false,
      "question": "[CR-21] The four-class vocabulary omits shared writable scratch and cache surfaces, which collide near-universally when two suites run in one checkout. — fix now, spawn a follow-up issue, or accept?",
      "options": [
        "fix-now",
        "defer-to-issue",
        "accept"
      ],
      "recommended": "fix-now",
      "finding_ref": "F-PO-43-4-21",
      "reasoning": "Computed by disposition-recommend.sh from fix_cost=trivial, feature_value=incidental, adjacent_to_blocking=false, category=in-scope-deferrable. See qa-report:v1 (domain=code, phase=validate) comment 1405 and .devwork/feature-qa-intra-run-lane-ownership/code-report.md for the full reasoning and the evidence behind this finding."
    },
    {
      "id": "D-PO-43-4-16",
      "type": "scope-disposition",
      "blocking": false,
      "question": "[CR-22] The late-withdrawal rule assigns the re-post to a domain agent that has usually exited by the time contention is established. — fix now, spawn a follow-up issue, or accept?",
      "options": [
        "fix-now",
        "defer-to-issue",
        "accept"
      ],
      "recommended": "fix-now",
      "finding_ref": "F-PO-43-4-22",
      "reasoning": "Computed by disposition-recommend.sh from fix_cost=trivial, feature_value=core, adjacent_to_blocking=false, category=in-scope-deferrable. See qa-report:v1 (domain=code, phase=validate) comment 1405 and .devwork/feature-qa-intra-run-lane-ownership/code-report.md for the full reasoning and the evidence behind this finding."
    },
    {
      "id": "D-PO-43-4-17",
      "type": "scope-disposition",
      "blocking": false,
      "question": "[CR-23] §7 step 1 conflates a missing journal with a journal that has no entries, and lets grep's error text land in the scan file as data. — fix now, spawn a follow-up issue, or accept?",
      "options": [
        "fix-now",
        "defer-to-issue",
        "accept"
      ],
      "recommended": "fix-now",
      "finding_ref": "F-PO-43-4-23",
      "reasoning": "Computed by disposition-recommend.sh from fix_cost=trivial, feature_value=incidental, adjacent_to_blocking=true, category=in-scope-deferrable. See qa-report:v1 (domain=code, phase=validate) comment 1405 and .devwork/feature-qa-intra-run-lane-ownership/code-report.md for the full reasoning and the evidence behind this finding."
    },
    {
      "id": "D-PO-43-4-18",
      "type": "scope-disposition",
      "blocking": false,
      "question": "[CR-24] The remedy preference is stated in opposite orders in §1 and §4. — fix now, spawn a follow-up issue, or accept?",
      "options": [
        "fix-now",
        "defer-to-issue",
        "accept"
      ],
      "recommended": "fix-now",
      "finding_ref": "F-PO-43-4-24",
      "reasoning": "Computed by disposition-recommend.sh from fix_cost=trivial, feature_value=incidental, adjacent_to_blocking=false, category=in-scope-deferrable. See qa-report:v1 (domain=code, phase=validate) comment 1405 and .devwork/feature-qa-intra-run-lane-ownership/code-report.md for the full reasoning and the evidence behind this finding."
    },
    {
      "id": "D-PO-43-4-19",
      "type": "scope-disposition",
      "blocking": false,
      "question": "[CR-25] The QA playbook's control flow has no step at which the dispatch journal is written. — fix now, spawn a follow-up issue, or accept?",
      "options": [
        "fix-now",
        "defer-to-issue",
        "accept"
      ],
      "recommended": "fix-now",
      "finding_ref": "F-PO-43-4-25",
      "reasoning": "Computed by disposition-recommend.sh from fix_cost=small, feature_value=core, adjacent_to_blocking=false, category=in-scope-deferrable. See qa-report:v1 (domain=code, phase=validate) comment 1405 and .devwork/feature-qa-intra-run-lane-ownership/code-report.md for the full reasoning and the evidence behind this finding."
    }
  ],
  "suite": {
    "source": "git",
    "sha": "70339883b9cba894ee55b394ff6438a8114a7810",
    "dirty": false
  }
}

```json { "next_state": "qa", "produced": [ { "kind": "qa-report", "ref": "1405", "summary": "code domain, phase=validate — 25 findings, 6 blocking" }, { "kind": "qa-report", "ref": "1400", "summary": "e2e — skipped, project declaration" }, { "kind": "qa-report", "ref": "1401", "summary": "a11y — skipped, project declaration" }, { "kind": "qa-report", "ref": "1402", "summary": "security-browser — skipped, project declaration" }, { "kind": "qa-report", "ref": "1403", "summary": "api — skipped, api_invocation: mode: none" }, { "kind": "qa-report", "ref": "1404", "summary": "security-api — skipped, api_invocation: mode: none" } ], "findings": [ { "category": "in-scope-blocking", "severity": "critical", "summary": "[code CR-1] §7's triage recipe extracts nothing: `grep -nE` prefixes every line with `LINENUM:`, which the `^claims:` sed anchor can never match.", "reasoning": "Reproduced by the driver against this QA round's own dispatch-journal.md (43 captured lines, one real claims entry): the documented step 3 emits 0 lines and exits 0. Dropping `-n` from step 1, changing nothing else, emits {\"database\": [], \"port\": [], \"workers\": 1, \"external\": []}, which `jq -e .` accepts and the §4 filter consumes. The failure is silent — `sed -n` prints nothing and returns success — so a driver following the recipe reads 'no claims in the record' and concludes 'nothing overlapped'. That is a confident false negative, the exact failure mode §7's own prose warns about two paragraphs earlier for `concurrent_with`. AC-9 ('was it contended?' is answered from the run record) rests entirely on this recipe, and its stated verification approach — 'a reader executes the triage scan recipe against a real run's journal' — was evidently never performed. Found independently by the Dependency Verifier and the Bug Hunter.", "id": "F-PO-43-4-1" }, { "category": "in-scope-blocking", "severity": "critical", "summary": "[code CR-2] §4's overlap filter returns `[]` — the 'provably disjoint, dispatch concurrently' signal — for four distinct input classes it cannot actually judge.", "reasoning": "Executed by the driver against the filter as published. All four return []: (a) two actors claiming the IDENTICAL reversed range \"4080-4079\" (range(4080;4080) is empty, so the claim expands to nothing); (b) two actors claiming the IDENTICAL database identity \"2024-01\" (expand is applied to every identity set, not only `port` as the prose says, so any range-shaped name vanishes); (c) two actors claiming the IDENTICAL project-named class `redis`, which §2 and §4's prose explicitly say is claimable and tested as an identity set, but the filter hardcodes [\"database\",\"port\",\"external\"]; (d) a class present on one side only, which §3 calls unknown-⇒-serialize but the snippet reads as disjoint. The controls pass — genuinely overlapping databases and overlapping port ranges are both reported correctly — which is why this survived. The root is one defect, not four: `[]` is overloaded to mean both 'disjoint' and 'I could not tell', and §1's serialize-by-default posture is inverted by the snippet, which defaults to the permissive answer. This is the dispatch decision itself (AC-1, AC-4). Bug Hunter M1/M7(a)/M7(b)/L12, merged and verified.", "id": "F-PO-43-4-2" }, { "category": "in-scope-blocking", "severity": "high", "summary": "[code CR-3] The overrun-disclosure duty reaches no actor: the contract asserts consumers carry it, and no consumer does.", "reasoning": "§5 says 'Drivers put the duty in the brief they dispatch (`qa-playbook.md`, `/dev:develop` §3.1)'. Verified by grep: `overran_claim`, 'overrun', 'beyond its claim' and 'disclos' appear nowhere in qa-playbook.md, develop/SKILL.md, fix-workflow.md or validate-workflow.md — the token exists only in run-resource-claims.md itself, journal-template.md's record shape, and the two lint scripts. So the contract makes a claim about documents that do not say what it claims. This is the same gap as F-PO-43-3-1, whose resolution D-PO-43-3-1 chose fix-now and landed b2848fe — but b2848fe added the duty to the contract only; the consumer half of that fix is missing, and the contract's own assertion makes the omission invisible. Corroborated live: this round's driver assembled its spawn briefs from qa-playbook and carried no disclosure duty in any of them, including for its own suite-running actor. Breaking scenario: an actor's suite falls back to the default database when its assigned one is unreachable, reports green, discloses nothing (it was never asked), overran_claim is recorded false, §8.4 never fires, and the contaminated result is citable — with every document obeyed to the letter.", "id": "F-PO-43-4-3" }, { "category": "in-scope-blocking", "severity": "high", "summary": "[code CR-4] The in-flight allowance re-arms on regression: with the canonical document deleted, the harness reports 21/21 pass, rc=0.", "reasoning": "`rrc_contract_landed()` (test-lint-conventions.sh:144-149) keys on the EXISTENCE of the artefacts the gate judges. Its comment claims it is 'self-retiring with no edit here' — true forwards, false backwards. Delete the canonical doc and the predicate flips back to not-landed; every resulting violation message contains the substring 'run-resource-claims', so the `grep -Fv 'run-resource-claims'` filter finds nothing unexpected and the control PASSES. Measured, not reasoned: copied the real tree to scratch, deleted plugin/skills/_shared/procedures/run-resource-claims.md, ran the harness — 21 passed, 0 failed, rc=0, with the control reporting the in-flight note. Same result for removing `type: dispatch` from journal-template.md. A control planting an UNRELATED violation still fails loudly (20/1, rc=1), so the masking is scoped precisely to this feature's own artefacts — the wrong scope exactly. Mitigating, and why this is High rather than Critical: lint-conventions.sh itself still goes red on the deletion, and it is gate 1/4 of release.sh, so a real deletion still blocks a release; the false green is confined to the self-test tier. The contract has landed, so the predicate and its lenient branch are now dead code whose only reachable behaviour is this masking — delete both and restore the unconditional rc==0 assertion. This also retires the misleading docstring (it says 'every artefact the gate judges' while keying on 2 of ~7) and the over-broad in-flight filter.", "id": "F-PO-43-4-4" }, { "category": "in-scope-blocking", "severity": "high", "summary": "[code CR-5] The `workers` budget test has no denominator: nothing in the suite declares the runner pool it compares against.", "reasoning": "§4 makes a collision 'sum of concurrently-claimed workers exceeds the project's runner pool'; §2 sources the value as 'the project's runner default concurrency'. Verified by grep: the phrase appears only inside run-resource-claims.md (three times), and no declaration surface anywhere — slot-isolation.md, dev-server-lifecycle.md, readiness-check.md, setup — declares a pool. §2 simultaneously promises that a project declaring nothing is fully supported and never blocked. Three names for the same number ('runner pool', 'runner default concurrency', 'the project's runner default') with no statement they are the same. Breaking scenario: two actors at `workers: 4` on a project that declares nothing — one agent guesses pool = CPU count and dispatches both, another treats the unknown pool as §1's 'an unknown' and serializes. Two competent agents, opposite dispatch decisions from the same text; §3's absent-key rule covers an unknown CLAIM, not an unknown POOL. Corroborated live: this round's driver wrote `workers: 1` 'against a pool of 32', having guessed the pool from `nproc` — exactly the guess the finding predicts.", "id": "F-PO-43-4-5" }, { "category": "in-scope-blocking", "severity": "medium", "summary": "[code CR-6] §7's YAML→JSON step quotes only keys, so a conforming claim block with unquoted values produces invalid JSON.", "reasoning": "Executed: `claims: {database: [app_test], port: [4080-4089], workers: 1, external: []}` — flat-YAML-safe by the contract's own definition (scalars and flat string lists; nothing mandates quoting), and journal-template.md's template shows bare `[...]` placeholders rather than quoted examples — converts to {\"database\": [app_test], ...} and jq reports 'Invalid numeric literal at line 1, column 23'. The recipe therefore works only when every value happens to be double-quoted, which no document requires. At least this failure is loud, unlike CR-1. Same section and same fix pass as CR-1, which is why it is grouped as blocking rather than demoted.", "id": "F-PO-43-4-6" }, { "category": "in-scope-deferrable", "severity": "medium", "summary": "[code CR-7] `SCAN=/tmp/dispatch-scan.txt` — a fixed, predictable path in a normative recipe whose own subject guarantees concurrent execution.", "reasoning": "Written with plain `>`, which follows a pre-existing symlink rather than refusing on one (CWE-377/CWE-59). The concurrency half matters more than the symlink half: two actors triaging in the same run — which this document exists to make routine — race on one scan file, so the anti-contention procedure's own tooling is contended. The fixed-/tmp idiom is a house pattern (10 other sites across promote, integrate, rebase-onto-base, requirements-from-deferred), but those are single-writer moments — one skill writing one payload for one helper call — so this is not the house pattern replicated and does not qualify as pre-existing. scripts/lint-conventions.sh in this same diff does it correctly: scratch=\"$(mktemp)\" with a trap. Found by both Static Security and the Bug Hunter.", "proposed_action": "fix-in-this-feature", "fix_cost": "trivial", "feature_value": "core", "adjacent_to_blocking": true, "id": "F-PO-43-4-7" }, { "category": "in-scope-deferrable", "severity": "medium", "summary": "[code CR-8] The record shape specifies a timestamp FORMAT but never says to read the clock, and does not pin a single UTC offset.", "reasoning": "DISPATCH and RELEASE both say `timestamp: [ISO 8601]`. An LLM driver composing journal entries as prose estimates the value, and nothing detects the drift. Demonstrated live in this round: four entries were hand-estimated, three landed 2-6 minutes ahead of the real clock, and the mutation battery's DISPATCH/RELEASE pair is inverted against wall time — a negative-length window. It surfaced only because the driver ran `date` for an unrelated reason. §7 computes each actor's window as [DISPATCH ts, RELEASE ts) and answers contention by intersecting windows, so estimated stamps give wrong answers in both directions. The journal is append-only by contract, so drift cannot be corrected in place — prevention is the whole of the fix. Bug Hunter L11 adds the second half: ISO 8601 permits mixed UTC offsets, which do not compare lexically, and nothing pins the journal to one.", "proposed_action": "fix-in-this-feature", "fix_cost": "trivial", "feature_value": "core", "adjacent_to_blocking": false, "id": "F-PO-43-4-8" }, { "category": "in-scope-deferrable", "severity": "medium", "summary": "[code CR-9] The `/dev:develop` consumer omits the solo-actor claim rule AC-2 requires of it, and never mentions the dispatch record at all.", "reasoning": "develop/SKILL.md:110's added sentence triggers only on concurrency ('before dispatching units concurrently, resolve what each one will own'). qa-playbook.md:50 requires the claims block 'including when it is the only actor the round dispatches', and AC-2's verification approach names BOTH consumers for exactly that property. A single-unit wave — or the single-worktree sequential fallback, which §3.1's own text makes the majority case — therefore dispatches suite-running Implementers with no claims and no DISPATCH entries, so a later 'was anything else running?' against a develop-phase result has no record to ask. The Spec Checker judged this acceptable on the grounds that the contract's own rule is unconditional and restating it would risk AC-14; the Bug Hunter judged it a gap. The lead sides with the Bug Hunter: AC-2 names both consumers explicitly, and a citation that scopes itself to the concurrent case is narrower than the rule it cites — the fix is to widen the trigger, which needs no restatement.", "proposed_action": "fix-in-this-feature", "fix_cost": "trivial", "feature_value": "core", "adjacent_to_blocking": false, "id": "F-PO-43-4-9" }, { "category": "in-scope-deferrable", "severity": "medium", "summary": "[code CR-10] `overran_claim` is a bare boolean, so the durable record never says WHAT was overrun — and §7 step 4's scope for it is ambiguous.", "reasoning": "§5 puts the naming of overrun resources in the actor's REPORT, but triage (§7) reads the JOURNAL, and §9's whole point is triage happening late, after transient reports are gone. The consequence is visible in §7 step 4's blanket rule — 'any RELEASE carrying overran_claim: true means the result was contended' — which is blanket precisely because a boolean cannot support a resource-overlap test. The optional free-prose Note is not a contract. Second half: is that 'any' bounded by step 3's window intersection, or global to a journal explicitly 'carried across every phase of the feature'? The global reading voids results against overruns that provably could not have touched them; the window reading contradicts the plain text. Both readings are defensible, which is the defect.", "proposed_action": "fix-in-this-feature", "fix_cost": "small", "feature_value": "core", "adjacent_to_blocking": false, "id": "F-PO-43-4-10" }, { "category": "in-scope-deferrable", "severity": "medium", "summary": "[code CR-11] The scope sentence promises 'any set of concurrent actors', but the mechanism is strictly intra-driver and cannot see a second driver.", "reasoning": "Claims live in briefs one driver writes, comparison happens inside that driver, and the record is per-feature ($FEATURE_FOLDER/dispatch-journal.md). Two feature sessions running in parallel on one project — this repo's own documented operating model, per CLAUDE.md §Parallel sessions — each dispatch actors claiming the same unslotted default test database. Each driver compares only its own dispatches, finds no overlap, and each journal's §7 scan later certifies 'uncontended': a false negative produced BY the record rather than despite it. This is not in the Non-Goals list; the nearest exclusion is 'contention by actors that never claimed anything', and these actors did claim, in another journal. The honest fix is to narrow the scope sentence or name the cross-driver case as a non-goal — not to build cross-driver machinery, which requirements ruled out.", "proposed_action": "fix-in-this-feature", "fix_cost": "small", "feature_value": "core", "adjacent_to_blocking": false, "id": "F-PO-43-4-11" }, { "category": "in-scope-deferrable", "severity": "medium", "summary": "[code CR-12] §5 equates 'the actor's report arrives' with the resources being free, which is false when the suite leaves stragglers.", "reasoning": "A suite that spawns a watch-mode runner or orphans a dev server leaves the child holding the port or database after RELEASE has been honestly written with ended_by: report. The next actor is dispatched onto 'released' resources, contends, and §7 later finds beautifully serialized windows — the record certifies as uncontended a contention the model itself created. The server half is arguably covered by dev-server-lifecycle re-verification; runner stragglers are not, and nothing in §5 makes release conditional on the resources actually being quiesced.", "proposed_action": "fix-in-this-feature", "fix_cost": "small", "feature_value": "incidental", "adjacent_to_blocking": false, "id": "F-PO-43-4-12" }, { "category": "in-scope-deferrable", "severity": "medium", "summary": "[code CR-13] Who obtains 'sole ownership' for a void re-run is unassigned, and the three documents that mention it point at three different actors.", "reasoning": "validate-workflow.md tells the domain VALIDATOR to re-run under sole ownership before classifying; run-resource-claims §8.1 states it agentlessly; fix-workflow gives the re-run to the FIXER. But only the DRIVER controls dispatch, holds the journal, and can guarantee nothing else is in flight — a validator cannot serialize its siblings. Breaking scenario: the validator scans the journal, sees the other actor released, re-runs — while the driver, following its own half of the contract, dispatches the next round's fixer whose claims were compared only against dispatched actors, the validator's re-run being invisible because its DISPATCH belongs to the original run. A second contended result, produced by the remedy.", "proposed_action": "fix-in-this-feature", "fix_cost": "small", "feature_value": "core", "adjacent_to_blocking": false, "id": "F-PO-43-4-13" }, { "category": "in-scope-deferrable", "severity": "medium", "summary": "[code CR-14] The new gate section is deliberately not fence-aware, contradicting an explicit SREQ constraint and a CLAUDE.md convention.", "reasoning": "The SREQ's Constraints say 'scripts/lint-conventions.sh is repo-local and fence-aware; new checks must reuse its existing fence tracker rather than line-regexing', and CLAUDE.md carries the same rule with the #50 evidence behind it. The implementation line-regexes and argues its way out in a code comment. The comment's reasoning is genuinely good for the citation checks — a fenced example that restates the rule is a restatement just the same — but the anchor-UNIQUENESS scan is the half where it bites: an anchor phrase appearing inside a fenced counter-example or a quoted 'do NOT write this' illustration in a consumer would be flagged, which is the false-positive class the fence tracker exists to prevent. Worth a recorded decision either way; the deviation currently lives only in a code comment, so a future reader cannot tell it was considered.", "proposed_action": "defer-to-issue", "fix_cost": "substantial", "feature_value": "incidental", "adjacent_to_blocking": false, "id": "F-PO-43-4-14" }, { "category": "in-scope-deferrable", "severity": "low", "summary": "[code CR-15] All 17 contract scenarios build synthetic fixture documents instead of copying and mutating the real, already-landed ones.", "reasoning": "make_claims_tree and its write_rrc_* helpers hand-author minimal fake versions of seven documents that already exist in the repo with real, much longer prose. None of the 17 scenarios copies-and-mutates the real files the way test-plugin-gates.sh's make_lint_copy does. This is the pattern CLAUDE.md calls the worst case — a fixture standing in for content the repo already holds — and it is exactly the shape that would miss a wrapped anchor in the REAL document, which is this feature's own recorded learning. Partly answered empirically this round: the driver's 20-mutation battery mutated the REAL documents and every check fired correctly with the specific message, so today's fixtures happen to encode the right assumptions. That is evidence about today, not about the design. The existing clean-tree control does run against the real tree, but that protection is coincidental to this design rather than provided by it — and per CR-4 it is one file-deletion from being defeated.", "proposed_action": "defer-to-issue", "fix_cost": "substantial", "feature_value": "incidental", "adjacent_to_blocking": false, "id": "F-PO-43-4-15" }, { "category": "in-scope-deferrable", "severity": "low", "summary": "[code CR-16] Three defensive 'file is missing' guards in the gate are exercised in neither direction.", "reasoning": "lint-conventions.sh's 'AC-14 consumer file is missing', 'test-plan.v1.md is missing' and 'readiness/setup surface is missing' branches have no MSG_ constant and no scenario. No scenario deletes qa-playbook.md, develop/SKILL.md, test-plan.v1.md, readiness-check.md or setup/SKILL.md; the AC-16 inbound scenario overwrites content rather than deleting the file, so only the elif branch is reached. A bug making one of these guards wrongly fire, or wrongly stay silent on a genuinely missing file, goes undetected in both directions. The driver's own mutation battery covers the canonical-doc deletion case but not these three.", "proposed_action": "fix-in-this-feature", "fix_cost": "small", "feature_value": "incidental", "adjacent_to_blocking": false, "id": "F-PO-43-4-16" }, { "category": "in-scope-deferrable", "severity": "low", "summary": "[code CR-17] Two consumers paraphrase the rule they cite, and the paraphrases carry no gate anchor — so they run under AC-14's mechanical floor.", "reasoning": "qa-playbook.md restates the remedy pair and the void classification; worktree-discipline.md restates both void causes while declaring itself 'a pointer, not a second copy'. Neither paraphrase contains one of the six anchors, so the uniqueness check cannot see them — this is precisely the drift channel the SREQ says the gate exists for, operating below the gate's floor. The paraphrases have already drifted slightly: qa-playbook's version triggers on 'where they would overlap', omitting the unknown-and-malformed ⇒ serialize half of §1. The Spec Checker independently flagged validate-workflow.md:54 as the same shape. Whether summary-then-cite is a defect or good writing is a judgement call, but the measured drift is not.", "proposed_action": "fix-in-this-feature", "fix_cost": "small", "feature_value": "core", "adjacent_to_blocking": false, "id": "F-PO-43-4-17" }, { "category": "in-scope-deferrable", "severity": "low", "summary": "[code CR-18] The `ended_by` timeout check is line-scoped and value-literal, so a reformat or a new third value passes it.", "reasoning": "The check inspects only lines containing `ended_by:` and greps for timeout|elapsed|silence. Reformat journal-template.md so the enum wraps with `timeout` on the following line and the gate passes a document that admits a timeout — the inverse of this repo's own wrapped-anchor learning, which was recorded from this very feature. Equally, a new third value that is not literally one of those three words (`assumed-dead`, `gave-up`) passes. AC-7 is the criterion this weakens.", "proposed_action": "fix-in-this-feature", "fix_cost": "small", "feature_value": "incidental", "adjacent_to_blocking": false, "id": "F-PO-43-4-18" }, { "category": "in-scope-deferrable", "severity": "low", "summary": "[code CR-19] Actor ids are not required to be unique per dispatch, so RELEASE-to-DISPATCH pairing is undefined for a repeated role.", "reasoning": "RELEASE's actor 'must match an earlier DISPATCH entry', but nothing requires ids unique per dispatch. A fixer dispatched in rounds 1 and 3 under the same role name yields two DISPATCH entries and two RELEASEs, and the pairing rule — nearest-following, first-unmatched, something else — is unstated. A mispaired window flips a contention verdict. Observable in this round's own journal, where role names are stable strings.", "proposed_action": "fix-in-this-feature", "fix_cost": "small", "feature_value": "incidental", "adjacent_to_blocking": false, "id": "F-PO-43-4-19" }, { "category": "in-scope-deferrable", "severity": "low", "summary": "[code CR-20] `ended_by` has no value for a deliberate driver-initiated termination.", "reasoning": "Both permitted values are positive events about the actor's own fate — a report, or a death check. A driver that kills a runaway actor must either record the kill as death-check (defensible if kill-then-verify counts, but unstated) or leave the claim held forever. The enum's deliberate two-value design is load-bearing for AC-7, so the fix is a sentence saying which, not a third value.", "proposed_action": "fix-in-this-feature", "fix_cost": "trivial", "feature_value": "incidental", "adjacent_to_blocking": false, "id": "F-PO-43-4-20" }, { "category": "in-scope-deferrable", "severity": "low", "summary": "[code CR-21] The four-class vocabulary omits shared writable scratch and cache surfaces, which collide near-universally when two suites run in one checkout.", "reasoning": "Coverage output directories, bundler and test-runner caches (.vite, .next, node_modules/.cache) are not database, port, workers or external. The model's answer is 'the project declares it', but this is precisely the resource nobody thinks to name — no project declares its cache until it has already lost a day to it, which is the same shape as the 18 minutes and five hours this feature was written for. A sentence naming shared writable caches as a candidate class closes it without a new mandatory block.", "proposed_action": "fix-in-this-feature", "fix_cost": "trivial", "feature_value": "incidental", "adjacent_to_blocking": false, "id": "F-PO-43-4-21" }, { "category": "in-scope-deferrable", "severity": "low", "summary": "[code CR-22] The late-withdrawal rule assigns the re-post to a domain agent that has usually exited by the time contention is established.", "reasoning": "validate-workflow.md says 'the domain re-posts its report', but §9's whole premise is contention established LATE — after the domain agent released and exited at report time. Whether the driver may re-post on the domain's behalf is unstated, and an agent taking the sentence literally waits for a dead actor. qa-report:v1 is latest-wins, so the mechanism works whoever posts; only the assignment is missing.", "proposed_action": "fix-in-this-feature", "fix_cost": "trivial", "feature_value": "core", "adjacent_to_blocking": false, "id": "F-PO-43-4-22" }, { "category": "in-scope-deferrable", "severity": "low", "summary": "[code CR-23] §7 step 1 conflates a missing journal with a journal that has no entries, and lets grep's error text land in the scan file as data.", "reasoning": "grep exits 2 for a missing file and 1 for no matches, and the redirection is `> \"$SCAN\" 2>&1`, so the error message is written INTO the scan file. The same 'no dispatch record' line prints for both cases, then execution continues with a scan file that may contain a grep error line the later sed would treat as data. Cosmetic given CR-1 makes the extraction return nothing anyway, but it is in the same block and should be fixed in the same pass.", "proposed_action": "fix-in-this-feature", "fix_cost": "trivial", "feature_value": "incidental", "adjacent_to_blocking": true, "id": "F-PO-43-4-23" }, { "category": "in-scope-deferrable", "severity": "low", "summary": "[code CR-24] The remedy preference is stated in opposite orders in §1 and §4.", "reasoning": "§1 lists serialize first, as the default: 'run the actors one after another, or reassign one of them'. §4 lists the opposite preference: 'reassign one actor onto a different identity, and failing that, serialize'. The two are reconcilable — a default action versus a preference once remediating — but nothing says so, and two agents can read the priority differently. Low impact because both outcomes are safe; it is a legibility defect in a document whose whole job is to be executed identically by different readers.", "proposed_action": "fix-in-this-feature", "fix_cost": "trivial", "feature_value": "incidental", "adjacent_to_blocking": false, "id": "F-PO-43-4-24" }, { "category": "in-scope-deferrable", "severity": "low", "summary": "[code CR-25] The QA playbook's control flow has no step at which the dispatch journal is written.", "reasoning": "The DISPATCH/RELEASE duty reaches the QA driver only transitively, through the referenced contract's §6. No numbered playbook step sequences 'append DISPATCH before spawning' or 'append RELEASE once wait-discipline concludes'. This is consistent with the do-not-restate discipline, and a citation is the correct mechanism — but the playbook self-describes as 'the control flow', and a driver working its steps in order never reaches a step where the record gets written. Observed in this round: the driver wrote the journal because it had read the contract directly, not because any playbook step told it to.", "proposed_action": "fix-in-this-feature", "fix_cost": "small", "feature_value": "core", "adjacent_to_blocking": false, "id": "F-PO-43-4-25" } ], "pending_decisions": [ { "id": "D-PO-43-4-1", "type": "scope-disposition", "blocking": false, "question": "[CR-7] `SCAN=/tmp/dispatch-scan.txt` — a fixed, predictable path in a normative recipe whose own subject guarantees concurrent execution. — fix now, spawn a follow-up issue, or accept?", "options": [ "fix-now", "defer-to-issue", "accept" ], "recommended": "fix-now", "finding_ref": "F-PO-43-4-7", "reasoning": "Computed by disposition-recommend.sh from fix_cost=trivial, feature_value=core, adjacent_to_blocking=true, category=in-scope-deferrable. See qa-report:v1 (domain=code, phase=validate) comment 1405 and .devwork/feature-qa-intra-run-lane-ownership/code-report.md for the full reasoning and the evidence behind this finding." }, { "id": "D-PO-43-4-2", "type": "scope-disposition", "blocking": false, "question": "[CR-8] The record shape specifies a timestamp FORMAT but never says to read the clock, and does not pin a single UTC offset. — fix now, spawn a follow-up issue, or accept?", "options": [ "fix-now", "defer-to-issue", "accept" ], "recommended": "fix-now", "finding_ref": "F-PO-43-4-8", "reasoning": "Computed by disposition-recommend.sh from fix_cost=trivial, feature_value=core, adjacent_to_blocking=false, category=in-scope-deferrable. See qa-report:v1 (domain=code, phase=validate) comment 1405 and .devwork/feature-qa-intra-run-lane-ownership/code-report.md for the full reasoning and the evidence behind this finding." }, { "id": "D-PO-43-4-3", "type": "scope-disposition", "blocking": false, "question": "[CR-9] The `/dev:develop` consumer omits the solo-actor claim rule AC-2 requires of it, and never mentions the dispatch record at all. — fix now, spawn a follow-up issue, or accept?", "options": [ "fix-now", "defer-to-issue", "accept" ], "recommended": "fix-now", "finding_ref": "F-PO-43-4-9", "reasoning": "Computed by disposition-recommend.sh from fix_cost=trivial, feature_value=core, adjacent_to_blocking=false, category=in-scope-deferrable. See qa-report:v1 (domain=code, phase=validate) comment 1405 and .devwork/feature-qa-intra-run-lane-ownership/code-report.md for the full reasoning and the evidence behind this finding." }, { "id": "D-PO-43-4-4", "type": "scope-disposition", "blocking": false, "question": "[CR-10] `overran_claim` is a bare boolean, so the durable record never says WHAT was overrun — and §7 step 4's scope for it is ambiguous. — fix now, spawn a follow-up issue, or accept?", "options": [ "fix-now", "defer-to-issue", "accept" ], "recommended": "fix-now", "finding_ref": "F-PO-43-4-10", "reasoning": "Computed by disposition-recommend.sh from fix_cost=small, feature_value=core, adjacent_to_blocking=false, category=in-scope-deferrable. See qa-report:v1 (domain=code, phase=validate) comment 1405 and .devwork/feature-qa-intra-run-lane-ownership/code-report.md for the full reasoning and the evidence behind this finding." }, { "id": "D-PO-43-4-5", "type": "scope-disposition", "blocking": false, "question": "[CR-11] The scope sentence promises 'any set of concurrent actors', but the mechanism is strictly intra-driver and cannot see a second driver. — fix now, spawn a follow-up issue, or accept?", "options": [ "fix-now", "defer-to-issue", "accept" ], "recommended": "fix-now", "finding_ref": "F-PO-43-4-11", "reasoning": "Computed by disposition-recommend.sh from fix_cost=small, feature_value=core, adjacent_to_blocking=false, category=in-scope-deferrable. See qa-report:v1 (domain=code, phase=validate) comment 1405 and .devwork/feature-qa-intra-run-lane-ownership/code-report.md for the full reasoning and the evidence behind this finding." }, { "id": "D-PO-43-4-6", "type": "scope-disposition", "blocking": false, "question": "[CR-12] §5 equates 'the actor's report arrives' with the resources being free, which is false when the suite leaves stragglers. — fix now, spawn a follow-up issue, or accept?", "options": [ "fix-now", "defer-to-issue", "accept" ], "recommended": "fix-now", "finding_ref": "F-PO-43-4-12", "reasoning": "Computed by disposition-recommend.sh from fix_cost=small, feature_value=incidental, adjacent_to_blocking=false, category=in-scope-deferrable. See qa-report:v1 (domain=code, phase=validate) comment 1405 and .devwork/feature-qa-intra-run-lane-ownership/code-report.md for the full reasoning and the evidence behind this finding." }, { "id": "D-PO-43-4-7", "type": "scope-disposition", "blocking": false, "question": "[CR-13] Who obtains 'sole ownership' for a void re-run is unassigned, and the three documents that mention it point at three different actors. — fix now, spawn a follow-up issue, or accept?", "options": [ "fix-now", "defer-to-issue", "accept" ], "recommended": "fix-now", "finding_ref": "F-PO-43-4-13", "reasoning": "Computed by disposition-recommend.sh from fix_cost=small, feature_value=core, adjacent_to_blocking=false, category=in-scope-deferrable. See qa-report:v1 (domain=code, phase=validate) comment 1405 and .devwork/feature-qa-intra-run-lane-ownership/code-report.md for the full reasoning and the evidence behind this finding." }, { "id": "D-PO-43-4-8", "type": "scope-disposition", "blocking": false, "question": "[CR-14] The new gate section is deliberately not fence-aware, contradicting an explicit SREQ constraint and a CLAUDE.md convention. — fix now, spawn a follow-up issue, or accept?", "options": [ "fix-now", "defer-to-issue", "accept" ], "recommended": "defer-to-issue", "finding_ref": "F-PO-43-4-14", "reasoning": "Computed by disposition-recommend.sh from fix_cost=substantial, feature_value=incidental, adjacent_to_blocking=false, category=in-scope-deferrable. See qa-report:v1 (domain=code, phase=validate) comment 1405 and .devwork/feature-qa-intra-run-lane-ownership/code-report.md for the full reasoning and the evidence behind this finding." }, { "id": "D-PO-43-4-9", "type": "scope-disposition", "blocking": false, "question": "[CR-15] All 17 contract scenarios build synthetic fixture documents instead of copying and mutating the real, already-landed ones. — fix now, spawn a follow-up issue, or accept?", "options": [ "fix-now", "defer-to-issue", "accept" ], "recommended": "defer-to-issue", "finding_ref": "F-PO-43-4-15", "reasoning": "Computed by disposition-recommend.sh from fix_cost=substantial, feature_value=incidental, adjacent_to_blocking=false, category=in-scope-deferrable. See qa-report:v1 (domain=code, phase=validate) comment 1405 and .devwork/feature-qa-intra-run-lane-ownership/code-report.md for the full reasoning and the evidence behind this finding." }, { "id": "D-PO-43-4-10", "type": "scope-disposition", "blocking": false, "question": "[CR-16] Three defensive 'file is missing' guards in the gate are exercised in neither direction. — fix now, spawn a follow-up issue, or accept?", "options": [ "fix-now", "defer-to-issue", "accept" ], "recommended": "fix-now", "finding_ref": "F-PO-43-4-16", "reasoning": "Computed by disposition-recommend.sh from fix_cost=small, feature_value=incidental, adjacent_to_blocking=false, category=in-scope-deferrable. See qa-report:v1 (domain=code, phase=validate) comment 1405 and .devwork/feature-qa-intra-run-lane-ownership/code-report.md for the full reasoning and the evidence behind this finding." }, { "id": "D-PO-43-4-11", "type": "scope-disposition", "blocking": false, "question": "[CR-17] Two consumers paraphrase the rule they cite, and the paraphrases carry no gate anchor — so they run under AC-14's mechanical floor. — fix now, spawn a follow-up issue, or accept?", "options": [ "fix-now", "defer-to-issue", "accept" ], "recommended": "fix-now", "finding_ref": "F-PO-43-4-17", "reasoning": "Computed by disposition-recommend.sh from fix_cost=small, feature_value=core, adjacent_to_blocking=false, category=in-scope-deferrable. See qa-report:v1 (domain=code, phase=validate) comment 1405 and .devwork/feature-qa-intra-run-lane-ownership/code-report.md for the full reasoning and the evidence behind this finding." }, { "id": "D-PO-43-4-12", "type": "scope-disposition", "blocking": false, "question": "[CR-18] The `ended_by` timeout check is line-scoped and value-literal, so a reformat or a new third value passes it. — fix now, spawn a follow-up issue, or accept?", "options": [ "fix-now", "defer-to-issue", "accept" ], "recommended": "fix-now", "finding_ref": "F-PO-43-4-18", "reasoning": "Computed by disposition-recommend.sh from fix_cost=small, feature_value=incidental, adjacent_to_blocking=false, category=in-scope-deferrable. See qa-report:v1 (domain=code, phase=validate) comment 1405 and .devwork/feature-qa-intra-run-lane-ownership/code-report.md for the full reasoning and the evidence behind this finding." }, { "id": "D-PO-43-4-13", "type": "scope-disposition", "blocking": false, "question": "[CR-19] Actor ids are not required to be unique per dispatch, so RELEASE-to-DISPATCH pairing is undefined for a repeated role. — fix now, spawn a follow-up issue, or accept?", "options": [ "fix-now", "defer-to-issue", "accept" ], "recommended": "fix-now", "finding_ref": "F-PO-43-4-19", "reasoning": "Computed by disposition-recommend.sh from fix_cost=small, feature_value=incidental, adjacent_to_blocking=false, category=in-scope-deferrable. See qa-report:v1 (domain=code, phase=validate) comment 1405 and .devwork/feature-qa-intra-run-lane-ownership/code-report.md for the full reasoning and the evidence behind this finding." }, { "id": "D-PO-43-4-14", "type": "scope-disposition", "blocking": false, "question": "[CR-20] `ended_by` has no value for a deliberate driver-initiated termination. — fix now, spawn a follow-up issue, or accept?", "options": [ "fix-now", "defer-to-issue", "accept" ], "recommended": "fix-now", "finding_ref": "F-PO-43-4-20", "reasoning": "Computed by disposition-recommend.sh from fix_cost=trivial, feature_value=incidental, adjacent_to_blocking=false, category=in-scope-deferrable. See qa-report:v1 (domain=code, phase=validate) comment 1405 and .devwork/feature-qa-intra-run-lane-ownership/code-report.md for the full reasoning and the evidence behind this finding." }, { "id": "D-PO-43-4-15", "type": "scope-disposition", "blocking": false, "question": "[CR-21] The four-class vocabulary omits shared writable scratch and cache surfaces, which collide near-universally when two suites run in one checkout. — fix now, spawn a follow-up issue, or accept?", "options": [ "fix-now", "defer-to-issue", "accept" ], "recommended": "fix-now", "finding_ref": "F-PO-43-4-21", "reasoning": "Computed by disposition-recommend.sh from fix_cost=trivial, feature_value=incidental, adjacent_to_blocking=false, category=in-scope-deferrable. See qa-report:v1 (domain=code, phase=validate) comment 1405 and .devwork/feature-qa-intra-run-lane-ownership/code-report.md for the full reasoning and the evidence behind this finding." }, { "id": "D-PO-43-4-16", "type": "scope-disposition", "blocking": false, "question": "[CR-22] The late-withdrawal rule assigns the re-post to a domain agent that has usually exited by the time contention is established. — fix now, spawn a follow-up issue, or accept?", "options": [ "fix-now", "defer-to-issue", "accept" ], "recommended": "fix-now", "finding_ref": "F-PO-43-4-22", "reasoning": "Computed by disposition-recommend.sh from fix_cost=trivial, feature_value=core, adjacent_to_blocking=false, category=in-scope-deferrable. See qa-report:v1 (domain=code, phase=validate) comment 1405 and .devwork/feature-qa-intra-run-lane-ownership/code-report.md for the full reasoning and the evidence behind this finding." }, { "id": "D-PO-43-4-17", "type": "scope-disposition", "blocking": false, "question": "[CR-23] §7 step 1 conflates a missing journal with a journal that has no entries, and lets grep's error text land in the scan file as data. — fix now, spawn a follow-up issue, or accept?", "options": [ "fix-now", "defer-to-issue", "accept" ], "recommended": "fix-now", "finding_ref": "F-PO-43-4-23", "reasoning": "Computed by disposition-recommend.sh from fix_cost=trivial, feature_value=incidental, adjacent_to_blocking=true, category=in-scope-deferrable. See qa-report:v1 (domain=code, phase=validate) comment 1405 and .devwork/feature-qa-intra-run-lane-ownership/code-report.md for the full reasoning and the evidence behind this finding." }, { "id": "D-PO-43-4-18", "type": "scope-disposition", "blocking": false, "question": "[CR-24] The remedy preference is stated in opposite orders in §1 and §4. — fix now, spawn a follow-up issue, or accept?", "options": [ "fix-now", "defer-to-issue", "accept" ], "recommended": "fix-now", "finding_ref": "F-PO-43-4-24", "reasoning": "Computed by disposition-recommend.sh from fix_cost=trivial, feature_value=incidental, adjacent_to_blocking=false, category=in-scope-deferrable. See qa-report:v1 (domain=code, phase=validate) comment 1405 and .devwork/feature-qa-intra-run-lane-ownership/code-report.md for the full reasoning and the evidence behind this finding." }, { "id": "D-PO-43-4-19", "type": "scope-disposition", "blocking": false, "question": "[CR-25] The QA playbook's control flow has no step at which the dispatch journal is written. — fix now, spawn a follow-up issue, or accept?", "options": [ "fix-now", "defer-to-issue", "accept" ], "recommended": "fix-now", "finding_ref": "F-PO-43-4-25", "reasoning": "Computed by disposition-recommend.sh from fix_cost=small, feature_value=core, adjacent_to_blocking=false, category=in-scope-deferrable. See qa-report:v1 (domain=code, phase=validate) comment 1405 and .devwork/feature-qa-intra-run-lane-ownership/code-report.md for the full reasoning and the evidence behind this finding." } ], "suite": { "source": "git", "sha": "70339883b9cba894ee55b394ff6438a8114a7810", "dirty": false } } ```

jbr870 commented

2026-08-25 13:57:04 +00:00

Author

Owner

{
  "status": "resolved",
  "chosen_option": "fix-now",
  "rationale": "[CR-7] The finding sits in the same block of §7 that CR-1 and CR-6 must rewrite anyway, so the marginal cost is one line inside an edit already happening. It is also not the house pattern replicated: the ten other fixed-/tmp sites in the suite are single-writer moments (one skill writing one payload for one helper call), whereas this recipe's own document guarantees concurrent execution, so the exposure is new with this feature. scripts/lint-conventions.sh in this same diff already shows the correct idiom (mktemp + trap), so the fix has a local precedent to copy rather than a convention to invent. Resolved under a standing instruction from the operator in this session — asked for /dev:resolve to be run and accepted all recommendations — so this follows the recommender's output rather than overriding it. The recommendation itself is disposition-recommend.sh's, computed from the finding's fix_cost, feature_value, adjacent_to_blocking and category.",
  "rejected_alternative": "defer-to-issue was arguable on the grounds that the fixed-/tmp idiom is pervasive and fixing one site leaves nine, which invites a reader to think the pattern is now safe. Turned down because the argument cuts the other way at this particular site — a contention-triage tool that corrupts its own input under contention is a self-refuting artifact, and it is cheaper to fix inside CR-1's edit than to re-open §7 later."
}

```json { "status": "resolved", "chosen_option": "fix-now", "rationale": "[CR-7] The finding sits in the same block of §7 that CR-1 and CR-6 must rewrite anyway, so the marginal cost is one line inside an edit already happening. It is also not the house pattern replicated: the ten other fixed-/tmp sites in the suite are single-writer moments (one skill writing one payload for one helper call), whereas this recipe's own document guarantees concurrent execution, so the exposure is new with this feature. scripts/lint-conventions.sh in this same diff already shows the correct idiom (mktemp + trap), so the fix has a local precedent to copy rather than a convention to invent. Resolved under a standing instruction from the operator in this session — asked for /dev:resolve to be run and accepted all recommendations — so this follows the recommender's output rather than overriding it. The recommendation itself is disposition-recommend.sh's, computed from the finding's fix_cost, feature_value, adjacent_to_blocking and category.", "rejected_alternative": "defer-to-issue was arguable on the grounds that the fixed-/tmp idiom is pervasive and fixing one site leaves nine, which invites a reader to think the pattern is now safe. Turned down because the argument cuts the other way at this particular site — a contention-triage tool that corrupts its own input under contention is a self-refuting artifact, and it is cheaper to fix inside CR-1's edit than to re-open §7 later." } ```

jbr870 commented

Author

Owner

{
  "status": "resolved",
  "chosen_option": "fix-now",
  "rationale": "[CR-8] Prevention is the entire fix: the journal is append-only by contract, so a drifted timestamp can never be corrected in place, only annotated. That makes the cost of getting it wrong permanent and the cost of stating it one sentence. The defect was demonstrated live in this round rather than hypothesised — four hand-estimated entries, three of them ahead of the real clock, one DISPATCH/RELEASE pair inverted against wall time — and §7 computes contention windows by intersecting exactly those values. Resolved under a standing instruction from the operator in this session — asked for /dev:resolve to be run and accepted all recommendations — so this follows the recommender's output rather than overriding it. The recommendation itself is disposition-recommend.sh's, computed from the finding's fix_cost, feature_value, adjacent_to_blocking and category.",
  "rejected_alternative": "accept was considered on the grounds that a competent driver would obviously read the clock. Rejected by the evidence: this round's driver is the reference implementation of the contract and did not, because nothing asked it to. An assumption that the run's own author violated on first contact is not a safe assumption to leave unstated."
}

```json { "status": "resolved", "chosen_option": "fix-now", "rationale": "[CR-8] Prevention is the entire fix: the journal is append-only by contract, so a drifted timestamp can never be corrected in place, only annotated. That makes the cost of getting it wrong permanent and the cost of stating it one sentence. The defect was demonstrated live in this round rather than hypothesised — four hand-estimated entries, three of them ahead of the real clock, one DISPATCH/RELEASE pair inverted against wall time — and §7 computes contention windows by intersecting exactly those values. Resolved under a standing instruction from the operator in this session — asked for /dev:resolve to be run and accepted all recommendations — so this follows the recommender's output rather than overriding it. The recommendation itself is disposition-recommend.sh's, computed from the finding's fix_cost, feature_value, adjacent_to_blocking and category.", "rejected_alternative": "accept was considered on the grounds that a competent driver would obviously read the clock. Rejected by the evidence: this round's driver is the reference implementation of the contract and did not, because nothing asked it to. An assumption that the run's own author violated on first contact is not a safe assumption to leave unstated." } ```

jbr870 commented

Author

Owner

{
  "status": "resolved",
  "chosen_option": "fix-now",
  "rationale": "[CR-9] AC-2's verification approach names both consumers for the solo-actor property specifically, so a consumer whose trigger is narrower than the rule it cites does not satisfy it. The fix widens a trigger rather than restating a rule, so it carries no AC-14 risk — which was the Spec Checker's stated reason for judging the omission acceptable, and is the only thing that made this a genuine disagreement rather than an oversight. Resolved under a standing instruction from the operator in this session — asked for /dev:resolve to be run and accepted all recommendations — so this follows the recommender's output rather than overriding it. The recommendation itself is disposition-recommend.sh's, computed from the finding's fix_cost, feature_value, adjacent_to_blocking and category.",
  "rejected_alternative": "accept was the Spec Checker's position and it was seriously in play: the contract's own rule is unconditional, so a driver that reads the contract behaves correctly regardless. Turned down because /dev:develop's §3.1 sequential fallback is the majority path, and a driver working from the consumer text alone would dispatch suite-running Implementers with no claim and no DISPATCH entry — leaving develop-phase results with no record to interrogate later, which is the failure the playbook's sibling sentence explicitly names."
}

```json { "status": "resolved", "chosen_option": "fix-now", "rationale": "[CR-9] AC-2's verification approach names both consumers for the solo-actor property specifically, so a consumer whose trigger is narrower than the rule it cites does not satisfy it. The fix widens a trigger rather than restating a rule, so it carries no AC-14 risk — which was the Spec Checker's stated reason for judging the omission acceptable, and is the only thing that made this a genuine disagreement rather than an oversight. Resolved under a standing instruction from the operator in this session — asked for /dev:resolve to be run and accepted all recommendations — so this follows the recommender's output rather than overriding it. The recommendation itself is disposition-recommend.sh's, computed from the finding's fix_cost, feature_value, adjacent_to_blocking and category.", "rejected_alternative": "accept was the Spec Checker's position and it was seriously in play: the contract's own rule is unconditional, so a driver that reads the contract behaves correctly regardless. Turned down because /dev:develop's §3.1 sequential fallback is the majority path, and a driver working from the consumer text alone would dispatch suite-running Implementers with no claim and no DISPATCH entry — leaving develop-phase results with no record to interrogate later, which is the failure the playbook's sibling sentence explicitly names." } ```

jbr870 commented

Author

Owner

{
  "status": "resolved",
  "chosen_option": "fix-now",
  "rationale": "[CR-10] The bare boolean and the step-4 scope ambiguity are one defect seen twice: triage reads the journal, not the report, so a boolean cannot support the resource-overlap test the rest of §7 is built on, and step 4 is a blanket rule precisely because it has nothing finer to work with. Fixing the record shape and the scope sentence together is coherent; fixing either alone leaves the other unexplained. Resolved under a standing instruction from the operator in this session — asked for /dev:resolve to be run and accepted all recommendations — so this follows the recommender's output rather than overriding it. The recommendation itself is disposition-recommend.sh's, computed from the finding's fix_cost, feature_value, adjacent_to_blocking and category.",
  "rejected_alternative": "defer-to-issue was reasonable given this touches journal-template.md's record shape, which is a contract other features consume. Turned down because the shape is new in this very diff — deferring means shipping a v1 record that triage cannot use, then changing it later, which is strictly more disruptive than getting it right before anything depends on it."
}

```json { "status": "resolved", "chosen_option": "fix-now", "rationale": "[CR-10] The bare boolean and the step-4 scope ambiguity are one defect seen twice: triage reads the journal, not the report, so a boolean cannot support the resource-overlap test the rest of §7 is built on, and step 4 is a blanket rule precisely because it has nothing finer to work with. Fixing the record shape and the scope sentence together is coherent; fixing either alone leaves the other unexplained. Resolved under a standing instruction from the operator in this session — asked for /dev:resolve to be run and accepted all recommendations — so this follows the recommender's output rather than overriding it. The recommendation itself is disposition-recommend.sh's, computed from the finding's fix_cost, feature_value, adjacent_to_blocking and category.", "rejected_alternative": "defer-to-issue was reasonable given this touches journal-template.md's record shape, which is a contract other features consume. Turned down because the shape is new in this very diff — deferring means shipping a v1 record that triage cannot use, then changing it later, which is strictly more disruptive than getting it right before anything depends on it." } ```

jbr870 commented

Author

Owner

{
  "status": "resolved",
  "chosen_option": "fix-now",
  "rationale": "[CR-11] The fix is to make the text honest about what the mechanism can see — narrow the scope sentence, or name the cross-driver case as a non-goal. That is a sentence, not machinery, and it matters here more than in most projects because this repo's own documented operating model is several parallel feature sessions on one checkout, so the unseen case is the normal case locally. Resolved under a standing instruction from the operator in this session — asked for /dev:resolve to be run and accepted all recommendations — so this follows the recommender's output rather than overriding it. The recommendation itself is disposition-recommend.sh's, computed from the finding's fix_cost, feature_value, adjacent_to_blocking and category.",
  "rejected_alternative": "defer-to-issue was considered on the reading that cross-driver contention is a genuine capability gap deserving its own issue. Turned down as a category error for this decision: building cross-driver coordination was ruled out at requirements time (declared and honoured, no registry), so there is no capability to schedule — the only live defect is a scope sentence that overpromises, and that is in-scope wording."
}

```json { "status": "resolved", "chosen_option": "fix-now", "rationale": "[CR-11] The fix is to make the text honest about what the mechanism can see — narrow the scope sentence, or name the cross-driver case as a non-goal. That is a sentence, not machinery, and it matters here more than in most projects because this repo's own documented operating model is several parallel feature sessions on one checkout, so the unseen case is the normal case locally. Resolved under a standing instruction from the operator in this session — asked for /dev:resolve to be run and accepted all recommendations — so this follows the recommender's output rather than overriding it. The recommendation itself is disposition-recommend.sh's, computed from the finding's fix_cost, feature_value, adjacent_to_blocking and category.", "rejected_alternative": "defer-to-issue was considered on the reading that cross-driver contention is a genuine capability gap deserving its own issue. Turned down as a category error for this decision: building cross-driver coordination was ruled out at requirements time (declared and honoured, no registry), so there is no capability to schedule — the only live defect is a scope sentence that overpromises, and that is in-scope wording." } ```

jbr870 commented

Author

Owner

{
  "status": "resolved",
  "chosen_option": "fix-now",
  "rationale": "[CR-12] A release entry that is honest by the letter and wrong in fact is worse than no entry, because §7 later reads it as evidence of clean serialization. One sentence making release conditional on the resources actually being quiesced closes it, and the neighbouring dev-server-lifecycle rule already establishes the shape of that check for the server half. Resolved under a standing instruction from the operator in this session — asked for /dev:resolve to be run and accepted all recommendations — so this follows the recommender's output rather than overriding it. The recommendation itself is disposition-recommend.sh's, computed from the finding's fix_cost, feature_value, adjacent_to_blocking and category.",
  "rejected_alternative": "accept was plausible because the server half is arguably already covered by dev-server-lifecycle re-verification. Turned down because runner stragglers — a watch-mode process outliving the actor that reported — are not covered anywhere, and that is the case most likely to occur in a suite the contract was written for."
}

```json { "status": "resolved", "chosen_option": "fix-now", "rationale": "[CR-12] A release entry that is honest by the letter and wrong in fact is worse than no entry, because §7 later reads it as evidence of clean serialization. One sentence making release conditional on the resources actually being quiesced closes it, and the neighbouring dev-server-lifecycle rule already establishes the shape of that check for the server half. Resolved under a standing instruction from the operator in this session — asked for /dev:resolve to be run and accepted all recommendations — so this follows the recommender's output rather than overriding it. The recommendation itself is disposition-recommend.sh's, computed from the finding's fix_cost, feature_value, adjacent_to_blocking and category.", "rejected_alternative": "accept was plausible because the server half is arguably already covered by dev-server-lifecycle re-verification. Turned down because runner stragglers — a watch-mode process outliving the actor that reported — are not covered anywhere, and that is the case most likely to occur in a suite the contract was written for." } ```

jbr870 commented

Author

Owner

{
  "status": "resolved",
  "chosen_option": "fix-now",
  "rationale": "[CR-13] Three documents assign the same re-run to three different actors, and only one of them (the driver) can actually deliver sole ownership, since only the driver controls dispatch and holds the journal. Naming the owner is a sentence; leaving it unnamed means the remedy for contention can itself produce contention, which is the specific scenario the Bug Hunter constructed. Resolved under a standing instruction from the operator in this session — asked for /dev:resolve to be run and accepted all recommendations — so this follows the recommender's output rather than overriding it. The recommendation itself is disposition-recommend.sh's, computed from the finding's fix_cost, feature_value, adjacent_to_blocking and category.",
  "rejected_alternative": "defer-to-issue was considered because the fix touches validate-workflow.md and fix-workflow.md as well as the contract. Turned down because all three edits are the same sentence pointing at the same owner, and splitting a one-decision change across two rounds is how the three documents drifted apart in the first place."
}

```json { "status": "resolved", "chosen_option": "fix-now", "rationale": "[CR-13] Three documents assign the same re-run to three different actors, and only one of them (the driver) can actually deliver sole ownership, since only the driver controls dispatch and holds the journal. Naming the owner is a sentence; leaving it unnamed means the remedy for contention can itself produce contention, which is the specific scenario the Bug Hunter constructed. Resolved under a standing instruction from the operator in this session — asked for /dev:resolve to be run and accepted all recommendations — so this follows the recommender's output rather than overriding it. The recommendation itself is disposition-recommend.sh's, computed from the finding's fix_cost, feature_value, adjacent_to_blocking and category.", "rejected_alternative": "defer-to-issue was considered because the fix touches validate-workflow.md and fix-workflow.md as well as the contract. Turned down because all three edits are the same sentence pointing at the same owner, and splitting a one-decision change across two rounds is how the three documents drifted apart in the first place." } ```

jbr870 commented

Author

Owner

{
  "status": "resolved",
  "chosen_option": "defer-to-issue",
  "rationale": "[CR-14] Reusing the fence tracker for the anchor-uniqueness scan is a substantial change to a gate that currently passes 20 of 20 driver-authored mutations, and substantial work does not fold into a fix round by the recommender's own rule. The deviation also deserves an explicit recorded decision rather than a code comment, because the SREQ constraint and the CLAUDE.md convention both say fence-aware and the implementation chose otherwise for reasons that are good but currently invisible to anyone who has not read that comment. Resolved under a standing instruction from the operator in this session — asked for /dev:resolve to be run and accepted all recommendations — so this follows the recommender's output rather than overriding it. The recommendation itself is disposition-recommend.sh's, computed from the finding's fix_cost, feature_value, adjacent_to_blocking and category.",
  "rejected_alternative": "fix-now was seriously in play: the citation-check half of the argument is genuinely sound (a fenced example restating the rule is still a restatement), so the deviation may be correct rather than merely expedient. It was turned down on cost, not on merit — the uniqueness half needs the fence tracker and that is a real rewrite of the scan, not a sentence, and doing it inside a round that already carries six blocking fixes risks the gate this feature depends on."
}

```json { "status": "resolved", "chosen_option": "defer-to-issue", "rationale": "[CR-14] Reusing the fence tracker for the anchor-uniqueness scan is a substantial change to a gate that currently passes 20 of 20 driver-authored mutations, and substantial work does not fold into a fix round by the recommender's own rule. The deviation also deserves an explicit recorded decision rather than a code comment, because the SREQ constraint and the CLAUDE.md convention both say fence-aware and the implementation chose otherwise for reasons that are good but currently invisible to anyone who has not read that comment. Resolved under a standing instruction from the operator in this session — asked for /dev:resolve to be run and accepted all recommendations — so this follows the recommender's output rather than overriding it. The recommendation itself is disposition-recommend.sh's, computed from the finding's fix_cost, feature_value, adjacent_to_blocking and category.", "rejected_alternative": "fix-now was seriously in play: the citation-check half of the argument is genuinely sound (a fenced example restating the rule is still a restatement), so the deviation may be correct rather than merely expedient. It was turned down on cost, not on merit — the uniqueness half needs the fence tracker and that is a real rewrite of the scan, not a sentence, and doing it inside a round that already carries six blocking fixes risks the gate this feature depends on." } ```

jbr870 commented

Author

Owner

{
  "status": "resolved",
  "chosen_option": "defer-to-issue",
  "rationale": "[CR-15] Converting 17 scenarios from hand-authored fixtures to copy-and-mutate of the real documents is substantial by inspection, and the recommender never folds substantial work. There is also no urgency: the driver's 20-mutation battery this round mutated the real documents directly and every check fired with its specific message, so the current fixtures demonstrably encode the right assumptions today. The issue is the design's fragility over time, which is exactly what a follow-up issue is for. Resolved under a standing instruction from the operator in this session — asked for /dev:resolve to be run and accepted all recommendations — so this follows the recommender's output rather than overriding it. The recommendation itself is disposition-recommend.sh's, computed from the finding's fix_cost, feature_value, adjacent_to_blocking and category.",
  "rejected_alternative": "fix-now was considered because CLAUDE.md names a fixture standing in for content the repo already holds as the worst case of over-mocking, and the real files are right there. Turned down because the change is 17 scenarios deep and this round must not destabilise the gate while six blocking findings are being fixed against it."
}

```json { "status": "resolved", "chosen_option": "defer-to-issue", "rationale": "[CR-15] Converting 17 scenarios from hand-authored fixtures to copy-and-mutate of the real documents is substantial by inspection, and the recommender never folds substantial work. There is also no urgency: the driver's 20-mutation battery this round mutated the real documents directly and every check fired with its specific message, so the current fixtures demonstrably encode the right assumptions today. The issue is the design's fragility over time, which is exactly what a follow-up issue is for. Resolved under a standing instruction from the operator in this session — asked for /dev:resolve to be run and accepted all recommendations — so this follows the recommender's output rather than overriding it. The recommendation itself is disposition-recommend.sh's, computed from the finding's fix_cost, feature_value, adjacent_to_blocking and category.", "rejected_alternative": "fix-now was considered because CLAUDE.md names a fixture standing in for content the repo already holds as the worst case of over-mocking, and the real files are right there. Turned down because the change is 17 scenarios deep and this round must not destabilise the gate while six blocking findings are being fixed against it." } ```

jbr870 commented

Author

Owner

{
  "status": "resolved",
  "chosen_option": "fix-now",
  "rationale": "[CR-16] The three guards are defensive branches with no scenario in either direction, so a bug that made one wrongly fire or wrongly stay silent would go undetected. Adding the missing scenarios is mechanical and lands in a harness the round is already editing for CR-4, which removes the in-flight allowance from the same file. Resolved under a standing instruction from the operator in this session — asked for /dev:resolve to be run and accepted all recommendations — so this follows the recommender's output rather than overriding it. The recommendation itself is disposition-recommend.sh's, computed from the finding's fix_cost, feature_value, adjacent_to_blocking and category.",
  "rejected_alternative": "defer-to-issue was considered as test-coverage work rather than feature work. Turned down because the round is already opening this file for CR-4, and adding three scenarios while it is open costs far less than a separate issue's full re-entry."
}

```json { "status": "resolved", "chosen_option": "fix-now", "rationale": "[CR-16] The three guards are defensive branches with no scenario in either direction, so a bug that made one wrongly fire or wrongly stay silent would go undetected. Adding the missing scenarios is mechanical and lands in a harness the round is already editing for CR-4, which removes the in-flight allowance from the same file. Resolved under a standing instruction from the operator in this session — asked for /dev:resolve to be run and accepted all recommendations — so this follows the recommender's output rather than overriding it. The recommendation itself is disposition-recommend.sh's, computed from the finding's fix_cost, feature_value, adjacent_to_blocking and category.", "rejected_alternative": "defer-to-issue was considered as test-coverage work rather than feature work. Turned down because the round is already opening this file for CR-4, and adding three scenarios while it is open costs far less than a separate issue's full re-entry." } ```

jbr870 commented

Author

Owner

{
  "status": "resolved",
  "chosen_option": "fix-now",
  "rationale": "[CR-17] The paraphrases have already measurably drifted — qa-playbook's version triggers on where they would overlap and silently drops the unknown-and-malformed half of §1 — so this is not a hypothetical drift risk but drift that has occurred, in the direction of the permissive answer. Since none of the paraphrases carries a gate anchor, AC-14's mechanical check cannot see them, which makes the manual fix the only available one. Resolved under a standing instruction from the operator in this session — asked for /dev:resolve to be run and accepted all recommendations — so this follows the recommender's output rather than overriding it. The recommendation itself is disposition-recommend.sh's, computed from the finding's fix_cost, feature_value, adjacent_to_blocking and category.",
  "rejected_alternative": "accept was considered on the view that summary-then-cite is good technical writing and forbidding it would make the consumers unreadable. That reading is respected in the fix: the remedy is to correct the drifted paraphrase, not to strip the summaries, so the consumers keep their readability and lose only the incorrect half-statement."
}

```json { "status": "resolved", "chosen_option": "fix-now", "rationale": "[CR-17] The paraphrases have already measurably drifted — qa-playbook's version triggers on where they would overlap and silently drops the unknown-and-malformed half of §1 — so this is not a hypothetical drift risk but drift that has occurred, in the direction of the permissive answer. Since none of the paraphrases carries a gate anchor, AC-14's mechanical check cannot see them, which makes the manual fix the only available one. Resolved under a standing instruction from the operator in this session — asked for /dev:resolve to be run and accepted all recommendations — so this follows the recommender's output rather than overriding it. The recommendation itself is disposition-recommend.sh's, computed from the finding's fix_cost, feature_value, adjacent_to_blocking and category.", "rejected_alternative": "accept was considered on the view that summary-then-cite is good technical writing and forbidding it would make the consumers unreadable. That reading is respected in the fix: the remedy is to correct the drifted paraphrase, not to strip the summaries, so the consumers keep their readability and lose only the incorrect half-statement." } ```

jbr870 commented

Author

Owner

{
  "status": "resolved",
  "chosen_option": "fix-now",
  "rationale": "[CR-18] This is the exact inverse of a learning this feature already recorded in CLAUDE.md — a grep-based content check reading a wrapped phrase as absent — arriving as a check that reads a wrapped enum as clean. Shipping the feature that produced that learning with a fresh instance of it is not defensible when the fix is to widen the check beyond a single line. Resolved under a standing instruction from the operator in this session — asked for /dev:resolve to be run and accepted all recommendations — so this follows the recommender's output rather than overriding it. The recommendation itself is disposition-recommend.sh's, computed from the finding's fix_cost, feature_value, adjacent_to_blocking and category.",
  "rejected_alternative": "defer-to-issue was considered because it is a gate-hardening task rather than a contract defect. Turned down because AC-7 is the criterion it weakens, AC-7 is one of this feature's own acceptance criteria, and the round is editing this gate file already."
}

```json { "status": "resolved", "chosen_option": "fix-now", "rationale": "[CR-18] This is the exact inverse of a learning this feature already recorded in CLAUDE.md — a grep-based content check reading a wrapped phrase as absent — arriving as a check that reads a wrapped enum as clean. Shipping the feature that produced that learning with a fresh instance of it is not defensible when the fix is to widen the check beyond a single line. Resolved under a standing instruction from the operator in this session — asked for /dev:resolve to be run and accepted all recommendations — so this follows the recommender's output rather than overriding it. The recommendation itself is disposition-recommend.sh's, computed from the finding's fix_cost, feature_value, adjacent_to_blocking and category.", "rejected_alternative": "defer-to-issue was considered because it is a gate-hardening task rather than a contract defect. Turned down because AC-7 is the criterion it weakens, AC-7 is one of this feature's own acceptance criteria, and the round is editing this gate file already." } ```

jbr870 commented

Author

Owner

{
  "status": "resolved",
  "chosen_option": "fix-now",
  "rationale": "[CR-19] Window pairing is the whole of the §7 scan, and a repeated role name across rounds — which this round's own journal already contains, since role names are stable strings — leaves the pairing rule undefined. A mispaired window flips a contention verdict, which is the single outcome the contract exists to get right. Resolved under a standing instruction from the operator in this session — asked for /dev:resolve to be run and accepted all recommendations — so this follows the recommender's output rather than overriding it. The recommendation itself is disposition-recommend.sh's, computed from the finding's fix_cost, feature_value, adjacent_to_blocking and category.",
  "rejected_alternative": "accept was considered on likelihood grounds, since most rounds dispatch each role once. Turned down because the fix loop's whole shape is repeated rounds with the same role names, so the collision is structural rather than unlucky."
}

```json { "status": "resolved", "chosen_option": "fix-now", "rationale": "[CR-19] Window pairing is the whole of the §7 scan, and a repeated role name across rounds — which this round's own journal already contains, since role names are stable strings — leaves the pairing rule undefined. A mispaired window flips a contention verdict, which is the single outcome the contract exists to get right. Resolved under a standing instruction from the operator in this session — asked for /dev:resolve to be run and accepted all recommendations — so this follows the recommender's output rather than overriding it. The recommendation itself is disposition-recommend.sh's, computed from the finding's fix_cost, feature_value, adjacent_to_blocking and category.", "rejected_alternative": "accept was considered on likelihood grounds, since most rounds dispatch each role once. Turned down because the fix loop's whole shape is repeated rounds with the same role names, so the collision is structural rather than unlucky." } ```

jbr870 commented

Author

Owner

{
  "status": "resolved",
  "chosen_option": "fix-now",
  "rationale": "[CR-20] The two-value enum is load-bearing for AC-7 and must not gain a third value, so the fix is a sentence saying which existing value covers a driver-initiated kill — trivial, and it removes the only case where a driver following the contract has no honest entry to write and would leave a claim held forever. Resolved under a standing instruction from the operator in this session — asked for /dev:resolve to be run and accepted all recommendations — so this follows the recommender's output rather than overriding it. The recommendation itself is disposition-recommend.sh's, computed from the finding's fix_cost, feature_value, adjacent_to_blocking and category.",
  "rejected_alternative": "defer-to-issue was not seriously in play; a one-sentence clarification inside a document the round is already rewriting has no plausible case for its own issue."
}

```json { "status": "resolved", "chosen_option": "fix-now", "rationale": "[CR-20] The two-value enum is load-bearing for AC-7 and must not gain a third value, so the fix is a sentence saying which existing value covers a driver-initiated kill — trivial, and it removes the only case where a driver following the contract has no honest entry to write and would leave a claim held forever. Resolved under a standing instruction from the operator in this session — asked for /dev:resolve to be run and accepted all recommendations — so this follows the recommender's output rather than overriding it. The recommendation itself is disposition-recommend.sh's, computed from the finding's fix_cost, feature_value, adjacent_to_blocking and category.", "rejected_alternative": "defer-to-issue was not seriously in play; a one-sentence clarification inside a document the round is already rewriting has no plausible case for its own issue." } ```

jbr870 commented

Author

Owner

{
  "status": "resolved",
  "chosen_option": "fix-now",
  "rationale": "[CR-21] Naming shared writable caches as a candidate class is one sentence and requires no new mandatory block, so it does not touch AC-5 or AC-6. It closes the gap the feature was written for at its own weakest point: the resource nobody thinks to declare until it has already cost a day, which is precisely the shape of the 18 minutes and five hours cited in the contract's own opening. Resolved under a standing instruction from the operator in this session — asked for /dev:resolve to be run and accepted all recommendations — so this follows the recommender's output rather than overriding it. The recommendation itself is disposition-recommend.sh's, computed from the finding's fix_cost, feature_value, adjacent_to_blocking and category.",
  "rejected_alternative": "accept was considered on the grounds that the project-declares-it escape hatch already covers this formally. Turned down because a formal escape hatch nobody knows to reach for is the same failure as the disclosure duty in CR-3 — a mechanism that cannot fire because nothing prompts anyone to feed it."
}

```json { "status": "resolved", "chosen_option": "fix-now", "rationale": "[CR-21] Naming shared writable caches as a candidate class is one sentence and requires no new mandatory block, so it does not touch AC-5 or AC-6. It closes the gap the feature was written for at its own weakest point: the resource nobody thinks to declare until it has already cost a day, which is precisely the shape of the 18 minutes and five hours cited in the contract's own opening. Resolved under a standing instruction from the operator in this session — asked for /dev:resolve to be run and accepted all recommendations — so this follows the recommender's output rather than overriding it. The recommendation itself is disposition-recommend.sh's, computed from the finding's fix_cost, feature_value, adjacent_to_blocking and category.", "rejected_alternative": "accept was considered on the grounds that the project-declares-it escape hatch already covers this formally. Turned down because a formal escape hatch nobody knows to reach for is the same failure as the disclosure duty in CR-3 — a mechanism that cannot fire because nothing prompts anyone to feed it." } ```

jbr870 commented

Author

Owner

{
  "status": "resolved",
  "chosen_option": "fix-now",
  "rationale": "[CR-22] qa-report:v1 is latest-wins, so the withdrawal mechanism already works whoever posts it; only the assignment is missing, and it currently names an actor that has exited by definition, since §9's premise is contention established late. One sentence naming the driver as the fallback poster makes an existing mechanism reachable. Resolved under a standing instruction from the operator in this session — asked for /dev:resolve to be run and accepted all recommendations — so this follows the recommender's output rather than overriding it. The recommendation itself is disposition-recommend.sh's, computed from the finding's fix_cost, feature_value, adjacent_to_blocking and category.",
  "rejected_alternative": "accept was considered because a careful reader would infer the driver can post. Turned down for the same reason as CR-8 — this feature's failures are consistently in what a reader must infer, and an agent taking the sentence literally waits on a dead actor."
}

```json { "status": "resolved", "chosen_option": "fix-now", "rationale": "[CR-22] qa-report:v1 is latest-wins, so the withdrawal mechanism already works whoever posts it; only the assignment is missing, and it currently names an actor that has exited by definition, since §9's premise is contention established late. One sentence naming the driver as the fallback poster makes an existing mechanism reachable. Resolved under a standing instruction from the operator in this session — asked for /dev:resolve to be run and accepted all recommendations — so this follows the recommender's output rather than overriding it. The recommendation itself is disposition-recommend.sh's, computed from the finding's fix_cost, feature_value, adjacent_to_blocking and category.", "rejected_alternative": "accept was considered because a careful reader would infer the driver can post. Turned down for the same reason as CR-8 — this feature's failures are consistently in what a reader must infer, and an agent taking the sentence literally waits on a dead actor." } ```

jbr870 commented

Author

Owner

{
  "status": "resolved",
  "chosen_option": "fix-now",
  "rationale": "[CR-23] It is in the same seven-line block as CR-1 and CR-6, both of which are blocking and must be rewritten this round, so it costs nothing extra. On its own merits it is small: grep's error text is redirected into the scan file by 2>&1 and would be read as data by the later sed, and a missing journal is reported identically to an empty one. Resolved under a standing instruction from the operator in this session — asked for /dev:resolve to be run and accepted all recommendations — so this follows the recommender's output rather than overriding it. The recommendation itself is disposition-recommend.sh's, computed from the finding's fix_cost, feature_value, adjacent_to_blocking and category.",
  "rejected_alternative": "defer-to-issue was not seriously in play. Fixing two blocking defects in a block while leaving a third known defect in the same seven lines would be indefensible on the next reading."
}

```json { "status": "resolved", "chosen_option": "fix-now", "rationale": "[CR-23] It is in the same seven-line block as CR-1 and CR-6, both of which are blocking and must be rewritten this round, so it costs nothing extra. On its own merits it is small: grep's error text is redirected into the scan file by 2>&1 and would be read as data by the later sed, and a missing journal is reported identically to an empty one. Resolved under a standing instruction from the operator in this session — asked for /dev:resolve to be run and accepted all recommendations — so this follows the recommender's output rather than overriding it. The recommendation itself is disposition-recommend.sh's, computed from the finding's fix_cost, feature_value, adjacent_to_blocking and category.", "rejected_alternative": "defer-to-issue was not seriously in play. Fixing two blocking defects in a block while leaving a third known defect in the same seven lines would be indefensible on the next reading." } ```

jbr870 commented

Author

Owner

{
  "status": "resolved",
  "chosen_option": "fix-now",
  "rationale": "[CR-24] The two orderings are reconcilable but nothing says so, and this is a document whose entire purpose is to be executed identically by different readers — a legibility defect in a normative contract is a correctness defect in slow motion. One clause stating that serialize is the resting state while reassign is the preferred remedy resolves it. Resolved under a standing instruction from the operator in this session — asked for /dev:resolve to be run and accepted all recommendations — so this follows the recommender's output rather than overriding it. The recommendation itself is disposition-recommend.sh's, computed from the finding's fix_cost, feature_value, adjacent_to_blocking and category.",
  "rejected_alternative": "accept was genuinely arguable because both readings lead to safe outcomes, so nothing breaks today. Turned down because the cost of the fix is a clause and the cost of leaving it is a permanent invitation to two readers reaching different dispatch decisions from one document."
}

```json { "status": "resolved", "chosen_option": "fix-now", "rationale": "[CR-24] The two orderings are reconcilable but nothing says so, and this is a document whose entire purpose is to be executed identically by different readers — a legibility defect in a normative contract is a correctness defect in slow motion. One clause stating that serialize is the resting state while reassign is the preferred remedy resolves it. Resolved under a standing instruction from the operator in this session — asked for /dev:resolve to be run and accepted all recommendations — so this follows the recommender's output rather than overriding it. The recommendation itself is disposition-recommend.sh's, computed from the finding's fix_cost, feature_value, adjacent_to_blocking and category.", "rejected_alternative": "accept was genuinely arguable because both readings lead to safe outcomes, so nothing breaks today. Turned down because the cost of the fix is a clause and the cost of leaving it is a permanent invitation to two readers reaching different dispatch decisions from one document." } ```

jbr870 commented

2026-08-25 13:57:46 +00:00

Author

Owner

{
  "status": "resolved",
  "chosen_option": "fix-now",
  "rationale": "[CR-25] The playbook self-describes as the control flow, and a driver working its numbered steps in order never reaches a step where the record gets written. Observed in this round: the driver wrote the journal because it had read the contract directly, not because any step told it to — so the citation discipline is working while the sequencing is not. Adding a step that says append DISPATCH here, append RELEASE there restates no rule and cites the contract for the shapes. Resolved under a standing instruction from the operator in this session — asked for /dev:resolve to be run and accepted all recommendations — so this follows the recommender's output rather than overriding it. The recommendation itself is disposition-recommend.sh's, computed from the finding's fix_cost, feature_value, adjacent_to_blocking and category.",
  "rejected_alternative": "defer-to-issue was considered because the omission is arguably correct reference discipline rather than a defect. Turned down because AC-9 depends on the record existing, and a control-flow document that never sequences the write is relying on every future driver reading a referenced document in full before acting."
}

```json { "status": "resolved", "chosen_option": "fix-now", "rationale": "[CR-25] The playbook self-describes as the control flow, and a driver working its numbered steps in order never reaches a step where the record gets written. Observed in this round: the driver wrote the journal because it had read the contract directly, not because any step told it to — so the citation discipline is working while the sequencing is not. Adding a step that says append DISPATCH here, append RELEASE there restates no rule and cites the contract for the shapes. Resolved under a standing instruction from the operator in this session — asked for /dev:resolve to be run and accepted all recommendations — so this follows the recommender's output rather than overriding it. The recommendation itself is disposition-recommend.sh's, computed from the finding's fix_cost, feature_value, adjacent_to_blocking and category.", "rejected_alternative": "defer-to-issue was considered because the omission is arguably correct reference discipline rather than a defect. Turned down because AC-9 depends on the record existing, and a control-flow document that never sequences the write is relying on every future driver reading a referenced document in full before acting." } ```

jbr870 referenced this issue

The new gate section is deliberately not fence-aware, contradicting an explicit SREQ constraint and a CLAUDE.md convention. #67

jbr870 commented

2026-08-25 13:57:46 +00:00

Author

Owner

Linked: this issue is sibling #67 (recorded by the devwork pipeline).

Linked: this issue is **sibling** #67 (recorded by the devwork pipeline).

jbr870 referenced this issue

2026-08-25 13:57:47 +00:00

All 17 contract scenarios build synthetic fixture documents instead of copying and mutating the real, already-landed ones. #68

jbr870 commented

2026-08-25 13:57:48 +00:00

Author

Owner

Linked: this issue is sibling #68 (recorded by the devwork pipeline).

Linked: this issue is **sibling** #68 (recorded by the devwork pipeline).

jbr870 commented

2026-08-25 14:30:58 +00:00

Author

Owner

{
  "outcome": "clean",
  "summary": "26 red scenarios across two suites, plus 2 positive controls and 3 newly-covered guards. Every intended test was written and verifies as expected; nothing went unwritten.",
  "findings": [],
  "artifacts": {
    "test_commit": "41768fe67dfd2ed1b1f10e79fbc9624192fc691a",
    "test_files": [
      "scripts/_red-lib.sh",
      "scripts/test-run-resource-claims.sh",
      "scripts/test-lint-conventions.sh"
    ],
    "test_marker": {
      "runner": "shell harness (bash) — scripts/test-*.sh",
      "write": "red_scenario \"<ID>\" <scenario_fn>   # <ID>: unfixed",
      "promote": "drop the `red_scenario \"<ID>\"` wrapper, calling <scenario_fn> directly"
    },
    "report_path": ".devwork/feature-qa-intra-run-lane-ownership/code-report.md",
    "journal_path": ".devwork/feature-qa-intra-run-lane-ownership/code-journal.md"
  },
  "notes": {
    "marker_semantics": "xfail(strict=True), not skip. The scenario RUNS; a failure prints RED (expected) and does not fail the suite; a PASS prints XPASS and DOES fail the suite (verified: suite rc=1). That second half is what catches a finding fixed without its marker promoted.",
    "coupling_verified": "The driver confirmed two scenarios (CR-1, CR-21) flip RED->XPASS when the real fix is applied to a scratch copy, so the red tests are genuinely coupled to the documents rather than being permanent complaints.",
    "snippet_tests": "CR-1/CR-2/CR-6 scenarios extract the fenced block from run-resource-claims.md and execute it, rather than testing a pasted transcription — a copy would stay green whether the shipped document was fixed or broken.",
    "unwrapped_by_design": "CR-16's three scenarios are unwrapped (not red_scenario): those guards were always correct, merely untested. Wrapping a passing test in a red marker would be false bookkeeping.",
    "left_for_the_fixer": "rrc_contract_landed() is deliberately still present. Removing it is CR-4's fix and belongs to the fixer, not to the actor writing the test that proves the defect.",
    "findings_added_since_validate": "CR-26 (the new suite is invoked by no gate), CR-27 (section 8.4 voids a sole owner's result, penalising the disclosure section 5 requires) and CR-28 (CR-4 diagnostics embed inner marker strings, inflating a substring count) were found during this stage and are carried into the fix round. The validate-phase report is superseded by a later post rather than edited."
  }
}

```json { "outcome": "clean", "summary": "26 red scenarios across two suites, plus 2 positive controls and 3 newly-covered guards. Every intended test was written and verifies as expected; nothing went unwritten.", "findings": [], "artifacts": { "test_commit": "41768fe67dfd2ed1b1f10e79fbc9624192fc691a", "test_files": [ "scripts/_red-lib.sh", "scripts/test-run-resource-claims.sh", "scripts/test-lint-conventions.sh" ], "test_marker": { "runner": "shell harness (bash) — scripts/test-*.sh", "write": "red_scenario \"<ID>\" <scenario_fn> # <ID>: unfixed", "promote": "drop the `red_scenario \"<ID>\"` wrapper, calling <scenario_fn> directly" }, "report_path": ".devwork/feature-qa-intra-run-lane-ownership/code-report.md", "journal_path": ".devwork/feature-qa-intra-run-lane-ownership/code-journal.md" }, "notes": { "marker_semantics": "xfail(strict=True), not skip. The scenario RUNS; a failure prints RED (expected) and does not fail the suite; a PASS prints XPASS and DOES fail the suite (verified: suite rc=1). That second half is what catches a finding fixed without its marker promoted.", "coupling_verified": "The driver confirmed two scenarios (CR-1, CR-21) flip RED->XPASS when the real fix is applied to a scratch copy, so the red tests are genuinely coupled to the documents rather than being permanent complaints.", "snippet_tests": "CR-1/CR-2/CR-6 scenarios extract the fenced block from run-resource-claims.md and execute it, rather than testing a pasted transcription — a copy would stay green whether the shipped document was fixed or broken.", "unwrapped_by_design": "CR-16's three scenarios are unwrapped (not red_scenario): those guards were always correct, merely untested. Wrapping a passing test in a red marker would be false bookkeeping.", "left_for_the_fixer": "rrc_contract_landed() is deliberately still present. Removing it is CR-4's fix and belongs to the fixer, not to the actor writing the test that proves the defect.", "findings_added_since_validate": "CR-26 (the new suite is invoked by no gate), CR-27 (section 8.4 voids a sole owner's result, penalising the disclosure section 5 requires) and CR-28 (CR-4 diagnostics embed inner marker strings, inflating a substring count) were found during this stage and are carried into the fix round. The validate-phase report is superseded by a later post rather than edited." } } ```

jbr870 referenced this issue

2026-08-25 14:33:54 +00:00

wait-discipline: no retry/resume protocol for transient API errors or quota stalls #46

jbr870 referenced this issue

2026-08-25 15:00:35 +00:00

wait-discipline: no retry/resume protocol for transient API errors or quota stalls #46

jbr870 commented

2026-08-25 15:48:40 +00:00

Author

Owner

{
  "outcome": "clean",
  "summary": "All 23 in-scope findings from round 1 fixed and verified across two commits (0b297ff documents, 960d686 harness). Four gates green on the committed tree.",
  "findings": [],
  "artifacts": {
    "fix_commits": [
      "0b297ff",
      "960d686"
    ],
    "test_commit": "41768fe",
    "report_path": ".devwork/feature-qa-intra-run-lane-ownership/code-report.md",
    "journal_path": ".devwork/feature-qa-intra-run-lane-ownership/code-journal.md"
  },
  "verification": {
    "scripts/lint-conventions.sh": "rc=0 clean",
    "scripts/test-lint-conventions.sh": "rc=0, 28 PASS / 0 FAIL",
    "scripts/test-run-resource-claims.sh": "rc=0, 24 PASS / 0 FAIL",
    "scripts/test-plugin-gates.sh": "rc=0, 17/17 — run AFTER commit, since it measures HEAD not the working tree"
  },
  "notes": {
    "assertion_constraint": "Verified against test_commit 41768fe. The documents fixer's diff to the test files was 22 hunks, every one a red_scenario wrapper removal — no assertion, scenario body or helper touched. The harness fixer's non-marker edits to test code were pre-licensed (CR-28 is a finding AGAINST the test code) and enumerated individually in its report.",
    "driver_defect": "The red-marker promote transform declared in CLAUDE.md was not inverse-consistent and was the driver's own error, not a fixer's. Corrected in 0b297ff (run_scenario). Downgraded Critical to Medium after the documents fixer correctly contradicted the driver's diagnosis: set -euo pipefail means a bare call still aborts on failure, so the defect was observability, not a false green.",
    "cr4_proof": "CR-4's fix was proven against the driver's own original probe, same script both times: with the canonical document deleted, the pre-fix harness reported 21/21 rc=0 (masked); the post-fix harness reports rc=1 with the control FAILing (caught). The unrelated-violation control still fails loudly, so the fix did not merely make the control paranoid.",
    "caveat": "This report records the fix stage's outcome. The SWEEP that followed found new findings against this same tree — see the qa-report:v1 (phase=validate) posted after this one. The round does NOT exit."
  }
}

```json { "outcome": "clean", "summary": "All 23 in-scope findings from round 1 fixed and verified across two commits (0b297ff documents, 960d686 harness). Four gates green on the committed tree.", "findings": [], "artifacts": { "fix_commits": [ "0b297ff", "960d686" ], "test_commit": "41768fe", "report_path": ".devwork/feature-qa-intra-run-lane-ownership/code-report.md", "journal_path": ".devwork/feature-qa-intra-run-lane-ownership/code-journal.md" }, "verification": { "scripts/lint-conventions.sh": "rc=0 clean", "scripts/test-lint-conventions.sh": "rc=0, 28 PASS / 0 FAIL", "scripts/test-run-resource-claims.sh": "rc=0, 24 PASS / 0 FAIL", "scripts/test-plugin-gates.sh": "rc=0, 17/17 — run AFTER commit, since it measures HEAD not the working tree" }, "notes": { "assertion_constraint": "Verified against test_commit 41768fe. The documents fixer's diff to the test files was 22 hunks, every one a red_scenario wrapper removal — no assertion, scenario body or helper touched. The harness fixer's non-marker edits to test code were pre-licensed (CR-28 is a finding AGAINST the test code) and enumerated individually in its report.", "driver_defect": "The red-marker promote transform declared in CLAUDE.md was not inverse-consistent and was the driver's own error, not a fixer's. Corrected in 0b297ff (run_scenario). Downgraded Critical to Medium after the documents fixer correctly contradicted the driver's diagnosis: set -euo pipefail means a bare call still aborts on failure, so the defect was observability, not a false green.", "cr4_proof": "CR-4's fix was proven against the driver's own original probe, same script both times: with the canonical document deleted, the pre-fix harness reported 21/21 rc=0 (masked); the post-fix harness reports rc=1 with the control FAILing (caught). The unrelated-violation control still fails loudly, so the fix did not merely make the control paranoid.", "caveat": "This report records the fix stage's outcome. The SWEEP that followed found new findings against this same tree — see the qa-report:v1 (phase=validate) posted after this one. The round does NOT exit." } } ```

jbr870 commented

2026-08-25 15:50:24 +00:00

Author

Owner

{
  "outcome": "issues-found",
  "summary": "SWEEP (round 1 exit gate) — 15 findings against the post-fix tree at 960d686, 2 Critical. The round does NOT exit; next_state stays qa.",
  "findings": [
    {
      "id": "CR-31",
      "category": "in-scope-blocking",
      "severity": "Critical",
      "summary": "The CR-4 regression scenarios are vacuous: the recursion guard's `return 1` makes the inner suite exit non-zero unconditionally, so the outer `rc != 0` assertion is always true.",
      "reasoning": "Reproduced by the driver: `RRC_INNER_RUN=1 bash scripts/test-lint-conventions.sh` on a PRISTINE, unmutated tree exits rc=1 with exactly two FAIL lines — both the guard's own bookkeeping. The guard does `return 1`, and in the inner run the CR-4 scenarios are themselves `run_scenario`-wrapped, so that routes through fail() and increments fail_count by 2. Re-introduce the exact CR-4 defect and the inner control passes on the mutated tree while the two guard FAILs still force rc=1 — both scenarios report 'correctly went red' and the suite is green. This is the third false green of the round and it is inside the flagship regression test of the commit that fixed the second. IMPORTANT: CR-4's fix is real — the driver's manual before/after probe measured the shipped harness directly (masked at 21/21 rc=0, caught at rc=1 with the control FAILing) and stands. What is vacuous is the scenario meant to guard it going forward. Fix: the guard returns 0 (or the scenarios are not run_scenario-wrapped in the inner run), AND the outer assertion keys on the inner output containing `FAIL: control_clean_tree` rather than on bare rc — the same 'assert on the specific failure, not the exit code' rule this round put in every brief."
    },
    {
      "id": "CR-32",
      "category": "in-scope-blocking",
      "severity": "Critical",
      "summary": "§7 step 4 contradicts §8.4: it voids a sole owner on its own disclosure, which is exactly what the CR-27 fix removed.",
      "reasoning": "§7 step 4 reads 'an overran_claim: true on any actor whose window intersects the one you are triaging — the triaged actor itself included — ... It is void'. §8.4 as amended reads 'An overrun by an actor that held sole ownership is recorded, not voided.' §7 was not updated when §8.4 was narrowed. Reproduced by hand against this round's own journal: qa-fix-F1-docs holds window [16:31:17, 17:03:13) with no intersecting actor, so step 3 finds no colliding pair — but F1 carries overran_claim: true and step 4's 'the triaged actor itself included' voids its entire fix-stage output on the strength of its own honest disclosure. The driver disposed all three of this round's overruns per §8.4, i.e. against the shipped checklist. Critical rather than Medium because §7 is written as an executable block to copy and run, precisely so a driver need not reason it out — and as shipped it re-creates the disclosure disincentive the CR-27 fix existed to remove. Found independently by the sweep's claims reviewer and by the driver's own read."
    },
    {
      "id": "CR-33",
      "category": "in-scope-blocking",
      "severity": "High",
      "summary": "§4's normative rule 'empty output means dispatch concurrently' is false for `workers`, the one class the filter structurally cannot judge — CR-2's defect reborn one class over.",
      "reasoning": "The rewritten filter subtracts `workers` from its class list, so it can never emit a workers entry: not for a one-sided claim, not for an absent-both claim, not for a budget overflow. Two breaking inputs. (a) Both claims omit `workers`: §3 says an absent key is unknown ⇒ serialize, the filter prints [], and the bold rule says dispatch — §3 and §4 give opposite answers for one input, and unlike every other class no verdict: 'unknown' is emitted. (b) A and B both claim workers: 8 on an 8-worker pool with a third actor holding 4: output [], driver dispatches, pool oversubscribed. The budget test exists only as a trailing comment inside the fence; the normative prose does not carve workers out. This is the exact defect CR-2 fixed for the identity classes — [] standing for 'could not judge' — surviving in the same rewrite that fixed it."
    },
    {
      "id": "CR-34",
      "category": "in-scope-blocking",
      "severity": "High",
      "summary": "§7 step 4 never consults `overran_resources`, the field CR-10 added for exactly this, so any overrun by a window-peer contaminates regardless of what it touched.",
      "reasoning": "journal-template.md states the purpose in terms: 'a bare boolean cannot be intersected with anything, and intersecting resources is the whole of §7's method'. Step 4 does not intersect. Breaking scenario: actor A overruns onto `external`; actor B's window intersects A's and B touched only `database`. Step 4 voids B, demanding a re-run that cannot change anything, because A's overrun could not have moved anything B observed. §7's own adjacent note makes precisely this argument one step earlier — it rejects a global reading because 'reading it as global would void half a feature's records from one honest disclosure, which is also how a contract teaches actors to stop disclosing' — then stops short of applying the same reasoning to resources, with the data to do so now in the record."
    },
    {
      "id": "CR-35",
      "category": "in-scope-blocking",
      "severity": "High",
      "summary": "§2's widened vocabulary never reached §5's duty language or §8's consequence table, both of which still enumerate the original four classes.",
      "reasoning": "The CR-21 fix widened §2 to name shared writable scratch/cache surfaces and 'any shared artefact one actor writes while another reads or executes it'. §5's duty sentence still reads 'a database, port, worker budget or external resource its claim did not name', and §8's machinery keys off the same four-class overran_claim/overran_resources shape. Consequence, observed: qa-tests-T1-contract wrote and read /tmp/dispatch-scan.txt and recorded overran_claim: false — correctly, under §5's literal text, because a shared scratch path is not one of the four. So the use never enters §8's table, is never voided, is never flagged unknown; it falls through to actor discretion, which is what the contract exists to stop relying on. §2 says such a surface 'cannot be named as an identity at all, it is an unknown, which §1 sends to serialization', but nothing in §3/§4 lets a driver DETECT an unnamed shared surface before dispatch — so the widened class is discoverable only after the fact via disclosure, a materially weaker guarantee than the pre-dispatch comparison the four named classes get. The text reads as closed while being open."
    },
    {
      "id": "CR-36",
      "category": "in-scope-blocking",
      "severity": "High",
      "summary": "`overran_resources` is required-but-absent on 3 of 3 real overrun entries — records the driver itself wrote, in the run that defined the field.",
      "reasoning": "journal-template.md requires overran_resources on any RELEASE whose overran_claim is true. Counted in this round's journal: 3 entries with overran_claim: true, 0 with overran_resources. The driver wrote all three through a helper that had no such parameter. The information exists only in each entry's prose Note, which §7's key-scan cannot read — so running §7 against this journal today correctly flags three overruns and has nothing to intersect for any of them, defeating the answer-from-the-record design in the reference run. Nothing mechanical checks the requirement, which is why it went unnoticed: CR-26's shape again, a rule with no enforcement path is a rule that will be missed. Remedied for the human record by an appended correction entry supplying the three values; a mechanical scan still reads the originals, which is CR-38."
    },
    {
      "id": "CR-37",
      "category": "in-scope-deferrable",
      "severity": "Medium",
      "summary": "qa-playbook's RELEASE step drops §5's quiescence condition — the same permissive paraphrase drift the same file's CR-17 fix warns about 80 lines earlier.",
      "reasoning": "qa-playbook sequences 'once wait-discipline §1a has concluded that actor is done — its report arrived, or a death check settled it — append the matching RELEASE entry'. §5.1 (the CR-12 fix) says the report is the trigger, not the proof: confirm processes gone and ports free BEFORE writing RELEASE. A driver working qa-playbook's numbered loop writes RELEASE on report arrival and dispatches the next actor onto a straggling watch-mode runner — §5's own worked example. develop/SKILL.md defers correctly; qa-playbook embeds the incomplete half-rule. One clause fixes it, and the round created this instance while fixing another in the same file.",
      "proposed_action": "fix-in-this-feature",
      "fix_cost": "trivial",
      "feature_value": "core",
      "adjacent_to_blocking": true
    },
    {
      "id": "CR-38",
      "category": "in-scope-deferrable",
      "severity": "Medium",
      "summary": "The contract has no pattern for superseding a fact already written, so every correction restores the human record and not the machine one.",
      "reasoning": "Journals are append-only, which is right. But nothing names how to supersede a written fact. This round needed it three times: the hand-estimated timestamps, the missing overran_resources, and the preamble's external: [] which qa-fix-F1-docs falsified. The first got a correction entry by improvisation; the other two went unnoticed until a reviewer asked. Because §7's scan reads YAML keys and every correction is prose in a DISCOVERY entry, a mechanical triage today still reads the original wrong timestamps and still finds no overran_resources. For a contract whose whole promise is 'answer it from the record', that is the half that matters. qa-report:v1 solved exactly this with latest-wins supersession; the journal has no equivalent.",
      "proposed_action": "fix-in-this-feature",
      "fix_cost": "small",
      "feature_value": "core",
      "adjacent_to_blocking": false
    },
    {
      "id": "CR-39",
      "category": "in-scope-deferrable",
      "severity": "Medium",
      "summary": "§8.4's narrowed void assumes every resource user is a journaled claim-holder — the driver itself is invisible to the §7 scan.",
      "reasoning": "The carve-out is decided by the §7 scan over the journal, and only dispatched suite-running actors appear there. Two users never do: the driver, which writes no DISPATCH for its own suite runs (this round's driver ran gates inline repeatedly), and a no-claims actor whose work still collides via §2's writer-vs-executor shape. Breaking scenario: validator V claims database []; the driver reseeds the repo-default database while V runs; V discloses it also touched that database. §7 finds no other claim-holder's window, so sole ownership applies, the result is recorded not voided, and it gets cited. The pre-fix unconditional void caught this. The narrowing is well argued on disclosure incentives, but never states its load-bearing assumption: that while any claim is open the driver touches nothing in the claim vocabulary, or self-records if it does.",
      "proposed_action": "fix-in-this-feature",
      "fix_cost": "trivial",
      "feature_value": "core",
      "adjacent_to_blocking": true
    },
    {
      "id": "CR-40",
      "category": "in-scope-deferrable",
      "severity": "Medium",
      "summary": "CR-1's scenario hard-depends on a gitignored machine-local journal, so a required Verification command reds on any fresh clone.",
      "reasoning": "The scenario asserts against .devwork/feature-qa-intra-run-lane-ownership/dispatch-journal.md, and .devwork/ is gitignored local staging. CLAUDE.md now names this suite as one of four required Verification commands. On a fresh clone, another machine, the main checkout after this branch integrates, or this machine once .devwork is drained post-close, the copy fails and CR-1 fails the whole suite. A required test command that reds on a clean clone is worse than none. Using the real journal was the right instinct — a synthetic fixture is the CR-15/#68 defect — but the real record is untracked; the fix is a committed fixture journal as a fallback when the real one is absent.",
      "proposed_action": "fix-in-this-feature",
      "fix_cost": "small",
      "feature_value": "core",
      "adjacent_to_blocking": false
    },
    {
      "id": "CR-41",
      "category": "in-scope-deferrable",
      "severity": "Medium",
      "summary": "§4 validates only the top-level type, so malformed elements inside a claim array stringify and compare as literals, yielding a false disjoint.",
      "reasoning": "The 'not a flat identity set' branch checks only that the value is an array; element types are never checked, and §3's 'scalars and flat string lists only' is enforced nowhere. Breaking input: A={database:[{name:'app_test'}]} — a nested map, forbidden by §3 but rejected by nothing — against B={database:['app_test']}. tostring gives {\"name\":\"app_test\"} versus app_test, the intersection is empty, and both are dispatched onto app_test. A nested list does the same. The round's own 'refuse to guess' principle says these should return verdict: 'unknown'.",
      "proposed_action": "fix-in-this-feature",
      "fix_cost": "small",
      "feature_value": "core",
      "adjacent_to_blocking": true
    },
    {
      "id": "CR-42",
      "category": "in-scope-deferrable",
      "severity": "Medium",
      "summary": "CR-23's stderr-leak assertion was half-vacuated by the CR-7 mktemp fix it verifies, and its comment describes the pre-fix recipe.",
      "reasoning": "The scenario still reads /tmp/dispatch-scan.txt and greps for grep error text, but the shipped §7 recipe now mktemps its scan file and traps-cleans it, so that buffer is always empty and the assertion can never fire. If a future edit reintroduced 2>&1 into the scan redirect — the exact regression CR-23 exists for — the scenario would stay green. Only the missing-versus-empty half still measures. Two stale comments ride along: CR-23's block still calls CR-7 'a separate, deferred finding' when CR-7 shipped in 0b297ff, and the CR-2(d) comment still describes the pre-fix filter. A fix that vacates its own regression test is the CR-31 shape at smaller scale.",
      "proposed_action": "fix-in-this-feature",
      "fix_cost": "small",
      "feature_value": "core",
      "adjacent_to_blocking": true
    },
    {
      "id": "CR-43",
      "category": "in-scope-deferrable",
      "severity": "Low",
      "summary": "Eleven further sweep findings: parser and vocabulary gaps in the shipped recipes and helpers.",
      "reasoning": "Indexed together because each is a one-to-three-line fix and they share no root beyond 'the shipped text meets an input its author did not picture'. doc_grep_folded is not wrap-safe for INDENTED continuation lines, so the wrap-safe helper has its own wrap bug. §7 has a fourth silent unusable-record state: DISPATCH entries with no claims lines pass the grep, extract nothing, exit 0. §7's key-quoting regex cannot parse a kebab-case project-named class, the naming style this repo uses everywhere. Near-miss port spellings ('4080 - 4089', en-dash, leading zeros) compare as literal names and read disjoint. §8 uses the word 'lane' four sections before §11 declares neither vocabulary uses the other's word. develop §3.1's remedy paraphrase drops reassignment, silently discarding the remedy that keeps wave concurrency. Disclosure consumption is unsequenced: no consumer step tells the driver to read a report for a disclosure when filling the RELEASE entry. extract_bash_block_containing is not fence-aware for 4-backtick wrappers, the exact trap CLAUDE.md's fence-tracker rule names. ended_by_offenders has a latent false positive on inline-code prose mentions. AC-14's uniqueness scan is line-scoped while its presence check is not, so a WRAPPED restatement in a consumer escapes — the third appearance of the wrapped-anchor failure on this feature. make_real_tree_copy copies the entire repo, which from the main checkout means every sibling worktree, twice per run.",
      "proposed_action": "defer-to-issue",
      "fix_cost": "substantial",
      "feature_value": "incidental",
      "adjacent_to_blocking": false
    },
    {
      "id": "CR-44",
      "category": "in-scope-deferrable",
      "severity": "Low",
      "summary": "`waited_ms` was populated once, as 0, despite three serializations — the field added to end an argument did not end it.",
      "reasoning": "§6 says waited_ms exists 'so the cost of serializing is measured from the record instead of argued about'. This round serialized three times and recorded the wait once, as zero. The cost is recoverable only by manually subtracting dispatch-minus-prior-release timestamps, which is precisely the state the field was added to end. An optional field the reference run does not fill is a field that will not be filled — the same shape as overran_resources (CR-36), one severity down because nothing depends on it.",
      "proposed_action": "fix-in-this-feature",
      "fix_cost": "trivial",
      "feature_value": "incidental",
      "adjacent_to_blocking": false
    },
    {
      "id": "CR-45",
      "category": "out-of-scope",
      "severity": "Medium",
      "summary": "Three rounds of the same failure shape — a fix landing where the finding pointed rather than everywhere the rule lives — is evidence about the design, not three unrelated defects.",
      "reasoning": "CR-2 fixed []-means-could-not-judge for identity classes and workers reproduces it in the same rewrite (CR-33). CR-17 fixed a permissive paraphrase in qa-playbook and CR-12's fix created a new one in the same file 80 lines away (CR-37). CR-4's fix is guarded by a test that proves nothing (CR-31). CR-27 narrowed §8.4 without updating §7 (CR-32). CR-10 added a field §7 never consults and no entry populates (CR-34, CR-36). CR-21 widened §2 without touching §5 or §8 (CR-35). This is the drift AC-14's lint check exists to catch, but that check guards six anchor phrases and nothing else. fix-workflow.md §2's convergence rule is directly on point: a second re-validation finding of the same CLASS as the one just fixed ends the patching, and its two exits are a round explicitly framed at the class, or deferral with the residue recorded — not a third patch pass of the same shape. Raised as a finding rather than acted on, because choosing between those exits is the operator's call.",
      "proposed_action": "defer-to-issue",
      "fix_cost": "substantial",
      "feature_value": "core",
      "adjacent_to_blocking": false
    }
  ],
  "artifacts": {
    "report_path": ".devwork/feature-qa-intra-run-lane-ownership/code-report.md",
    "journal_path": ".devwork/feature-qa-intra-run-lane-ownership/code-journal.md",
    "dispatch_journal": ".devwork/feature-qa-intra-run-lane-ownership/dispatch-journal.md",
    "swept_head": "960d686"
  },
  "notes": {
    "supersedes": "This supersedes the phase=validate report at comment 1405 by latest-wins. 1405 recorded round 1's findings against the PRE-fix tree; all 23 in-scope ones were fixed and verified (see phase=fix, comment 1689). These 15 are NEW, against the post-fix tree.",
    "adversarial_pass": "Carried by a fable Bug Hunter in fresh context against the post-fix tree, per qa-playbook §7 — never the fixer's context. It was told to assume a third false green existed; it found one (CR-31) and the driver reproduced it.",
    "exit_invariant": "qa-playbook §7: QA is done when a full sweep completes with nothing modified after it. This sweep found findings, so this is a new round, including its own sweep. The invariant is a check against the record, not a read of the trend — the finding count rose 25 -> 30 -> 45 across the round and that is not what decides it.",
    "tool_deviation": "The Bug Hunter's brief said Read/Grep/Glob only, no Bash. Its session had no Grep/Glob tools, so it used Bash strictly read-only and DISCLOSED the deviation rather than working around it silently. Driver confirmed via git status that the sweep modified nothing.",
    "convergence": "CR-45 records that three rounds of the same failure shape is itself evidence. fix-workflow.md §2's convergence rule applies and its two exits are a round framed at the class, or deferral with residue recorded — not a third patch pass of the same shape. That choice is the operator's."
  }
}

```json { "outcome": "issues-found", "summary": "SWEEP (round 1 exit gate) — 15 findings against the post-fix tree at 960d686, 2 Critical. The round does NOT exit; next_state stays qa.", "findings": [ { "id": "CR-31", "category": "in-scope-blocking", "severity": "Critical", "summary": "The CR-4 regression scenarios are vacuous: the recursion guard's `return 1` makes the inner suite exit non-zero unconditionally, so the outer `rc != 0` assertion is always true.", "reasoning": "Reproduced by the driver: `RRC_INNER_RUN=1 bash scripts/test-lint-conventions.sh` on a PRISTINE, unmutated tree exits rc=1 with exactly two FAIL lines — both the guard's own bookkeeping. The guard does `return 1`, and in the inner run the CR-4 scenarios are themselves `run_scenario`-wrapped, so that routes through fail() and increments fail_count by 2. Re-introduce the exact CR-4 defect and the inner control passes on the mutated tree while the two guard FAILs still force rc=1 — both scenarios report 'correctly went red' and the suite is green. This is the third false green of the round and it is inside the flagship regression test of the commit that fixed the second. IMPORTANT: CR-4's fix is real — the driver's manual before/after probe measured the shipped harness directly (masked at 21/21 rc=0, caught at rc=1 with the control FAILing) and stands. What is vacuous is the scenario meant to guard it going forward. Fix: the guard returns 0 (or the scenarios are not run_scenario-wrapped in the inner run), AND the outer assertion keys on the inner output containing `FAIL: control_clean_tree` rather than on bare rc — the same 'assert on the specific failure, not the exit code' rule this round put in every brief." }, { "id": "CR-32", "category": "in-scope-blocking", "severity": "Critical", "summary": "§7 step 4 contradicts §8.4: it voids a sole owner on its own disclosure, which is exactly what the CR-27 fix removed.", "reasoning": "§7 step 4 reads 'an overran_claim: true on any actor whose window intersects the one you are triaging — the triaged actor itself included — ... It is void'. §8.4 as amended reads 'An overrun by an actor that held sole ownership is recorded, not voided.' §7 was not updated when §8.4 was narrowed. Reproduced by hand against this round's own journal: qa-fix-F1-docs holds window [16:31:17, 17:03:13) with no intersecting actor, so step 3 finds no colliding pair — but F1 carries overran_claim: true and step 4's 'the triaged actor itself included' voids its entire fix-stage output on the strength of its own honest disclosure. The driver disposed all three of this round's overruns per §8.4, i.e. against the shipped checklist. Critical rather than Medium because §7 is written as an executable block to copy and run, precisely so a driver need not reason it out — and as shipped it re-creates the disclosure disincentive the CR-27 fix existed to remove. Found independently by the sweep's claims reviewer and by the driver's own read." }, { "id": "CR-33", "category": "in-scope-blocking", "severity": "High", "summary": "§4's normative rule 'empty output means dispatch concurrently' is false for `workers`, the one class the filter structurally cannot judge — CR-2's defect reborn one class over.", "reasoning": "The rewritten filter subtracts `workers` from its class list, so it can never emit a workers entry: not for a one-sided claim, not for an absent-both claim, not for a budget overflow. Two breaking inputs. (a) Both claims omit `workers`: §3 says an absent key is unknown ⇒ serialize, the filter prints [], and the bold rule says dispatch — §3 and §4 give opposite answers for one input, and unlike every other class no verdict: 'unknown' is emitted. (b) A and B both claim workers: 8 on an 8-worker pool with a third actor holding 4: output [], driver dispatches, pool oversubscribed. The budget test exists only as a trailing comment inside the fence; the normative prose does not carve workers out. This is the exact defect CR-2 fixed for the identity classes — [] standing for 'could not judge' — surviving in the same rewrite that fixed it." }, { "id": "CR-34", "category": "in-scope-blocking", "severity": "High", "summary": "§7 step 4 never consults `overran_resources`, the field CR-10 added for exactly this, so any overrun by a window-peer contaminates regardless of what it touched.", "reasoning": "journal-template.md states the purpose in terms: 'a bare boolean cannot be intersected with anything, and intersecting resources is the whole of §7's method'. Step 4 does not intersect. Breaking scenario: actor A overruns onto `external`; actor B's window intersects A's and B touched only `database`. Step 4 voids B, demanding a re-run that cannot change anything, because A's overrun could not have moved anything B observed. §7's own adjacent note makes precisely this argument one step earlier — it rejects a global reading because 'reading it as global would void half a feature's records from one honest disclosure, which is also how a contract teaches actors to stop disclosing' — then stops short of applying the same reasoning to resources, with the data to do so now in the record." }, { "id": "CR-35", "category": "in-scope-blocking", "severity": "High", "summary": "§2's widened vocabulary never reached §5's duty language or §8's consequence table, both of which still enumerate the original four classes.", "reasoning": "The CR-21 fix widened §2 to name shared writable scratch/cache surfaces and 'any shared artefact one actor writes while another reads or executes it'. §5's duty sentence still reads 'a database, port, worker budget or external resource its claim did not name', and §8's machinery keys off the same four-class overran_claim/overran_resources shape. Consequence, observed: qa-tests-T1-contract wrote and read /tmp/dispatch-scan.txt and recorded overran_claim: false — correctly, under §5's literal text, because a shared scratch path is not one of the four. So the use never enters §8's table, is never voided, is never flagged unknown; it falls through to actor discretion, which is what the contract exists to stop relying on. §2 says such a surface 'cannot be named as an identity at all, it is an unknown, which §1 sends to serialization', but nothing in §3/§4 lets a driver DETECT an unnamed shared surface before dispatch — so the widened class is discoverable only after the fact via disclosure, a materially weaker guarantee than the pre-dispatch comparison the four named classes get. The text reads as closed while being open." }, { "id": "CR-36", "category": "in-scope-blocking", "severity": "High", "summary": "`overran_resources` is required-but-absent on 3 of 3 real overrun entries — records the driver itself wrote, in the run that defined the field.", "reasoning": "journal-template.md requires overran_resources on any RELEASE whose overran_claim is true. Counted in this round's journal: 3 entries with overran_claim: true, 0 with overran_resources. The driver wrote all three through a helper that had no such parameter. The information exists only in each entry's prose Note, which §7's key-scan cannot read — so running §7 against this journal today correctly flags three overruns and has nothing to intersect for any of them, defeating the answer-from-the-record design in the reference run. Nothing mechanical checks the requirement, which is why it went unnoticed: CR-26's shape again, a rule with no enforcement path is a rule that will be missed. Remedied for the human record by an appended correction entry supplying the three values; a mechanical scan still reads the originals, which is CR-38." }, { "id": "CR-37", "category": "in-scope-deferrable", "severity": "Medium", "summary": "qa-playbook's RELEASE step drops §5's quiescence condition — the same permissive paraphrase drift the same file's CR-17 fix warns about 80 lines earlier.", "reasoning": "qa-playbook sequences 'once wait-discipline §1a has concluded that actor is done — its report arrived, or a death check settled it — append the matching RELEASE entry'. §5.1 (the CR-12 fix) says the report is the trigger, not the proof: confirm processes gone and ports free BEFORE writing RELEASE. A driver working qa-playbook's numbered loop writes RELEASE on report arrival and dispatches the next actor onto a straggling watch-mode runner — §5's own worked example. develop/SKILL.md defers correctly; qa-playbook embeds the incomplete half-rule. One clause fixes it, and the round created this instance while fixing another in the same file.", "proposed_action": "fix-in-this-feature", "fix_cost": "trivial", "feature_value": "core", "adjacent_to_blocking": true }, { "id": "CR-38", "category": "in-scope-deferrable", "severity": "Medium", "summary": "The contract has no pattern for superseding a fact already written, so every correction restores the human record and not the machine one.", "reasoning": "Journals are append-only, which is right. But nothing names how to supersede a written fact. This round needed it three times: the hand-estimated timestamps, the missing overran_resources, and the preamble's external: [] which qa-fix-F1-docs falsified. The first got a correction entry by improvisation; the other two went unnoticed until a reviewer asked. Because §7's scan reads YAML keys and every correction is prose in a DISCOVERY entry, a mechanical triage today still reads the original wrong timestamps and still finds no overran_resources. For a contract whose whole promise is 'answer it from the record', that is the half that matters. qa-report:v1 solved exactly this with latest-wins supersession; the journal has no equivalent.", "proposed_action": "fix-in-this-feature", "fix_cost": "small", "feature_value": "core", "adjacent_to_blocking": false }, { "id": "CR-39", "category": "in-scope-deferrable", "severity": "Medium", "summary": "§8.4's narrowed void assumes every resource user is a journaled claim-holder — the driver itself is invisible to the §7 scan.", "reasoning": "The carve-out is decided by the §7 scan over the journal, and only dispatched suite-running actors appear there. Two users never do: the driver, which writes no DISPATCH for its own suite runs (this round's driver ran gates inline repeatedly), and a no-claims actor whose work still collides via §2's writer-vs-executor shape. Breaking scenario: validator V claims database []; the driver reseeds the repo-default database while V runs; V discloses it also touched that database. §7 finds no other claim-holder's window, so sole ownership applies, the result is recorded not voided, and it gets cited. The pre-fix unconditional void caught this. The narrowing is well argued on disclosure incentives, but never states its load-bearing assumption: that while any claim is open the driver touches nothing in the claim vocabulary, or self-records if it does.", "proposed_action": "fix-in-this-feature", "fix_cost": "trivial", "feature_value": "core", "adjacent_to_blocking": true }, { "id": "CR-40", "category": "in-scope-deferrable", "severity": "Medium", "summary": "CR-1's scenario hard-depends on a gitignored machine-local journal, so a required Verification command reds on any fresh clone.", "reasoning": "The scenario asserts against .devwork/feature-qa-intra-run-lane-ownership/dispatch-journal.md, and .devwork/ is gitignored local staging. CLAUDE.md now names this suite as one of four required Verification commands. On a fresh clone, another machine, the main checkout after this branch integrates, or this machine once .devwork is drained post-close, the copy fails and CR-1 fails the whole suite. A required test command that reds on a clean clone is worse than none. Using the real journal was the right instinct — a synthetic fixture is the CR-15/#68 defect — but the real record is untracked; the fix is a committed fixture journal as a fallback when the real one is absent.", "proposed_action": "fix-in-this-feature", "fix_cost": "small", "feature_value": "core", "adjacent_to_blocking": false }, { "id": "CR-41", "category": "in-scope-deferrable", "severity": "Medium", "summary": "§4 validates only the top-level type, so malformed elements inside a claim array stringify and compare as literals, yielding a false disjoint.", "reasoning": "The 'not a flat identity set' branch checks only that the value is an array; element types are never checked, and §3's 'scalars and flat string lists only' is enforced nowhere. Breaking input: A={database:[{name:'app_test'}]} — a nested map, forbidden by §3 but rejected by nothing — against B={database:['app_test']}. tostring gives {\"name\":\"app_test\"} versus app_test, the intersection is empty, and both are dispatched onto app_test. A nested list does the same. The round's own 'refuse to guess' principle says these should return verdict: 'unknown'.", "proposed_action": "fix-in-this-feature", "fix_cost": "small", "feature_value": "core", "adjacent_to_blocking": true }, { "id": "CR-42", "category": "in-scope-deferrable", "severity": "Medium", "summary": "CR-23's stderr-leak assertion was half-vacuated by the CR-7 mktemp fix it verifies, and its comment describes the pre-fix recipe.", "reasoning": "The scenario still reads /tmp/dispatch-scan.txt and greps for grep error text, but the shipped §7 recipe now mktemps its scan file and traps-cleans it, so that buffer is always empty and the assertion can never fire. If a future edit reintroduced 2>&1 into the scan redirect — the exact regression CR-23 exists for — the scenario would stay green. Only the missing-versus-empty half still measures. Two stale comments ride along: CR-23's block still calls CR-7 'a separate, deferred finding' when CR-7 shipped in 0b297ff, and the CR-2(d) comment still describes the pre-fix filter. A fix that vacates its own regression test is the CR-31 shape at smaller scale.", "proposed_action": "fix-in-this-feature", "fix_cost": "small", "feature_value": "core", "adjacent_to_blocking": true }, { "id": "CR-43", "category": "in-scope-deferrable", "severity": "Low", "summary": "Eleven further sweep findings: parser and vocabulary gaps in the shipped recipes and helpers.", "reasoning": "Indexed together because each is a one-to-three-line fix and they share no root beyond 'the shipped text meets an input its author did not picture'. doc_grep_folded is not wrap-safe for INDENTED continuation lines, so the wrap-safe helper has its own wrap bug. §7 has a fourth silent unusable-record state: DISPATCH entries with no claims lines pass the grep, extract nothing, exit 0. §7's key-quoting regex cannot parse a kebab-case project-named class, the naming style this repo uses everywhere. Near-miss port spellings ('4080 - 4089', en-dash, leading zeros) compare as literal names and read disjoint. §8 uses the word 'lane' four sections before §11 declares neither vocabulary uses the other's word. develop §3.1's remedy paraphrase drops reassignment, silently discarding the remedy that keeps wave concurrency. Disclosure consumption is unsequenced: no consumer step tells the driver to read a report for a disclosure when filling the RELEASE entry. extract_bash_block_containing is not fence-aware for 4-backtick wrappers, the exact trap CLAUDE.md's fence-tracker rule names. ended_by_offenders has a latent false positive on inline-code prose mentions. AC-14's uniqueness scan is line-scoped while its presence check is not, so a WRAPPED restatement in a consumer escapes — the third appearance of the wrapped-anchor failure on this feature. make_real_tree_copy copies the entire repo, which from the main checkout means every sibling worktree, twice per run.", "proposed_action": "defer-to-issue", "fix_cost": "substantial", "feature_value": "incidental", "adjacent_to_blocking": false }, { "id": "CR-44", "category": "in-scope-deferrable", "severity": "Low", "summary": "`waited_ms` was populated once, as 0, despite three serializations — the field added to end an argument did not end it.", "reasoning": "§6 says waited_ms exists 'so the cost of serializing is measured from the record instead of argued about'. This round serialized three times and recorded the wait once, as zero. The cost is recoverable only by manually subtracting dispatch-minus-prior-release timestamps, which is precisely the state the field was added to end. An optional field the reference run does not fill is a field that will not be filled — the same shape as overran_resources (CR-36), one severity down because nothing depends on it.", "proposed_action": "fix-in-this-feature", "fix_cost": "trivial", "feature_value": "incidental", "adjacent_to_blocking": false }, { "id": "CR-45", "category": "out-of-scope", "severity": "Medium", "summary": "Three rounds of the same failure shape — a fix landing where the finding pointed rather than everywhere the rule lives — is evidence about the design, not three unrelated defects.", "reasoning": "CR-2 fixed []-means-could-not-judge for identity classes and workers reproduces it in the same rewrite (CR-33). CR-17 fixed a permissive paraphrase in qa-playbook and CR-12's fix created a new one in the same file 80 lines away (CR-37). CR-4's fix is guarded by a test that proves nothing (CR-31). CR-27 narrowed §8.4 without updating §7 (CR-32). CR-10 added a field §7 never consults and no entry populates (CR-34, CR-36). CR-21 widened §2 without touching §5 or §8 (CR-35). This is the drift AC-14's lint check exists to catch, but that check guards six anchor phrases and nothing else. fix-workflow.md §2's convergence rule is directly on point: a second re-validation finding of the same CLASS as the one just fixed ends the patching, and its two exits are a round explicitly framed at the class, or deferral with the residue recorded — not a third patch pass of the same shape. Raised as a finding rather than acted on, because choosing between those exits is the operator's call.", "proposed_action": "defer-to-issue", "fix_cost": "substantial", "feature_value": "core", "adjacent_to_blocking": false } ], "artifacts": { "report_path": ".devwork/feature-qa-intra-run-lane-ownership/code-report.md", "journal_path": ".devwork/feature-qa-intra-run-lane-ownership/code-journal.md", "dispatch_journal": ".devwork/feature-qa-intra-run-lane-ownership/dispatch-journal.md", "swept_head": "960d686" }, "notes": { "supersedes": "This supersedes the phase=validate report at comment 1405 by latest-wins. 1405 recorded round 1's findings against the PRE-fix tree; all 23 in-scope ones were fixed and verified (see phase=fix, comment 1689). These 15 are NEW, against the post-fix tree.", "adversarial_pass": "Carried by a fable Bug Hunter in fresh context against the post-fix tree, per qa-playbook §7 — never the fixer's context. It was told to assume a third false green existed; it found one (CR-31) and the driver reproduced it.", "exit_invariant": "qa-playbook §7: QA is done when a full sweep completes with nothing modified after it. This sweep found findings, so this is a new round, including its own sweep. The invariant is a check against the record, not a read of the trend — the finding count rose 25 -> 30 -> 45 across the round and that is not what decides it.", "tool_deviation": "The Bug Hunter's brief said Read/Grep/Glob only, no Bash. Its session had no Grep/Glob tools, so it used Bash strictly read-only and DISCLOSED the deviation rather than working around it silently. Driver confirmed via git status that the sweep modified nothing.", "convergence": "CR-45 records that three rounds of the same failure shape is itself evidence. fix-workflow.md §2's convergence rule applies and its two exits are a round framed at the class, or deferral with residue recorded — not a third patch pass of the same shape. That choice is the operator's." } } ```

jbr870 commented

2026-08-25 15:50:26 +00:00

Author

Owner

{
  "next_state": "qa",
  "produced": [
    {
      "kind": "qa-report",
      "ref": "1689",
      "summary": "code phase=fix — 23 findings fixed, 4 gates green"
    },
    {
      "kind": "qa-report",
      "ref": "latest",
      "summary": "code phase=validate — the sweep, 15 findings, 2 Critical"
    },
    {
      "kind": "code-bundle",
      "ref": "960d686",
      "summary": "the swept HEAD: fix commits 0b297ff + 960d686 on test_commit 41768fe"
    }
  ],
  "findings": [
    {
      "category": "in-scope-blocking",
      "severity": "critical",
      "summary": "[code CR-31] The CR-4 regression scenarios are vacuous: the recursion guard's `return 1` makes the inner suite exit non-zero unconditionally, so the outer `rc != 0` assertion is always true.",
      "reasoning": "Reproduced by the driver: `RRC_INNER_RUN=1 bash scripts/test-lint-conventions.sh` on a PRISTINE, unmutated tree exits rc=1 with exactly two FAIL lines — both the guard's own bookkeeping. The guard does `return 1`, and in the inner run the CR-4 scenarios are themselves `run_scenario`-wrapped, so that routes through fail() and increments fail_count by 2. Re-introduce the exact CR-4 defect and the inner control passes on the mutated tree while the two guard FAILs still force rc=1 — both scenarios report 'correctly went red' and the suite is green. This is the third false green of the round and it is inside the flagship regression test of the commit that fixed the second. IMPORTANT: CR-4's fix is real — the driver's manual before/after probe measured the shipped harness directly (masked at 21/21 rc=0, caught at rc=1 with the control FAILing) and stands. What is vacuous is the scenario meant to guard it going forward. Fix: the guard returns 0 (or the scenarios are not run_scenario-wrapped in the inner run), AND the outer assertion keys on the inner output containing `FAIL: control_clean_tree` rather than on bare rc — the same 'assert on the specific failure, not the exit code' rule this round put in every brief.",
      "id": "F-PO-43-5-1"
    },
    {
      "category": "in-scope-blocking",
      "severity": "critical",
      "summary": "[code CR-32] §7 step 4 contradicts §8.4: it voids a sole owner on its own disclosure, which is exactly what the CR-27 fix removed.",
      "reasoning": "§7 step 4 reads 'an overran_claim: true on any actor whose window intersects the one you are triaging — the triaged actor itself included — ... It is void'. §8.4 as amended reads 'An overrun by an actor that held sole ownership is recorded, not voided.' §7 was not updated when §8.4 was narrowed. Reproduced by hand against this round's own journal: qa-fix-F1-docs holds window [16:31:17, 17:03:13) with no intersecting actor, so step 3 finds no colliding pair — but F1 carries overran_claim: true and step 4's 'the triaged actor itself included' voids its entire fix-stage output on the strength of its own honest disclosure. The driver disposed all three of this round's overruns per §8.4, i.e. against the shipped checklist. Critical rather than Medium because §7 is written as an executable block to copy and run, precisely so a driver need not reason it out — and as shipped it re-creates the disclosure disincentive the CR-27 fix existed to remove. Found independently by the sweep's claims reviewer and by the driver's own read.",
      "id": "F-PO-43-5-2"
    },
    {
      "category": "in-scope-blocking",
      "severity": "high",
      "summary": "[code CR-33] §4's normative rule 'empty output means dispatch concurrently' is false for `workers`, the one class the filter structurally cannot judge — CR-2's defect reborn one class over.",
      "reasoning": "The rewritten filter subtracts `workers` from its class list, so it can never emit a workers entry: not for a one-sided claim, not for an absent-both claim, not for a budget overflow. Two breaking inputs. (a) Both claims omit `workers`: §3 says an absent key is unknown ⇒ serialize, the filter prints [], and the bold rule says dispatch — §3 and §4 give opposite answers for one input, and unlike every other class no verdict: 'unknown' is emitted. (b) A and B both claim workers: 8 on an 8-worker pool with a third actor holding 4: output [], driver dispatches, pool oversubscribed. The budget test exists only as a trailing comment inside the fence; the normative prose does not carve workers out. This is the exact defect CR-2 fixed for the identity classes — [] standing for 'could not judge' — surviving in the same rewrite that fixed it.",
      "id": "F-PO-43-5-3"
    },
    {
      "category": "in-scope-blocking",
      "severity": "high",
      "summary": "[code CR-34] §7 step 4 never consults `overran_resources`, the field CR-10 added for exactly this, so any overrun by a window-peer contaminates regardless of what it touched.",
      "reasoning": "journal-template.md states the purpose in terms: 'a bare boolean cannot be intersected with anything, and intersecting resources is the whole of §7's method'. Step 4 does not intersect. Breaking scenario: actor A overruns onto `external`; actor B's window intersects A's and B touched only `database`. Step 4 voids B, demanding a re-run that cannot change anything, because A's overrun could not have moved anything B observed. §7's own adjacent note makes precisely this argument one step earlier — it rejects a global reading because 'reading it as global would void half a feature's records from one honest disclosure, which is also how a contract teaches actors to stop disclosing' — then stops short of applying the same reasoning to resources, with the data to do so now in the record.",
      "id": "F-PO-43-5-4"
    },
    {
      "category": "in-scope-blocking",
      "severity": "high",
      "summary": "[code CR-35] §2's widened vocabulary never reached §5's duty language or §8's consequence table, both of which still enumerate the original four classes.",
      "reasoning": "The CR-21 fix widened §2 to name shared writable scratch/cache surfaces and 'any shared artefact one actor writes while another reads or executes it'. §5's duty sentence still reads 'a database, port, worker budget or external resource its claim did not name', and §8's machinery keys off the same four-class overran_claim/overran_resources shape. Consequence, observed: qa-tests-T1-contract wrote and read /tmp/dispatch-scan.txt and recorded overran_claim: false — correctly, under §5's literal text, because a shared scratch path is not one of the four. So the use never enters §8's table, is never voided, is never flagged unknown; it falls through to actor discretion, which is what the contract exists to stop relying on. §2 says such a surface 'cannot be named as an identity at all, it is an unknown, which §1 sends to serialization', but nothing in §3/§4 lets a driver DETECT an unnamed shared surface before dispatch — so the widened class is discoverable only after the fact via disclosure, a materially weaker guarantee than the pre-dispatch comparison the four named classes get. The text reads as closed while being open.",
      "id": "F-PO-43-5-5"
    },
    {
      "category": "in-scope-blocking",
      "severity": "high",
      "summary": "[code CR-36] `overran_resources` is required-but-absent on 3 of 3 real overrun entries — records the driver itself wrote, in the run that defined the field.",
      "reasoning": "journal-template.md requires overran_resources on any RELEASE whose overran_claim is true. Counted in this round's journal: 3 entries with overran_claim: true, 0 with overran_resources. The driver wrote all three through a helper that had no such parameter. The information exists only in each entry's prose Note, which §7's key-scan cannot read — so running §7 against this journal today correctly flags three overruns and has nothing to intersect for any of them, defeating the answer-from-the-record design in the reference run. Nothing mechanical checks the requirement, which is why it went unnoticed: CR-26's shape again, a rule with no enforcement path is a rule that will be missed. Remedied for the human record by an appended correction entry supplying the three values; a mechanical scan still reads the originals, which is CR-38.",
      "id": "F-PO-43-5-6"
    },
    {
      "category": "in-scope-deferrable",
      "severity": "medium",
      "summary": "[code CR-37] qa-playbook's RELEASE step drops §5's quiescence condition — the same permissive paraphrase drift the same file's CR-17 fix warns about 80 lines earlier.",
      "reasoning": "qa-playbook sequences 'once wait-discipline §1a has concluded that actor is done — its report arrived, or a death check settled it — append the matching RELEASE entry'. §5.1 (the CR-12 fix) says the report is the trigger, not the proof: confirm processes gone and ports free BEFORE writing RELEASE. A driver working qa-playbook's numbered loop writes RELEASE on report arrival and dispatches the next actor onto a straggling watch-mode runner — §5's own worked example. develop/SKILL.md defers correctly; qa-playbook embeds the incomplete half-rule. One clause fixes it, and the round created this instance while fixing another in the same file.",
      "proposed_action": "fix-in-this-feature",
      "fix_cost": "trivial",
      "feature_value": "core",
      "adjacent_to_blocking": true,
      "id": "F-PO-43-5-7"
    },
    {
      "category": "in-scope-deferrable",
      "severity": "medium",
      "summary": "[code CR-38] The contract has no pattern for superseding a fact already written, so every correction restores the human record and not the machine one.",
      "reasoning": "Journals are append-only, which is right. But nothing names how to supersede a written fact. This round needed it three times: the hand-estimated timestamps, the missing overran_resources, and the preamble's external: [] which qa-fix-F1-docs falsified. The first got a correction entry by improvisation; the other two went unnoticed until a reviewer asked. Because §7's scan reads YAML keys and every correction is prose in a DISCOVERY entry, a mechanical triage today still reads the original wrong timestamps and still finds no overran_resources. For a contract whose whole promise is 'answer it from the record', that is the half that matters. qa-report:v1 solved exactly this with latest-wins supersession; the journal has no equivalent.",
      "proposed_action": "fix-in-this-feature",
      "fix_cost": "small",
      "feature_value": "core",
      "adjacent_to_blocking": false,
      "id": "F-PO-43-5-8"
    },
    {
      "category": "in-scope-deferrable",
      "severity": "medium",
      "summary": "[code CR-39] §8.4's narrowed void assumes every resource user is a journaled claim-holder — the driver itself is invisible to the §7 scan.",
      "reasoning": "The carve-out is decided by the §7 scan over the journal, and only dispatched suite-running actors appear there. Two users never do: the driver, which writes no DISPATCH for its own suite runs (this round's driver ran gates inline repeatedly), and a no-claims actor whose work still collides via §2's writer-vs-executor shape. Breaking scenario: validator V claims database []; the driver reseeds the repo-default database while V runs; V discloses it also touched that database. §7 finds no other claim-holder's window, so sole ownership applies, the result is recorded not voided, and it gets cited. The pre-fix unconditional void caught this. The narrowing is well argued on disclosure incentives, but never states its load-bearing assumption: that while any claim is open the driver touches nothing in the claim vocabulary, or self-records if it does.",
      "proposed_action": "fix-in-this-feature",
      "fix_cost": "trivial",
      "feature_value": "core",
      "adjacent_to_blocking": true,
      "id": "F-PO-43-5-9"
    },
    {
      "category": "in-scope-deferrable",
      "severity": "medium",
      "summary": "[code CR-40] CR-1's scenario hard-depends on a gitignored machine-local journal, so a required Verification command reds on any fresh clone.",
      "reasoning": "The scenario asserts against .devwork/feature-qa-intra-run-lane-ownership/dispatch-journal.md, and .devwork/ is gitignored local staging. CLAUDE.md now names this suite as one of four required Verification commands. On a fresh clone, another machine, the main checkout after this branch integrates, or this machine once .devwork is drained post-close, the copy fails and CR-1 fails the whole suite. A required test command that reds on a clean clone is worse than none. Using the real journal was the right instinct — a synthetic fixture is the CR-15/#68 defect — but the real record is untracked; the fix is a committed fixture journal as a fallback when the real one is absent.",
      "proposed_action": "fix-in-this-feature",
      "fix_cost": "small",
      "feature_value": "core",
      "adjacent_to_blocking": false,
      "id": "F-PO-43-5-10"
    },
    {
      "category": "in-scope-deferrable",
      "severity": "medium",
      "summary": "[code CR-41] §4 validates only the top-level type, so malformed elements inside a claim array stringify and compare as literals, yielding a false disjoint.",
      "reasoning": "The 'not a flat identity set' branch checks only that the value is an array; element types are never checked, and §3's 'scalars and flat string lists only' is enforced nowhere. Breaking input: A={database:[{name:'app_test'}]} — a nested map, forbidden by §3 but rejected by nothing — against B={database:['app_test']}. tostring gives {\"name\":\"app_test\"} versus app_test, the intersection is empty, and both are dispatched onto app_test. A nested list does the same. The round's own 'refuse to guess' principle says these should return verdict: 'unknown'.",
      "proposed_action": "fix-in-this-feature",
      "fix_cost": "small",
      "feature_value": "core",
      "adjacent_to_blocking": true,
      "id": "F-PO-43-5-11"
    },
    {
      "category": "in-scope-deferrable",
      "severity": "medium",
      "summary": "[code CR-42] CR-23's stderr-leak assertion was half-vacuated by the CR-7 mktemp fix it verifies, and its comment describes the pre-fix recipe.",
      "reasoning": "The scenario still reads /tmp/dispatch-scan.txt and greps for grep error text, but the shipped §7 recipe now mktemps its scan file and traps-cleans it, so that buffer is always empty and the assertion can never fire. If a future edit reintroduced 2>&1 into the scan redirect — the exact regression CR-23 exists for — the scenario would stay green. Only the missing-versus-empty half still measures. Two stale comments ride along: CR-23's block still calls CR-7 'a separate, deferred finding' when CR-7 shipped in 0b297ff, and the CR-2(d) comment still describes the pre-fix filter. A fix that vacates its own regression test is the CR-31 shape at smaller scale.",
      "proposed_action": "fix-in-this-feature",
      "fix_cost": "small",
      "feature_value": "core",
      "adjacent_to_blocking": true,
      "id": "F-PO-43-5-12"
    },
    {
      "category": "in-scope-deferrable",
      "severity": "low",
      "summary": "[code CR-43] Eleven further sweep findings: parser and vocabulary gaps in the shipped recipes and helpers.",
      "reasoning": "Indexed together because each is a one-to-three-line fix and they share no root beyond 'the shipped text meets an input its author did not picture'. doc_grep_folded is not wrap-safe for INDENTED continuation lines, so the wrap-safe helper has its own wrap bug. §7 has a fourth silent unusable-record state: DISPATCH entries with no claims lines pass the grep, extract nothing, exit 0. §7's key-quoting regex cannot parse a kebab-case project-named class, the naming style this repo uses everywhere. Near-miss port spellings ('4080 - 4089', en-dash, leading zeros) compare as literal names and read disjoint. §8 uses the word 'lane' four sections before §11 declares neither vocabulary uses the other's word. develop §3.1's remedy paraphrase drops reassignment, silently discarding the remedy that keeps wave concurrency. Disclosure consumption is unsequenced: no consumer step tells the driver to read a report for a disclosure when filling the RELEASE entry. extract_bash_block_containing is not fence-aware for 4-backtick wrappers, the exact trap CLAUDE.md's fence-tracker rule names. ended_by_offenders has a latent false positive on inline-code prose mentions. AC-14's uniqueness scan is line-scoped while its presence check is not, so a WRAPPED restatement in a consumer escapes — the third appearance of the wrapped-anchor failure on this feature. make_real_tree_copy copies the entire repo, which from the main checkout means every sibling worktree, twice per run.",
      "proposed_action": "defer-to-issue",
      "fix_cost": "substantial",
      "feature_value": "incidental",
      "adjacent_to_blocking": false,
      "id": "F-PO-43-5-13"
    },
    {
      "category": "in-scope-deferrable",
      "severity": "low",
      "summary": "[code CR-44] `waited_ms` was populated once, as 0, despite three serializations — the field added to end an argument did not end it.",
      "reasoning": "§6 says waited_ms exists 'so the cost of serializing is measured from the record instead of argued about'. This round serialized three times and recorded the wait once, as zero. The cost is recoverable only by manually subtracting dispatch-minus-prior-release timestamps, which is precisely the state the field was added to end. An optional field the reference run does not fill is a field that will not be filled — the same shape as overran_resources (CR-36), one severity down because nothing depends on it.",
      "proposed_action": "fix-in-this-feature",
      "fix_cost": "trivial",
      "feature_value": "incidental",
      "adjacent_to_blocking": false,
      "id": "F-PO-43-5-14"
    },
    {
      "category": "out-of-scope",
      "severity": "medium",
      "summary": "[code CR-45] Three rounds of the same failure shape — a fix landing where the finding pointed rather than everywhere the rule lives — is evidence about the design, not three unrelated defects.",
      "reasoning": "CR-2 fixed []-means-could-not-judge for identity classes and workers reproduces it in the same rewrite (CR-33). CR-17 fixed a permissive paraphrase in qa-playbook and CR-12's fix created a new one in the same file 80 lines away (CR-37). CR-4's fix is guarded by a test that proves nothing (CR-31). CR-27 narrowed §8.4 without updating §7 (CR-32). CR-10 added a field §7 never consults and no entry populates (CR-34, CR-36). CR-21 widened §2 without touching §5 or §8 (CR-35). This is the drift AC-14's lint check exists to catch, but that check guards six anchor phrases and nothing else. fix-workflow.md §2's convergence rule is directly on point: a second re-validation finding of the same CLASS as the one just fixed ends the patching, and its two exits are a round explicitly framed at the class, or deferral with the residue recorded — not a third patch pass of the same shape. Raised as a finding rather than acted on, because choosing between those exits is the operator's call.",
      "proposed_action": "defer-to-issue",
      "fix_cost": "substantial",
      "feature_value": "core",
      "adjacent_to_blocking": false,
      "id": "F-PO-43-5-15"
    }
  ],
  "pending_decisions": [
    {
      "id": "D-PO-43-5-1",
      "type": "scope-disposition",
      "blocking": false,
      "question": "[CR-37] qa-playbook's RELEASE step drops §5's quiescence condition — the same permissive paraphrase drift the same file's CR-17 fix warns about 80 lines earlier. — fix now, spawn a follow-up issue, or accept?",
      "options": [
        "fix-now",
        "defer-to-issue",
        "accept"
      ],
      "recommended": "fix-now",
      "finding_ref": "F-PO-43-5-7",
      "reasoning": "Computed by disposition-recommend.sh from the finding's axes. Full evidence in the sweep qa-report:v1 (domain=code, phase=validate) and code-journal.md. NOTE: the operator has been asked to choose the round-2 strategy first (blockers-only versus full round versus reassess the design per CR-45); that choice may change which of these are in scope, so resolve it before these."
    },
    {
      "id": "D-PO-43-5-2",
      "type": "scope-disposition",
      "blocking": false,
      "question": "[CR-38] The contract has no pattern for superseding a fact already written, so every correction restores the human record and not the machine one. — fix now, spawn a follow-up issue, or accept?",
      "options": [
        "fix-now",
        "defer-to-issue",
        "accept"
      ],
      "recommended": "fix-now",
      "finding_ref": "F-PO-43-5-8",
      "reasoning": "Computed by disposition-recommend.sh from the finding's axes. Full evidence in the sweep qa-report:v1 (domain=code, phase=validate) and code-journal.md. NOTE: the operator has been asked to choose the round-2 strategy first (blockers-only versus full round versus reassess the design per CR-45); that choice may change which of these are in scope, so resolve it before these."
    },
    {
      "id": "D-PO-43-5-3",
      "type": "scope-disposition",
      "blocking": false,
      "question": "[CR-39] §8.4's narrowed void assumes every resource user is a journaled claim-holder — the driver itself is invisible to the §7 scan. — fix now, spawn a follow-up issue, or accept?",
      "options": [
        "fix-now",
        "defer-to-issue",
        "accept"
      ],
      "recommended": "fix-now",
      "finding_ref": "F-PO-43-5-9",
      "reasoning": "Computed by disposition-recommend.sh from the finding's axes. Full evidence in the sweep qa-report:v1 (domain=code, phase=validate) and code-journal.md. NOTE: the operator has been asked to choose the round-2 strategy first (blockers-only versus full round versus reassess the design per CR-45); that choice may change which of these are in scope, so resolve it before these."
    },
    {
      "id": "D-PO-43-5-4",
      "type": "scope-disposition",
      "blocking": false,
      "question": "[CR-40] CR-1's scenario hard-depends on a gitignored machine-local journal, so a required Verification command reds on any fresh clone. — fix now, spawn a follow-up issue, or accept?",
      "options": [
        "fix-now",
        "defer-to-issue",
        "accept"
      ],
      "recommended": "fix-now",
      "finding_ref": "F-PO-43-5-10",
      "reasoning": "Computed by disposition-recommend.sh from the finding's axes. Full evidence in the sweep qa-report:v1 (domain=code, phase=validate) and code-journal.md. NOTE: the operator has been asked to choose the round-2 strategy first (blockers-only versus full round versus reassess the design per CR-45); that choice may change which of these are in scope, so resolve it before these."
    },
    {
      "id": "D-PO-43-5-5",
      "type": "scope-disposition",
      "blocking": false,
      "question": "[CR-41] §4 validates only the top-level type, so malformed elements inside a claim array stringify and compare as literals, yielding a false disjoint. — fix now, spawn a follow-up issue, or accept?",
      "options": [
        "fix-now",
        "defer-to-issue",
        "accept"
      ],
      "recommended": "fix-now",
      "finding_ref": "F-PO-43-5-11",
      "reasoning": "Computed by disposition-recommend.sh from the finding's axes. Full evidence in the sweep qa-report:v1 (domain=code, phase=validate) and code-journal.md. NOTE: the operator has been asked to choose the round-2 strategy first (blockers-only versus full round versus reassess the design per CR-45); that choice may change which of these are in scope, so resolve it before these."
    },
    {
      "id": "D-PO-43-5-6",
      "type": "scope-disposition",
      "blocking": false,
      "question": "[CR-42] CR-23's stderr-leak assertion was half-vacuated by the CR-7 mktemp fix it verifies, and its comment describes the pre-fix recipe. — fix now, spawn a follow-up issue, or accept?",
      "options": [
        "fix-now",
        "defer-to-issue",
        "accept"
      ],
      "recommended": "fix-now",
      "finding_ref": "F-PO-43-5-12",
      "reasoning": "Computed by disposition-recommend.sh from the finding's axes. Full evidence in the sweep qa-report:v1 (domain=code, phase=validate) and code-journal.md. NOTE: the operator has been asked to choose the round-2 strategy first (blockers-only versus full round versus reassess the design per CR-45); that choice may change which of these are in scope, so resolve it before these."
    },
    {
      "id": "D-PO-43-5-7",
      "type": "scope-disposition",
      "blocking": false,
      "question": "[CR-43] Eleven further sweep findings: parser and vocabulary gaps in the shipped recipes and helpers. — fix now, spawn a follow-up issue, or accept?",
      "options": [
        "fix-now",
        "defer-to-issue",
        "accept"
      ],
      "recommended": "defer-to-issue",
      "finding_ref": "F-PO-43-5-13",
      "reasoning": "Computed by disposition-recommend.sh from the finding's axes. Full evidence in the sweep qa-report:v1 (domain=code, phase=validate) and code-journal.md. NOTE: the operator has been asked to choose the round-2 strategy first (blockers-only versus full round versus reassess the design per CR-45); that choice may change which of these are in scope, so resolve it before these."
    },
    {
      "id": "D-PO-43-5-8",
      "type": "scope-disposition",
      "blocking": false,
      "question": "[CR-44] `waited_ms` was populated once, as 0, despite three serializations — the field added to end an argument did not end it. — fix now, spawn a follow-up issue, or accept?",
      "options": [
        "fix-now",
        "defer-to-issue",
        "accept"
      ],
      "recommended": "fix-now",
      "finding_ref": "F-PO-43-5-14",
      "reasoning": "Computed by disposition-recommend.sh from the finding's axes. Full evidence in the sweep qa-report:v1 (domain=code, phase=validate) and code-journal.md. NOTE: the operator has been asked to choose the round-2 strategy first (blockers-only versus full round versus reassess the design per CR-45); that choice may change which of these are in scope, so resolve it before these."
    },
    {
      "id": "D-PO-43-5-9",
      "type": "scope-disposition",
      "blocking": false,
      "question": "[CR-45] Three rounds of the same failure shape — a fix landing where the finding pointed rather than everywhere the rule lives — is evidence about the design, not three unrelated defects. — fix now, spawn a follow-up issue, or accept?",
      "options": [
        "fix-now",
        "defer-to-issue",
        "accept"
      ],
      "recommended": "defer-to-issue",
      "finding_ref": "F-PO-43-5-15",
      "reasoning": "Computed by disposition-recommend.sh from the finding's axes. Full evidence in the sweep qa-report:v1 (domain=code, phase=validate) and code-journal.md. NOTE: the operator has been asked to choose the round-2 strategy first (blockers-only versus full round versus reassess the design per CR-45); that choice may change which of these are in scope, so resolve it before these."
    }
  ],
  "suite": {
    "source": "git",
    "sha": "960d6869d428e4ebf02fca171fa9acd01cb7a2fc",
    "dirty": false
  }
}

```json { "next_state": "qa", "produced": [ { "kind": "qa-report", "ref": "1689", "summary": "code phase=fix — 23 findings fixed, 4 gates green" }, { "kind": "qa-report", "ref": "latest", "summary": "code phase=validate — the sweep, 15 findings, 2 Critical" }, { "kind": "code-bundle", "ref": "960d686", "summary": "the swept HEAD: fix commits 0b297ff + 960d686 on test_commit 41768fe" } ], "findings": [ { "category": "in-scope-blocking", "severity": "critical", "summary": "[code CR-31] The CR-4 regression scenarios are vacuous: the recursion guard's `return 1` makes the inner suite exit non-zero unconditionally, so the outer `rc != 0` assertion is always true.", "reasoning": "Reproduced by the driver: `RRC_INNER_RUN=1 bash scripts/test-lint-conventions.sh` on a PRISTINE, unmutated tree exits rc=1 with exactly two FAIL lines — both the guard's own bookkeeping. The guard does `return 1`, and in the inner run the CR-4 scenarios are themselves `run_scenario`-wrapped, so that routes through fail() and increments fail_count by 2. Re-introduce the exact CR-4 defect and the inner control passes on the mutated tree while the two guard FAILs still force rc=1 — both scenarios report 'correctly went red' and the suite is green. This is the third false green of the round and it is inside the flagship regression test of the commit that fixed the second. IMPORTANT: CR-4's fix is real — the driver's manual before/after probe measured the shipped harness directly (masked at 21/21 rc=0, caught at rc=1 with the control FAILing) and stands. What is vacuous is the scenario meant to guard it going forward. Fix: the guard returns 0 (or the scenarios are not run_scenario-wrapped in the inner run), AND the outer assertion keys on the inner output containing `FAIL: control_clean_tree` rather than on bare rc — the same 'assert on the specific failure, not the exit code' rule this round put in every brief.", "id": "F-PO-43-5-1" }, { "category": "in-scope-blocking", "severity": "critical", "summary": "[code CR-32] §7 step 4 contradicts §8.4: it voids a sole owner on its own disclosure, which is exactly what the CR-27 fix removed.", "reasoning": "§7 step 4 reads 'an overran_claim: true on any actor whose window intersects the one you are triaging — the triaged actor itself included — ... It is void'. §8.4 as amended reads 'An overrun by an actor that held sole ownership is recorded, not voided.' §7 was not updated when §8.4 was narrowed. Reproduced by hand against this round's own journal: qa-fix-F1-docs holds window [16:31:17, 17:03:13) with no intersecting actor, so step 3 finds no colliding pair — but F1 carries overran_claim: true and step 4's 'the triaged actor itself included' voids its entire fix-stage output on the strength of its own honest disclosure. The driver disposed all three of this round's overruns per §8.4, i.e. against the shipped checklist. Critical rather than Medium because §7 is written as an executable block to copy and run, precisely so a driver need not reason it out — and as shipped it re-creates the disclosure disincentive the CR-27 fix existed to remove. Found independently by the sweep's claims reviewer and by the driver's own read.", "id": "F-PO-43-5-2" }, { "category": "in-scope-blocking", "severity": "high", "summary": "[code CR-33] §4's normative rule 'empty output means dispatch concurrently' is false for `workers`, the one class the filter structurally cannot judge — CR-2's defect reborn one class over.", "reasoning": "The rewritten filter subtracts `workers` from its class list, so it can never emit a workers entry: not for a one-sided claim, not for an absent-both claim, not for a budget overflow. Two breaking inputs. (a) Both claims omit `workers`: §3 says an absent key is unknown ⇒ serialize, the filter prints [], and the bold rule says dispatch — §3 and §4 give opposite answers for one input, and unlike every other class no verdict: 'unknown' is emitted. (b) A and B both claim workers: 8 on an 8-worker pool with a third actor holding 4: output [], driver dispatches, pool oversubscribed. The budget test exists only as a trailing comment inside the fence; the normative prose does not carve workers out. This is the exact defect CR-2 fixed for the identity classes — [] standing for 'could not judge' — surviving in the same rewrite that fixed it.", "id": "F-PO-43-5-3" }, { "category": "in-scope-blocking", "severity": "high", "summary": "[code CR-34] §7 step 4 never consults `overran_resources`, the field CR-10 added for exactly this, so any overrun by a window-peer contaminates regardless of what it touched.", "reasoning": "journal-template.md states the purpose in terms: 'a bare boolean cannot be intersected with anything, and intersecting resources is the whole of §7's method'. Step 4 does not intersect. Breaking scenario: actor A overruns onto `external`; actor B's window intersects A's and B touched only `database`. Step 4 voids B, demanding a re-run that cannot change anything, because A's overrun could not have moved anything B observed. §7's own adjacent note makes precisely this argument one step earlier — it rejects a global reading because 'reading it as global would void half a feature's records from one honest disclosure, which is also how a contract teaches actors to stop disclosing' — then stops short of applying the same reasoning to resources, with the data to do so now in the record.", "id": "F-PO-43-5-4" }, { "category": "in-scope-blocking", "severity": "high", "summary": "[code CR-35] §2's widened vocabulary never reached §5's duty language or §8's consequence table, both of which still enumerate the original four classes.", "reasoning": "The CR-21 fix widened §2 to name shared writable scratch/cache surfaces and 'any shared artefact one actor writes while another reads or executes it'. §5's duty sentence still reads 'a database, port, worker budget or external resource its claim did not name', and §8's machinery keys off the same four-class overran_claim/overran_resources shape. Consequence, observed: qa-tests-T1-contract wrote and read /tmp/dispatch-scan.txt and recorded overran_claim: false — correctly, under §5's literal text, because a shared scratch path is not one of the four. So the use never enters §8's table, is never voided, is never flagged unknown; it falls through to actor discretion, which is what the contract exists to stop relying on. §2 says such a surface 'cannot be named as an identity at all, it is an unknown, which §1 sends to serialization', but nothing in §3/§4 lets a driver DETECT an unnamed shared surface before dispatch — so the widened class is discoverable only after the fact via disclosure, a materially weaker guarantee than the pre-dispatch comparison the four named classes get. The text reads as closed while being open.", "id": "F-PO-43-5-5" }, { "category": "in-scope-blocking", "severity": "high", "summary": "[code CR-36] `overran_resources` is required-but-absent on 3 of 3 real overrun entries — records the driver itself wrote, in the run that defined the field.", "reasoning": "journal-template.md requires overran_resources on any RELEASE whose overran_claim is true. Counted in this round's journal: 3 entries with overran_claim: true, 0 with overran_resources. The driver wrote all three through a helper that had no such parameter. The information exists only in each entry's prose Note, which §7's key-scan cannot read — so running §7 against this journal today correctly flags three overruns and has nothing to intersect for any of them, defeating the answer-from-the-record design in the reference run. Nothing mechanical checks the requirement, which is why it went unnoticed: CR-26's shape again, a rule with no enforcement path is a rule that will be missed. Remedied for the human record by an appended correction entry supplying the three values; a mechanical scan still reads the originals, which is CR-38.", "id": "F-PO-43-5-6" }, { "category": "in-scope-deferrable", "severity": "medium", "summary": "[code CR-37] qa-playbook's RELEASE step drops §5's quiescence condition — the same permissive paraphrase drift the same file's CR-17 fix warns about 80 lines earlier.", "reasoning": "qa-playbook sequences 'once wait-discipline §1a has concluded that actor is done — its report arrived, or a death check settled it — append the matching RELEASE entry'. §5.1 (the CR-12 fix) says the report is the trigger, not the proof: confirm processes gone and ports free BEFORE writing RELEASE. A driver working qa-playbook's numbered loop writes RELEASE on report arrival and dispatches the next actor onto a straggling watch-mode runner — §5's own worked example. develop/SKILL.md defers correctly; qa-playbook embeds the incomplete half-rule. One clause fixes it, and the round created this instance while fixing another in the same file.", "proposed_action": "fix-in-this-feature", "fix_cost": "trivial", "feature_value": "core", "adjacent_to_blocking": true, "id": "F-PO-43-5-7" }, { "category": "in-scope-deferrable", "severity": "medium", "summary": "[code CR-38] The contract has no pattern for superseding a fact already written, so every correction restores the human record and not the machine one.", "reasoning": "Journals are append-only, which is right. But nothing names how to supersede a written fact. This round needed it three times: the hand-estimated timestamps, the missing overran_resources, and the preamble's external: [] which qa-fix-F1-docs falsified. The first got a correction entry by improvisation; the other two went unnoticed until a reviewer asked. Because §7's scan reads YAML keys and every correction is prose in a DISCOVERY entry, a mechanical triage today still reads the original wrong timestamps and still finds no overran_resources. For a contract whose whole promise is 'answer it from the record', that is the half that matters. qa-report:v1 solved exactly this with latest-wins supersession; the journal has no equivalent.", "proposed_action": "fix-in-this-feature", "fix_cost": "small", "feature_value": "core", "adjacent_to_blocking": false, "id": "F-PO-43-5-8" }, { "category": "in-scope-deferrable", "severity": "medium", "summary": "[code CR-39] §8.4's narrowed void assumes every resource user is a journaled claim-holder — the driver itself is invisible to the §7 scan.", "reasoning": "The carve-out is decided by the §7 scan over the journal, and only dispatched suite-running actors appear there. Two users never do: the driver, which writes no DISPATCH for its own suite runs (this round's driver ran gates inline repeatedly), and a no-claims actor whose work still collides via §2's writer-vs-executor shape. Breaking scenario: validator V claims database []; the driver reseeds the repo-default database while V runs; V discloses it also touched that database. §7 finds no other claim-holder's window, so sole ownership applies, the result is recorded not voided, and it gets cited. The pre-fix unconditional void caught this. The narrowing is well argued on disclosure incentives, but never states its load-bearing assumption: that while any claim is open the driver touches nothing in the claim vocabulary, or self-records if it does.", "proposed_action": "fix-in-this-feature", "fix_cost": "trivial", "feature_value": "core", "adjacent_to_blocking": true, "id": "F-PO-43-5-9" }, { "category": "in-scope-deferrable", "severity": "medium", "summary": "[code CR-40] CR-1's scenario hard-depends on a gitignored machine-local journal, so a required Verification command reds on any fresh clone.", "reasoning": "The scenario asserts against .devwork/feature-qa-intra-run-lane-ownership/dispatch-journal.md, and .devwork/ is gitignored local staging. CLAUDE.md now names this suite as one of four required Verification commands. On a fresh clone, another machine, the main checkout after this branch integrates, or this machine once .devwork is drained post-close, the copy fails and CR-1 fails the whole suite. A required test command that reds on a clean clone is worse than none. Using the real journal was the right instinct — a synthetic fixture is the CR-15/#68 defect — but the real record is untracked; the fix is a committed fixture journal as a fallback when the real one is absent.", "proposed_action": "fix-in-this-feature", "fix_cost": "small", "feature_value": "core", "adjacent_to_blocking": false, "id": "F-PO-43-5-10" }, { "category": "in-scope-deferrable", "severity": "medium", "summary": "[code CR-41] §4 validates only the top-level type, so malformed elements inside a claim array stringify and compare as literals, yielding a false disjoint.", "reasoning": "The 'not a flat identity set' branch checks only that the value is an array; element types are never checked, and §3's 'scalars and flat string lists only' is enforced nowhere. Breaking input: A={database:[{name:'app_test'}]} — a nested map, forbidden by §3 but rejected by nothing — against B={database:['app_test']}. tostring gives {\"name\":\"app_test\"} versus app_test, the intersection is empty, and both are dispatched onto app_test. A nested list does the same. The round's own 'refuse to guess' principle says these should return verdict: 'unknown'.", "proposed_action": "fix-in-this-feature", "fix_cost": "small", "feature_value": "core", "adjacent_to_blocking": true, "id": "F-PO-43-5-11" }, { "category": "in-scope-deferrable", "severity": "medium", "summary": "[code CR-42] CR-23's stderr-leak assertion was half-vacuated by the CR-7 mktemp fix it verifies, and its comment describes the pre-fix recipe.", "reasoning": "The scenario still reads /tmp/dispatch-scan.txt and greps for grep error text, but the shipped §7 recipe now mktemps its scan file and traps-cleans it, so that buffer is always empty and the assertion can never fire. If a future edit reintroduced 2>&1 into the scan redirect — the exact regression CR-23 exists for — the scenario would stay green. Only the missing-versus-empty half still measures. Two stale comments ride along: CR-23's block still calls CR-7 'a separate, deferred finding' when CR-7 shipped in 0b297ff, and the CR-2(d) comment still describes the pre-fix filter. A fix that vacates its own regression test is the CR-31 shape at smaller scale.", "proposed_action": "fix-in-this-feature", "fix_cost": "small", "feature_value": "core", "adjacent_to_blocking": true, "id": "F-PO-43-5-12" }, { "category": "in-scope-deferrable", "severity": "low", "summary": "[code CR-43] Eleven further sweep findings: parser and vocabulary gaps in the shipped recipes and helpers.", "reasoning": "Indexed together because each is a one-to-three-line fix and they share no root beyond 'the shipped text meets an input its author did not picture'. doc_grep_folded is not wrap-safe for INDENTED continuation lines, so the wrap-safe helper has its own wrap bug. §7 has a fourth silent unusable-record state: DISPATCH entries with no claims lines pass the grep, extract nothing, exit 0. §7's key-quoting regex cannot parse a kebab-case project-named class, the naming style this repo uses everywhere. Near-miss port spellings ('4080 - 4089', en-dash, leading zeros) compare as literal names and read disjoint. §8 uses the word 'lane' four sections before §11 declares neither vocabulary uses the other's word. develop §3.1's remedy paraphrase drops reassignment, silently discarding the remedy that keeps wave concurrency. Disclosure consumption is unsequenced: no consumer step tells the driver to read a report for a disclosure when filling the RELEASE entry. extract_bash_block_containing is not fence-aware for 4-backtick wrappers, the exact trap CLAUDE.md's fence-tracker rule names. ended_by_offenders has a latent false positive on inline-code prose mentions. AC-14's uniqueness scan is line-scoped while its presence check is not, so a WRAPPED restatement in a consumer escapes — the third appearance of the wrapped-anchor failure on this feature. make_real_tree_copy copies the entire repo, which from the main checkout means every sibling worktree, twice per run.", "proposed_action": "defer-to-issue", "fix_cost": "substantial", "feature_value": "incidental", "adjacent_to_blocking": false, "id": "F-PO-43-5-13" }, { "category": "in-scope-deferrable", "severity": "low", "summary": "[code CR-44] `waited_ms` was populated once, as 0, despite three serializations — the field added to end an argument did not end it.", "reasoning": "§6 says waited_ms exists 'so the cost of serializing is measured from the record instead of argued about'. This round serialized three times and recorded the wait once, as zero. The cost is recoverable only by manually subtracting dispatch-minus-prior-release timestamps, which is precisely the state the field was added to end. An optional field the reference run does not fill is a field that will not be filled — the same shape as overran_resources (CR-36), one severity down because nothing depends on it.", "proposed_action": "fix-in-this-feature", "fix_cost": "trivial", "feature_value": "incidental", "adjacent_to_blocking": false, "id": "F-PO-43-5-14" }, { "category": "out-of-scope", "severity": "medium", "summary": "[code CR-45] Three rounds of the same failure shape — a fix landing where the finding pointed rather than everywhere the rule lives — is evidence about the design, not three unrelated defects.", "reasoning": "CR-2 fixed []-means-could-not-judge for identity classes and workers reproduces it in the same rewrite (CR-33). CR-17 fixed a permissive paraphrase in qa-playbook and CR-12's fix created a new one in the same file 80 lines away (CR-37). CR-4's fix is guarded by a test that proves nothing (CR-31). CR-27 narrowed §8.4 without updating §7 (CR-32). CR-10 added a field §7 never consults and no entry populates (CR-34, CR-36). CR-21 widened §2 without touching §5 or §8 (CR-35). This is the drift AC-14's lint check exists to catch, but that check guards six anchor phrases and nothing else. fix-workflow.md §2's convergence rule is directly on point: a second re-validation finding of the same CLASS as the one just fixed ends the patching, and its two exits are a round explicitly framed at the class, or deferral with the residue recorded — not a third patch pass of the same shape. Raised as a finding rather than acted on, because choosing between those exits is the operator's call.", "proposed_action": "defer-to-issue", "fix_cost": "substantial", "feature_value": "core", "adjacent_to_blocking": false, "id": "F-PO-43-5-15" } ], "pending_decisions": [ { "id": "D-PO-43-5-1", "type": "scope-disposition", "blocking": false, "question": "[CR-37] qa-playbook's RELEASE step drops §5's quiescence condition — the same permissive paraphrase drift the same file's CR-17 fix warns about 80 lines earlier. — fix now, spawn a follow-up issue, or accept?", "options": [ "fix-now", "defer-to-issue", "accept" ], "recommended": "fix-now", "finding_ref": "F-PO-43-5-7", "reasoning": "Computed by disposition-recommend.sh from the finding's axes. Full evidence in the sweep qa-report:v1 (domain=code, phase=validate) and code-journal.md. NOTE: the operator has been asked to choose the round-2 strategy first (blockers-only versus full round versus reassess the design per CR-45); that choice may change which of these are in scope, so resolve it before these." }, { "id": "D-PO-43-5-2", "type": "scope-disposition", "blocking": false, "question": "[CR-38] The contract has no pattern for superseding a fact already written, so every correction restores the human record and not the machine one. — fix now, spawn a follow-up issue, or accept?", "options": [ "fix-now", "defer-to-issue", "accept" ], "recommended": "fix-now", "finding_ref": "F-PO-43-5-8", "reasoning": "Computed by disposition-recommend.sh from the finding's axes. Full evidence in the sweep qa-report:v1 (domain=code, phase=validate) and code-journal.md. NOTE: the operator has been asked to choose the round-2 strategy first (blockers-only versus full round versus reassess the design per CR-45); that choice may change which of these are in scope, so resolve it before these." }, { "id": "D-PO-43-5-3", "type": "scope-disposition", "blocking": false, "question": "[CR-39] §8.4's narrowed void assumes every resource user is a journaled claim-holder — the driver itself is invisible to the §7 scan. — fix now, spawn a follow-up issue, or accept?", "options": [ "fix-now", "defer-to-issue", "accept" ], "recommended": "fix-now", "finding_ref": "F-PO-43-5-9", "reasoning": "Computed by disposition-recommend.sh from the finding's axes. Full evidence in the sweep qa-report:v1 (domain=code, phase=validate) and code-journal.md. NOTE: the operator has been asked to choose the round-2 strategy first (blockers-only versus full round versus reassess the design per CR-45); that choice may change which of these are in scope, so resolve it before these." }, { "id": "D-PO-43-5-4", "type": "scope-disposition", "blocking": false, "question": "[CR-40] CR-1's scenario hard-depends on a gitignored machine-local journal, so a required Verification command reds on any fresh clone. — fix now, spawn a follow-up issue, or accept?", "options": [ "fix-now", "defer-to-issue", "accept" ], "recommended": "fix-now", "finding_ref": "F-PO-43-5-10", "reasoning": "Computed by disposition-recommend.sh from the finding's axes. Full evidence in the sweep qa-report:v1 (domain=code, phase=validate) and code-journal.md. NOTE: the operator has been asked to choose the round-2 strategy first (blockers-only versus full round versus reassess the design per CR-45); that choice may change which of these are in scope, so resolve it before these." }, { "id": "D-PO-43-5-5", "type": "scope-disposition", "blocking": false, "question": "[CR-41] §4 validates only the top-level type, so malformed elements inside a claim array stringify and compare as literals, yielding a false disjoint. — fix now, spawn a follow-up issue, or accept?", "options": [ "fix-now", "defer-to-issue", "accept" ], "recommended": "fix-now", "finding_ref": "F-PO-43-5-11", "reasoning": "Computed by disposition-recommend.sh from the finding's axes. Full evidence in the sweep qa-report:v1 (domain=code, phase=validate) and code-journal.md. NOTE: the operator has been asked to choose the round-2 strategy first (blockers-only versus full round versus reassess the design per CR-45); that choice may change which of these are in scope, so resolve it before these." }, { "id": "D-PO-43-5-6", "type": "scope-disposition", "blocking": false, "question": "[CR-42] CR-23's stderr-leak assertion was half-vacuated by the CR-7 mktemp fix it verifies, and its comment describes the pre-fix recipe. — fix now, spawn a follow-up issue, or accept?", "options": [ "fix-now", "defer-to-issue", "accept" ], "recommended": "fix-now", "finding_ref": "F-PO-43-5-12", "reasoning": "Computed by disposition-recommend.sh from the finding's axes. Full evidence in the sweep qa-report:v1 (domain=code, phase=validate) and code-journal.md. NOTE: the operator has been asked to choose the round-2 strategy first (blockers-only versus full round versus reassess the design per CR-45); that choice may change which of these are in scope, so resolve it before these." }, { "id": "D-PO-43-5-7", "type": "scope-disposition", "blocking": false, "question": "[CR-43] Eleven further sweep findings: parser and vocabulary gaps in the shipped recipes and helpers. — fix now, spawn a follow-up issue, or accept?", "options": [ "fix-now", "defer-to-issue", "accept" ], "recommended": "defer-to-issue", "finding_ref": "F-PO-43-5-13", "reasoning": "Computed by disposition-recommend.sh from the finding's axes. Full evidence in the sweep qa-report:v1 (domain=code, phase=validate) and code-journal.md. NOTE: the operator has been asked to choose the round-2 strategy first (blockers-only versus full round versus reassess the design per CR-45); that choice may change which of these are in scope, so resolve it before these." }, { "id": "D-PO-43-5-8", "type": "scope-disposition", "blocking": false, "question": "[CR-44] `waited_ms` was populated once, as 0, despite three serializations — the field added to end an argument did not end it. — fix now, spawn a follow-up issue, or accept?", "options": [ "fix-now", "defer-to-issue", "accept" ], "recommended": "fix-now", "finding_ref": "F-PO-43-5-14", "reasoning": "Computed by disposition-recommend.sh from the finding's axes. Full evidence in the sweep qa-report:v1 (domain=code, phase=validate) and code-journal.md. NOTE: the operator has been asked to choose the round-2 strategy first (blockers-only versus full round versus reassess the design per CR-45); that choice may change which of these are in scope, so resolve it before these." }, { "id": "D-PO-43-5-9", "type": "scope-disposition", "blocking": false, "question": "[CR-45] Three rounds of the same failure shape — a fix landing where the finding pointed rather than everywhere the rule lives — is evidence about the design, not three unrelated defects. — fix now, spawn a follow-up issue, or accept?", "options": [ "fix-now", "defer-to-issue", "accept" ], "recommended": "defer-to-issue", "finding_ref": "F-PO-43-5-15", "reasoning": "Computed by disposition-recommend.sh from the finding's axes. Full evidence in the sweep qa-report:v1 (domain=code, phase=validate) and code-journal.md. NOTE: the operator has been asked to choose the round-2 strategy first (blockers-only versus full round versus reassess the design per CR-45); that choice may change which of these are in scope, so resolve it before these." } ], "suite": { "source": "git", "sha": "960d6869d428e4ebf02fca171fa9acd01cb7a2fc", "dirty": false } } ```

jbr870 commented

2026-08-25 19:09:14 +00:00

Author

Owner

{
  "status": "resolved",
  "chosen_option": "fix-now",
  "rationale": "[CR-37] One clause, in a file the round is already reopening for the blocking §7 work, and it closes a paraphrase that drifts toward the permissive answer — a driver following qa-playbook's numbered loop writes RELEASE on report arrival and dispatches the next actor onto a straggling watch-mode runner. The recursion is the argument for doing it now rather than later: this same file's CR-17 fix warns against exactly this drift eighty lines earlier, so shipping the instance alongside the warning is indefensible on the next reading. Resolved under the operator's explicit choice of round-2 strategy this session — presented three options (blockers-only, full round, reassess the design) and instructed to proceed with the first — so this follows the recommender rather than overriding it. The recommendation itself is disposition-recommend.sh's, computed from the finding's fix_cost, feature_value, adjacent_to_blocking and category.",
  "rejected_alternative": "defer-to-issue was weighed because it is strictly a consumer-text defect rather than a contract one. Turned down because the fix is one clause in a file already open, and because the finding's whole point is that a half-stated rule reads as complete."
}

```json { "status": "resolved", "chosen_option": "fix-now", "rationale": "[CR-37] One clause, in a file the round is already reopening for the blocking §7 work, and it closes a paraphrase that drifts toward the permissive answer — a driver following qa-playbook's numbered loop writes RELEASE on report arrival and dispatches the next actor onto a straggling watch-mode runner. The recursion is the argument for doing it now rather than later: this same file's CR-17 fix warns against exactly this drift eighty lines earlier, so shipping the instance alongside the warning is indefensible on the next reading. Resolved under the operator's explicit choice of round-2 strategy this session — presented three options (blockers-only, full round, reassess the design) and instructed to proceed with the first — so this follows the recommender rather than overriding it. The recommendation itself is disposition-recommend.sh's, computed from the finding's fix_cost, feature_value, adjacent_to_blocking and category.", "rejected_alternative": "defer-to-issue was weighed because it is strictly a consumer-text defect rather than a contract one. Turned down because the fix is one clause in a file already open, and because the finding's whole point is that a half-stated rule reads as complete." } ```

jbr870 commented

Author

Owner

{
  "status": "resolved",
  "chosen_option": "fix-now",
  "rationale": "[CR-38] Every correction this round produced restores the human record and leaves the machine record wrong, which for a contract whose entire promise is \"answer it from the record\" is the half that matters. The round needed the pattern three times and improvised it once. qa-report:v1 already solves precisely this with latest-wins supersession, so the fix is to name an existing, proven mechanism for the journal rather than to invent one. Resolved under the operator's explicit choice of round-2 strategy this session — presented three options (blockers-only, full round, reassess the design) and instructed to proceed with the first — so this follows the recommender rather than overriding it. The recommendation itself is disposition-recommend.sh's, computed from the finding's fix_cost, feature_value, adjacent_to_blocking and category.",
  "rejected_alternative": "defer-to-issue was serious here, since a supersession mechanism for an append-only record is a design decision with reach beyond this feature. Turned down because two of the three instances are defects this round itself introduced into the reference record, and leaving them uncorrectable-by-machine while shipping the contract that depends on the record is worse than the design risk."
}

```json { "status": "resolved", "chosen_option": "fix-now", "rationale": "[CR-38] Every correction this round produced restores the human record and leaves the machine record wrong, which for a contract whose entire promise is \"answer it from the record\" is the half that matters. The round needed the pattern three times and improvised it once. qa-report:v1 already solves precisely this with latest-wins supersession, so the fix is to name an existing, proven mechanism for the journal rather than to invent one. Resolved under the operator's explicit choice of round-2 strategy this session — presented three options (blockers-only, full round, reassess the design) and instructed to proceed with the first — so this follows the recommender rather than overriding it. The recommendation itself is disposition-recommend.sh's, computed from the finding's fix_cost, feature_value, adjacent_to_blocking and category.", "rejected_alternative": "defer-to-issue was serious here, since a supersession mechanism for an append-only record is a design decision with reach beyond this feature. Turned down because two of the three instances are defects this round itself introduced into the reference record, and leaving them uncorrectable-by-machine while shipping the contract that depends on the record is worse than the design risk." } ```

jbr870 commented

Author

Owner

{
  "status": "resolved",
  "chosen_option": "fix-now",
  "rationale": "[CR-39] One sentence, and it names the assumption the narrowed §8.4 silently rests on: that while any claim is open the driver touches nothing in the claim vocabulary, or self-records if it does. The driver of this very round ran gates inline repeatedly and wrote no DISPATCH for itself, so the unstated assumption was violated by the reference implementation on its first outing. Resolved under the operator's explicit choice of round-2 strategy this session — presented three options (blockers-only, full round, reassess the design) and instructed to proceed with the first — so this follows the recommender rather than overriding it. The recommendation itself is disposition-recommend.sh's, computed from the finding's fix_cost, feature_value, adjacent_to_blocking and category.",
  "rejected_alternative": "accept was arguable on the view that a driver reseeding a database mid-round is a discipline problem rather than a contract gap. Turned down because the narrowing is new this round and a narrowed safety rule owes an explicit statement of what it now assumes — otherwise the next reader inherits the gap without the reasoning."
}

```json { "status": "resolved", "chosen_option": "fix-now", "rationale": "[CR-39] One sentence, and it names the assumption the narrowed §8.4 silently rests on: that while any claim is open the driver touches nothing in the claim vocabulary, or self-records if it does. The driver of this very round ran gates inline repeatedly and wrote no DISPATCH for itself, so the unstated assumption was violated by the reference implementation on its first outing. Resolved under the operator's explicit choice of round-2 strategy this session — presented three options (blockers-only, full round, reassess the design) and instructed to proceed with the first — so this follows the recommender rather than overriding it. The recommendation itself is disposition-recommend.sh's, computed from the finding's fix_cost, feature_value, adjacent_to_blocking and category.", "rejected_alternative": "accept was arguable on the view that a driver reseeding a database mid-round is a discipline problem rather than a contract gap. Turned down because the narrowing is new this round and a narrowed safety rule owes an explicit statement of what it now assumes — otherwise the next reader inherits the gap without the reasoning." } ```

jbr870 commented

Author

Owner

{
  "status": "resolved",
  "chosen_option": "fix-now",
  "rationale": "[CR-40] CLAUDE.md now names this suite as one of four required Verification commands, so a scenario that reds on a fresh clone makes the project's stated test command fail for anyone who is not this machine. That is worse than having no test command, because it trains readers to ignore a red. The fix is a committed fixture journal used as a fallback when the real one is absent, which keeps the real record primary without depending on untracked state. Resolved under the operator's explicit choice of round-2 strategy this session — presented three options (blockers-only, full round, reassess the design) and instructed to proceed with the first — so this follows the recommender rather than overriding it. The recommendation itself is disposition-recommend.sh's, computed from the finding's fix_cost, feature_value, adjacent_to_blocking and category.",
  "rejected_alternative": "defer-to-issue was considered since nothing breaks on this machine today. Turned down because the defect activates precisely when the branch integrates and .devwork is drained — that is, at the moment nobody is watching, and on a tree where the round's own evidence no longer exists to debug it."
}

```json { "status": "resolved", "chosen_option": "fix-now", "rationale": "[CR-40] CLAUDE.md now names this suite as one of four required Verification commands, so a scenario that reds on a fresh clone makes the project's stated test command fail for anyone who is not this machine. That is worse than having no test command, because it trains readers to ignore a red. The fix is a committed fixture journal used as a fallback when the real one is absent, which keeps the real record primary without depending on untracked state. Resolved under the operator's explicit choice of round-2 strategy this session — presented three options (blockers-only, full round, reassess the design) and instructed to proceed with the first — so this follows the recommender rather than overriding it. The recommendation itself is disposition-recommend.sh's, computed from the finding's fix_cost, feature_value, adjacent_to_blocking and category.", "rejected_alternative": "defer-to-issue was considered since nothing breaks on this machine today. Turned down because the defect activates precisely when the branch integrates and .devwork is drained — that is, at the moment nobody is watching, and on a tree where the round's own evidence no longer exists to debug it." } ```

jbr870 commented

Author

Owner

{
  "status": "resolved",
  "chosen_option": "fix-now",
  "rationale": "[CR-41] The filter validates only that a claim's value is an array and never checks element types, while §3's \"scalars and flat string lists only\" is enforced nowhere. A nested map stringifies and compares as a literal, so two actors claiming the same database are dispatched together. The round's own governing principle for this filter — refuse to guess, emit verdict \"unknown\" — already has the shape; this is applying it one level down. Resolved under the operator's explicit choice of round-2 strategy this session — presented three options (blockers-only, full round, reassess the design) and instructed to proceed with the first — so this follows the recommender rather than overriding it. The recommendation itself is disposition-recommend.sh's, computed from the finding's fix_cost, feature_value, adjacent_to_blocking and category.",
  "rejected_alternative": "defer-to-issue was weighed on the grounds that a malformed claim block is itself a contract violation, so arguably out of the filter's remit. Turned down because §3's parseability limits have no enforcement anywhere, which makes the filter the only place the malformation can surface, and it currently answers \"disjoint\" — the permissive direction."
}

```json { "status": "resolved", "chosen_option": "fix-now", "rationale": "[CR-41] The filter validates only that a claim's value is an array and never checks element types, while §3's \"scalars and flat string lists only\" is enforced nowhere. A nested map stringifies and compares as a literal, so two actors claiming the same database are dispatched together. The round's own governing principle for this filter — refuse to guess, emit verdict \"unknown\" — already has the shape; this is applying it one level down. Resolved under the operator's explicit choice of round-2 strategy this session — presented three options (blockers-only, full round, reassess the design) and instructed to proceed with the first — so this follows the recommender rather than overriding it. The recommendation itself is disposition-recommend.sh's, computed from the finding's fix_cost, feature_value, adjacent_to_blocking and category.", "rejected_alternative": "defer-to-issue was weighed on the grounds that a malformed claim block is itself a contract violation, so arguably out of the filter's remit. Turned down because §3's parseability limits have no enforcement anywhere, which makes the filter the only place the malformation can surface, and it currently answers \"disjoint\" — the permissive direction." } ```

jbr870 commented

2026-08-25 19:09:16 +00:00

Author

Owner

{
  "status": "resolved",
  "chosen_option": "fix-now",
  "rationale": "[CR-42] A fix that vacates its own regression test is the CR-31 shape at smaller scale, and leaving it means the stderr-leak regression CR-23 exists to catch could return silently. The scenario still greps a /tmp path the shipped recipe no longer writes, so that assertion can never fire again. Two stale comments ride along in the same edit at no extra cost. Resolved under the operator's explicit choice of round-2 strategy this session — presented three options (blockers-only, full round, reassess the design) and instructed to proceed with the first — so this follows the recommender rather than overriding it. The recommendation itself is disposition-recommend.sh's, computed from the finding's fix_cost, feature_value, adjacent_to_blocking and category.",
  "rejected_alternative": "accept was considered because the missing-versus-empty half of the scenario still measures something real. Turned down because a half-vacuous test reads as full coverage to anyone counting scenarios, which is the round's dominant defect class rather than an exception to it."
}

```json { "status": "resolved", "chosen_option": "fix-now", "rationale": "[CR-42] A fix that vacates its own regression test is the CR-31 shape at smaller scale, and leaving it means the stderr-leak regression CR-23 exists to catch could return silently. The scenario still greps a /tmp path the shipped recipe no longer writes, so that assertion can never fire again. Two stale comments ride along in the same edit at no extra cost. Resolved under the operator's explicit choice of round-2 strategy this session — presented three options (blockers-only, full round, reassess the design) and instructed to proceed with the first — so this follows the recommender rather than overriding it. The recommendation itself is disposition-recommend.sh's, computed from the finding's fix_cost, feature_value, adjacent_to_blocking and category.", "rejected_alternative": "accept was considered because the missing-versus-empty half of the scenario still measures something real. Turned down because a half-vacuous test reads as full coverage to anyone counting scenarios, which is the round's dominant defect class rather than an exception to it." } ```

jbr870 commented

Author

Owner

{
  "status": "resolved",
  "chosen_option": "defer-to-issue",
  "rationale": "[CR-43] Eleven separate parser and vocabulary gaps in the shipped recipes and helpers, sharing no root beyond \"the text met an input its author did not picture\". Substantial by inspection, and the recommender never folds substantial work into a round already carrying six blocking fixes. None is a false green or a safety inversion; each is a wrong answer on an input that does not occur in this repo today. Deferring them as one issue keeps them together, which is how they will actually get fixed — eleven separate issues would fragment a single afternoon's work into eleven re-entries. Resolved under the operator's explicit choice of round-2 strategy this session — presented three options (blockers-only, full round, reassess the design) and instructed to proceed with the first — so this follows the recommender rather than overriding it. The recommendation itself is disposition-recommend.sh's, computed from the finding's fix_cost, feature_value, adjacent_to_blocking and category.",
  "rejected_alternative": "fix-now had a real case: several are one-line regex widenings, and the round is already editing every file involved. Turned down on the convergence rule — fix-workflow.md section 2 stops the patching when re-validation keeps finding the same class, and CR-45 records that this round has now produced that class three times. Folding eleven more small patches into this pass is precisely the third pass of the same shape the rule forbids."
}

```json { "status": "resolved", "chosen_option": "defer-to-issue", "rationale": "[CR-43] Eleven separate parser and vocabulary gaps in the shipped recipes and helpers, sharing no root beyond \"the text met an input its author did not picture\". Substantial by inspection, and the recommender never folds substantial work into a round already carrying six blocking fixes. None is a false green or a safety inversion; each is a wrong answer on an input that does not occur in this repo today. Deferring them as one issue keeps them together, which is how they will actually get fixed — eleven separate issues would fragment a single afternoon's work into eleven re-entries. Resolved under the operator's explicit choice of round-2 strategy this session — presented three options (blockers-only, full round, reassess the design) and instructed to proceed with the first — so this follows the recommender rather than overriding it. The recommendation itself is disposition-recommend.sh's, computed from the finding's fix_cost, feature_value, adjacent_to_blocking and category.", "rejected_alternative": "fix-now had a real case: several are one-line regex widenings, and the round is already editing every file involved. Turned down on the convergence rule — fix-workflow.md section 2 stops the patching when re-validation keeps finding the same class, and CR-45 records that this round has now produced that class three times. Folding eleven more small patches into this pass is precisely the third pass of the same shape the rule forbids." } ```

jbr870 commented

2026-08-25 19:09:16 +00:00

Author

Owner

{
  "status": "resolved",
  "chosen_option": "fix-now",
  "rationale": "[CR-44] Trivial, and it lands in the same journal-template edit CR-38 already opens. The field was added so the cost of serializing could be measured from the record instead of argued about; this round serialized three times and recorded the wait once, as zero. An optional field the reference run does not fill is a field that will not be filled, so the fix is to make the obligation explicit rather than to add machinery. Resolved under the operator's explicit choice of round-2 strategy this session — presented three options (blockers-only, full round, reassess the design) and instructed to proceed with the first — so this follows the recommender rather than overriding it. The recommendation itself is disposition-recommend.sh's, computed from the finding's fix_cost, feature_value, adjacent_to_blocking and category.",
  "rejected_alternative": "accept was arguable because nothing depends on waited_ms and no decision this round turned on it. Turned down because the same shape one severity up — overran_resources, required and absent from 3 of 3 real entries — is a blocking finding in this very set, and treating the two differently by severity alone would leave the cheaper instance to recur."
}

```json { "status": "resolved", "chosen_option": "fix-now", "rationale": "[CR-44] Trivial, and it lands in the same journal-template edit CR-38 already opens. The field was added so the cost of serializing could be measured from the record instead of argued about; this round serialized three times and recorded the wait once, as zero. An optional field the reference run does not fill is a field that will not be filled, so the fix is to make the obligation explicit rather than to add machinery. Resolved under the operator's explicit choice of round-2 strategy this session — presented three options (blockers-only, full round, reassess the design) and instructed to proceed with the first — so this follows the recommender rather than overriding it. The recommendation itself is disposition-recommend.sh's, computed from the finding's fix_cost, feature_value, adjacent_to_blocking and category.", "rejected_alternative": "accept was arguable because nothing depends on waited_ms and no decision this round turned on it. Turned down because the same shape one severity up — overran_resources, required and absent from 3 of 3 real entries — is a blocking finding in this very set, and treating the two differently by severity alone would leave the cheaper instance to recur." } ```

jbr870 commented

2026-08-25 19:09:16 +00:00

Author

Owner

{
  "status": "resolved",
  "chosen_option": "defer-to-issue",
  "rationale": "[CR-45] This is a finding about the design, not a defect in it, and acting on it inside the round it indicts would be the error it describes. Six of this sweep's fifteen findings are the round's own fixes landing where the finding pointed rather than everywhere the rule lives. fix-workflow.md section 2's convergence rule is directly on point and offers exactly two exits: a round explicitly framed at the class, or the class deferred with the residue recorded as a Finding. This resolution takes the second exit deliberately and on the operator's instruction, which is what makes the remaining fix-now items a scoped completion rather than a third patch pass. Resolved under the operator's explicit choice of round-2 strategy this session — presented three options (blockers-only, full round, reassess the design) and instructed to proceed with the first — so this follows the recommender rather than overriding it. The recommendation itself is disposition-recommend.sh's, computed from the finding's fix_cost, feature_value, adjacent_to_blocking and category.",
  "rejected_alternative": "fix-now was the tempting answer and was rejected as a category error. A cross-cutting drift problem cannot be fixed by more of the drifting activity; it needs either a mechanical guard with wider reach than AC-14's six anchor phrases, or an accepted limit stated in the text. Both are design work deserving their own requirements pass, and neither is a QA fix. accept was never in play: the evidence is six measured instances in one sweep."
}

```json { "status": "resolved", "chosen_option": "defer-to-issue", "rationale": "[CR-45] This is a finding about the design, not a defect in it, and acting on it inside the round it indicts would be the error it describes. Six of this sweep's fifteen findings are the round's own fixes landing where the finding pointed rather than everywhere the rule lives. fix-workflow.md section 2's convergence rule is directly on point and offers exactly two exits: a round explicitly framed at the class, or the class deferred with the residue recorded as a Finding. This resolution takes the second exit deliberately and on the operator's instruction, which is what makes the remaining fix-now items a scoped completion rather than a third patch pass. Resolved under the operator's explicit choice of round-2 strategy this session — presented three options (blockers-only, full round, reassess the design) and instructed to proceed with the first — so this follows the recommender rather than overriding it. The recommendation itself is disposition-recommend.sh's, computed from the finding's fix_cost, feature_value, adjacent_to_blocking and category.", "rejected_alternative": "fix-now was the tempting answer and was rejected as a category error. A cross-cutting drift problem cannot be fixed by more of the drifting activity; it needs either a mechanical guard with wider reach than AC-14's six anchor phrases, or an accepted limit stated in the text. Both are design work deserving their own requirements pass, and neither is a QA fix. accept was never in play: the evidence is six measured instances in one sweep." } ```

jbr870 referenced this issue

2026-08-25 19:09:41 +00:00

run-resource-claims: eleven parser and vocabulary gaps in the shipped recipes and helpers #256

jbr870 commented

2026-08-25 19:09:42 +00:00

Author

Owner

Linked: this issue is sibling #256 (recorded by the devwork pipeline).

Linked: this issue is **sibling** #256 (recorded by the devwork pipeline).

jbr870 referenced this issue

2026-08-25 19:09:42 +00:00

A fix lands where the finding pointed, not everywhere the rule lives — six measured instances in one sweep #257

jbr870 commented

2026-08-25 19:09:43 +00:00

Author

Owner

Linked: this issue is sibling #257 (recorded by the devwork pipeline).

Linked: this issue is **sibling** #257 (recorded by the devwork pipeline).

jbr870 commented

2026-08-26 12:57:28 +00:00

Author

Owner

{
  "outcome": "clean",
  "summary": "Round 2 tests stage. 12 red scenarios for the 12 in-scope sweep findings (CR-31 through CR-42 and CR-44), written by two actors on disjoint file boundaries before any fix exists. Every scenario was proven COUPLED, not merely observed red. All four gates green at this commit.",
  "findings": [],
  "artifacts": {
    "test_commit": "570afaab2341a53c4a89f648eb5dee8a3f3cda1e",
    "test_files": [
      "scripts/test-lint-conventions.sh",
      "scripts/test-run-resource-claims.sh"
    ],
    "test_marker": {
      "runner": "shell harness (bash) — scripts/test-*.sh",
      "write": "red_scenario \"<ID>\" <scenario_fn>   # <ID>: unfixed",
      "promote": "swap `red_scenario \"<ID>\" <fn>` for `run_scenario <fn>` — never a bare call"
    },
    "coverage": {
      "scripts/test-lint-conventions.sh": [
        "CR-31"
      ],
      "scripts/test-run-resource-claims.sh": [
        "CR-32",
        "CR-33",
        "CR-34",
        "CR-35",
        "CR-36",
        "CR-37",
        "CR-38",
        "CR-39",
        "CR-40",
        "CR-41",
        "CR-44",
        "CR-42 (repair of an existing green scenario, not a new red one)"
      ]
    },
    "gates_at_test_commit": {
      "lint-conventions.sh": "clean — 49 non-adapter scripts, 84 markdown files, 6 normative anchors",
      "test-lint-conventions.sh": "28 PASS / 0 FAIL / 1 RED (expected)",
      "test-run-resource-claims.sh": "24 PASS / 0 FAIL / 11 RED (expected) / 0 XPASS",
      "test-plugin-gates.sh": "17 passed, 0 failed, 0 skipped — run AFTER the commit, since it measures HEAD"
    },
    "journal_path": ".devwork/feature-qa-intra-run-lane-ownership/dispatch-journal.md"
  },
  "notes": {
    "coupling_discipline": "Every brief carried a three-part proof obligation, and the driver re-ran it independently rather than accepting the actor report: (1) red now for the finding's stated reason, with the printed diagnostic matching the actual symptom; (2) green in a scratch copy once the minimal fix is applied; (3) asserting on a specific observable, never a bare exit code. This round had already produced three false greens, all found by EXECUTING the deliverable rather than reading it, so a passing scenario was not accepted as evidence that a guard works.",
    "dead_assertions_caught": "The discipline caught two assertions that had already been reported as working. (a) CR-42's first repair could not fail: its new unreadable-journal case used a DIRECTORY, but the recipe guards with `[ ! -f ]` and -f is false for a directory, so it exited at the NO RECORD branch before grep ever ran; and its SCAN_DUMP instrumentation was appended after a snippet whose three error branches all `exit 1`, so the dump was unreachable on every path. Driver measured it with a mutation battery (one site, `2>\"$SCAN_ERR\"` -> `2>&1`, 1 match before and 0 after): control PASS, mutant PASS — the assertion was dead. (b) The driver's OWN first CR-31 probe armed on any RRC_INNER_RUN mention, which also matched the `RRC_INNER_RUN=1 bash ...` invocation line and so flipped each CR-4 scenario's final failure return — 4 flips where the fix describes 2 — making those scenarios pass unconditionally and manufacturing the exact evidence the probe was looking for.",
    "cr42_redone": "Redone against the reachable observable instead of instrumentation: with a mode-000 REGULAR journal, the recipe's own UNREADABLE line carries grep's stderr, and is empty exactly when the CR-7 stderr leak is present (shipped: `grep: ...: Permission denied`; leaked: empty). Re-verified by the driver in both directions — control PASS rc=0, mutant FAIL rc=1. Carries a loud SKIP when chmod 000 has no effect (e.g. running as root), so an environment that cannot construct the input reports undetermined rather than passing.",
    "cr31_scope_measured": "CR-31 states a two-part fix. Measurement scoped it: with the recursion guard returning 0, the bare-rc assertion DOES discriminate a masked tree from a clean one (verified by re-introducing the CR-4 defect: both scenario_cr4_deleted_* correctly FAIL). Part 2 — keying on the inner `FAIL: control_clean_tree` line — is therefore hardening, not correctness. The fix stage should not treat CR-31 as unfixed if part 2 is deferred. T3 wrote one scenario rather than two and argued the second would add nothing; that judgement is upheld on measurement rather than on argument.",
    "cr40_fixture_pending": "CR-40's scenario proves the suite reds when .devwork/ is absent, by env-overriding the journal path — it never touches the real .devwork/. The fix needs a COMMITTED fixture journal as a fallback, which lands outside the tests-stage boundary; the actor proposed scripts/fixtures/dispatch-journal.fixture.md and stopped rather than creating it. That is a fix-stage decision.",
    "concurrency": "Two actors dispatched CONCURRENTLY rather than serialized — the first time this round. Their file boundaries are disjoint and the section 4 filter emits no colliding class over their claims. Both DISPATCH entries and both RELEASE entries are in the dispatch journal, stamped from the real clock, with RELEASE written only after the section 5.1 quiescence check (no lingering harness processes, no leftover scratch trees, fixed path absent).",
    "dogfood_note": "T4 claimed /tmp/dispatch-scan.txt under `external` because the four-class schema has no class for a shared writable scratch path — the least-wrong box. The CR-42 repair then removed the dependency, so the claim was never exercised. An unused claim is the safe direction and is not an overrun, but it is a second data point for CR-35: the widened section 2 vocabulary has no home in the section 3 schema."
  }
}

```json { "outcome": "clean", "summary": "Round 2 tests stage. 12 red scenarios for the 12 in-scope sweep findings (CR-31 through CR-42 and CR-44), written by two actors on disjoint file boundaries before any fix exists. Every scenario was proven COUPLED, not merely observed red. All four gates green at this commit.", "findings": [], "artifacts": { "test_commit": "570afaab2341a53c4a89f648eb5dee8a3f3cda1e", "test_files": [ "scripts/test-lint-conventions.sh", "scripts/test-run-resource-claims.sh" ], "test_marker": { "runner": "shell harness (bash) — scripts/test-*.sh", "write": "red_scenario \"<ID>\" <scenario_fn> # <ID>: unfixed", "promote": "swap `red_scenario \"<ID>\" <fn>` for `run_scenario <fn>` — never a bare call" }, "coverage": { "scripts/test-lint-conventions.sh": [ "CR-31" ], "scripts/test-run-resource-claims.sh": [ "CR-32", "CR-33", "CR-34", "CR-35", "CR-36", "CR-37", "CR-38", "CR-39", "CR-40", "CR-41", "CR-44", "CR-42 (repair of an existing green scenario, not a new red one)" ] }, "gates_at_test_commit": { "lint-conventions.sh": "clean — 49 non-adapter scripts, 84 markdown files, 6 normative anchors", "test-lint-conventions.sh": "28 PASS / 0 FAIL / 1 RED (expected)", "test-run-resource-claims.sh": "24 PASS / 0 FAIL / 11 RED (expected) / 0 XPASS", "test-plugin-gates.sh": "17 passed, 0 failed, 0 skipped — run AFTER the commit, since it measures HEAD" }, "journal_path": ".devwork/feature-qa-intra-run-lane-ownership/dispatch-journal.md" }, "notes": { "coupling_discipline": "Every brief carried a three-part proof obligation, and the driver re-ran it independently rather than accepting the actor report: (1) red now for the finding's stated reason, with the printed diagnostic matching the actual symptom; (2) green in a scratch copy once the minimal fix is applied; (3) asserting on a specific observable, never a bare exit code. This round had already produced three false greens, all found by EXECUTING the deliverable rather than reading it, so a passing scenario was not accepted as evidence that a guard works.", "dead_assertions_caught": "The discipline caught two assertions that had already been reported as working. (a) CR-42's first repair could not fail: its new unreadable-journal case used a DIRECTORY, but the recipe guards with `[ ! -f ]` and -f is false for a directory, so it exited at the NO RECORD branch before grep ever ran; and its SCAN_DUMP instrumentation was appended after a snippet whose three error branches all `exit 1`, so the dump was unreachable on every path. Driver measured it with a mutation battery (one site, `2>\"$SCAN_ERR\"` -> `2>&1`, 1 match before and 0 after): control PASS, mutant PASS — the assertion was dead. (b) The driver's OWN first CR-31 probe armed on any RRC_INNER_RUN mention, which also matched the `RRC_INNER_RUN=1 bash ...` invocation line and so flipped each CR-4 scenario's final failure return — 4 flips where the fix describes 2 — making those scenarios pass unconditionally and manufacturing the exact evidence the probe was looking for.", "cr42_redone": "Redone against the reachable observable instead of instrumentation: with a mode-000 REGULAR journal, the recipe's own UNREADABLE line carries grep's stderr, and is empty exactly when the CR-7 stderr leak is present (shipped: `grep: ...: Permission denied`; leaked: empty). Re-verified by the driver in both directions — control PASS rc=0, mutant FAIL rc=1. Carries a loud SKIP when chmod 000 has no effect (e.g. running as root), so an environment that cannot construct the input reports undetermined rather than passing.", "cr31_scope_measured": "CR-31 states a two-part fix. Measurement scoped it: with the recursion guard returning 0, the bare-rc assertion DOES discriminate a masked tree from a clean one (verified by re-introducing the CR-4 defect: both scenario_cr4_deleted_* correctly FAIL). Part 2 — keying on the inner `FAIL: control_clean_tree` line — is therefore hardening, not correctness. The fix stage should not treat CR-31 as unfixed if part 2 is deferred. T3 wrote one scenario rather than two and argued the second would add nothing; that judgement is upheld on measurement rather than on argument.", "cr40_fixture_pending": "CR-40's scenario proves the suite reds when .devwork/ is absent, by env-overriding the journal path — it never touches the real .devwork/. The fix needs a COMMITTED fixture journal as a fallback, which lands outside the tests-stage boundary; the actor proposed scripts/fixtures/dispatch-journal.fixture.md and stopped rather than creating it. That is a fix-stage decision.", "concurrency": "Two actors dispatched CONCURRENTLY rather than serialized — the first time this round. Their file boundaries are disjoint and the section 4 filter emits no colliding class over their claims. Both DISPATCH entries and both RELEASE entries are in the dispatch journal, stamped from the real clock, with RELEASE written only after the section 5.1 quiescence check (no lingering harness processes, no leftover scratch trees, fixed path absent).", "dogfood_note": "T4 claimed /tmp/dispatch-scan.txt under `external` because the four-class schema has no class for a shared writable scratch path — the least-wrong box. The CR-42 repair then removed the dependency, so the claim was never exercised. An unused claim is the safe direction and is not an overrun, but it is a second data point for CR-35: the widened section 2 vocabulary has no home in the section 3 schema." } } ```

jbr870 referenced this issue

2026-08-26 13:48:03 +00:00

Second pipeline time study: measure the effect of the #37 efficiency changes on the next comparable verity feature run #261

jbr870 commented

2026-08-26 14:24:19 +00:00

Author

Owner

{
  "outcome": "clean",
  "summary": "Round 2 fix stage. All 12 in-scope sweep findings fixed and their markers promoted, plus CR-46 — a Critical the driver found while verifying the CR-33 fix and routed back into the same round. Both suites now fully green with zero red markers. All four gates green at this commit.",
  "findings": [],
  "artifacts": {
    "fix_commit": "8346f0f2f549c1f555d8c180a3e3f7f73cc1d2d2",
    "test_commit": "570afaa",
    "fixed": [
      "CR-31",
      "CR-32",
      "CR-33",
      "CR-34",
      "CR-35",
      "CR-36",
      "CR-37",
      "CR-38",
      "CR-39",
      "CR-40",
      "CR-41",
      "CR-44",
      "CR-42 (landed in the tests stage)",
      "CR-46 (created and closed within this stage)"
    ],
    "files": [
      "plugin/skills/_shared/procedures/run-resource-claims.md",
      "plugin/skills/_shared/procedures/journal-template.md",
      "plugin/skills/_shared/procedures/qa-playbook.md",
      "scripts/test-lint-conventions.sh",
      "scripts/test-run-resource-claims.sh",
      "scripts/fixtures/dispatch-journal.fixture.md (new, committed)"
    ],
    "gates_at_fix_commit": {
      "lint-conventions.sh": "clean",
      "test-lint-conventions.sh": "29 PASS / 0 FAIL / 0 RED / 0 XPASS",
      "test-run-resource-claims.sh": "35 PASS / 0 FAIL / 0 RED / 0 XPASS",
      "test-plugin-gates.sh": "17 passed, 0 failed, 0 skipped — run AFTER the commit, since it measures HEAD"
    }
  },
  "notes": {
    "cr46_the_rounds_own_defect": "CR-33 asked that `workers` stop being silently dropped from the §4 filter. The fix did that, but routed `workers` to `verdict: \"unknown\"` whenever claimed, while §4's bold rule still read \"any output at all means apply a remedy\". Measured on the SHIPPED filter against four real claim pairs — including the T3/T4 pair this round actually dispatched concurrently — not one returned `[]`, so the rule resolved to serialize, ALWAYS. A rule that answers serialize for every input does not fail safe, it fails useless: it is a rule an operator learns to override, and an overridden rule protects nothing. Fixed with a third verdict, `budget`, routing to the sum test rather than to §1's remedy. In scope for this round rather than #257 because it is a defect INSIDE the fix, not drift to a sibling location.",
    "every_promotion_earned": "The driver did not accept a promotion on the actor's word. Reverting the three documents to test_commit 570afaa while KEEPING the promoted markers put all ten scenarios back to red, so no promotion rests on a scenario passing for an unrelated reason. Re-run after the CR-46 repair with the same result.",
    "cr31_naive_fix_recreates_cr31": "Measured before dispatching the fixer. Flip the two CR-4 guards to return 0 and promote CR-31's own marker, and the outer run is rc=0 with every scenario PASS while a PRISTINE inner run is rc=1 — the contamination moves into the scenario that detects it, because that scenario's own guard `return 1` routes through fail() once promoted, and it still reports success since it greps only for the CR-4 FAIL lines and its own is not one of them. This SUPERSEDED the driver's earlier conclusion that part 2 of CR-31's fix was optional hardening — that measurement was valid only for a configuration that was never going to ship. Part 2 became required, and all three guard-bearing scenarios now return 0 through a loud skip.",
    "verified_at_the_inner_level": "A green outer run is exactly what the naive CR-31 fix produces, so the driver verified on scratch copies at the inner level: (a) pristine inner run rc=0, zero FAIL lines, three loud SKIPs; (b) control masked to re-introduce the CR-4 defect — outer rc=1 with both scenario_cr4_deleted_* FAILing, so a masked regression is still CAUGHT rather than merely reported caught; (c) .devwork/ removed from the copy — suite rc=0, zero FAIL, loud FIXTURE FALLBACK line and fixture_fallback_count=1; (d) the fixture exists and is not gitignored, so it will actually commit.",
    "the_rounds_pattern": "CR-32, CR-33/CR-46, CR-34 and CR-35 are one thing stated four times: a normative rule in prose and the mechanism implementing it, drifting apart, with every mechanical gate green across the gap. CR-46 is the sharpest instance — created eighty lines from the CR-32 repair, in the same sitting. The design question is deferred to #257; this note records that the round produced a fourth and fifth instance after that deferral was taken.",
    "residual_not_blocking": "F4 could not extend scripts/_red-lib.sh (outside its boundary), so guard-fired skips use a file-local skip() that prints SKIP (LOUD) and returns 0; run_scenario then prints its own PASS on top. A guard firing in an OUTER run — possible only if RRC_INNER_RUN is exported into the environment — would silently pass three scenarios, mitigated but not prevented by the loud line. Carried into the sweep rather than fixed here."
  }
}

```json { "outcome": "clean", "summary": "Round 2 fix stage. All 12 in-scope sweep findings fixed and their markers promoted, plus CR-46 — a Critical the driver found while verifying the CR-33 fix and routed back into the same round. Both suites now fully green with zero red markers. All four gates green at this commit.", "findings": [], "artifacts": { "fix_commit": "8346f0f2f549c1f555d8c180a3e3f7f73cc1d2d2", "test_commit": "570afaa", "fixed": [ "CR-31", "CR-32", "CR-33", "CR-34", "CR-35", "CR-36", "CR-37", "CR-38", "CR-39", "CR-40", "CR-41", "CR-44", "CR-42 (landed in the tests stage)", "CR-46 (created and closed within this stage)" ], "files": [ "plugin/skills/_shared/procedures/run-resource-claims.md", "plugin/skills/_shared/procedures/journal-template.md", "plugin/skills/_shared/procedures/qa-playbook.md", "scripts/test-lint-conventions.sh", "scripts/test-run-resource-claims.sh", "scripts/fixtures/dispatch-journal.fixture.md (new, committed)" ], "gates_at_fix_commit": { "lint-conventions.sh": "clean", "test-lint-conventions.sh": "29 PASS / 0 FAIL / 0 RED / 0 XPASS", "test-run-resource-claims.sh": "35 PASS / 0 FAIL / 0 RED / 0 XPASS", "test-plugin-gates.sh": "17 passed, 0 failed, 0 skipped — run AFTER the commit, since it measures HEAD" } }, "notes": { "cr46_the_rounds_own_defect": "CR-33 asked that `workers` stop being silently dropped from the §4 filter. The fix did that, but routed `workers` to `verdict: \"unknown\"` whenever claimed, while §4's bold rule still read \"any output at all means apply a remedy\". Measured on the SHIPPED filter against four real claim pairs — including the T3/T4 pair this round actually dispatched concurrently — not one returned `[]`, so the rule resolved to serialize, ALWAYS. A rule that answers serialize for every input does not fail safe, it fails useless: it is a rule an operator learns to override, and an overridden rule protects nothing. Fixed with a third verdict, `budget`, routing to the sum test rather than to §1's remedy. In scope for this round rather than #257 because it is a defect INSIDE the fix, not drift to a sibling location.", "every_promotion_earned": "The driver did not accept a promotion on the actor's word. Reverting the three documents to test_commit 570afaa while KEEPING the promoted markers put all ten scenarios back to red, so no promotion rests on a scenario passing for an unrelated reason. Re-run after the CR-46 repair with the same result.", "cr31_naive_fix_recreates_cr31": "Measured before dispatching the fixer. Flip the two CR-4 guards to return 0 and promote CR-31's own marker, and the outer run is rc=0 with every scenario PASS while a PRISTINE inner run is rc=1 — the contamination moves into the scenario that detects it, because that scenario's own guard `return 1` routes through fail() once promoted, and it still reports success since it greps only for the CR-4 FAIL lines and its own is not one of them. This SUPERSEDED the driver's earlier conclusion that part 2 of CR-31's fix was optional hardening — that measurement was valid only for a configuration that was never going to ship. Part 2 became required, and all three guard-bearing scenarios now return 0 through a loud skip.", "verified_at_the_inner_level": "A green outer run is exactly what the naive CR-31 fix produces, so the driver verified on scratch copies at the inner level: (a) pristine inner run rc=0, zero FAIL lines, three loud SKIPs; (b) control masked to re-introduce the CR-4 defect — outer rc=1 with both scenario_cr4_deleted_* FAILing, so a masked regression is still CAUGHT rather than merely reported caught; (c) .devwork/ removed from the copy — suite rc=0, zero FAIL, loud FIXTURE FALLBACK line and fixture_fallback_count=1; (d) the fixture exists and is not gitignored, so it will actually commit.", "the_rounds_pattern": "CR-32, CR-33/CR-46, CR-34 and CR-35 are one thing stated four times: a normative rule in prose and the mechanism implementing it, drifting apart, with every mechanical gate green across the gap. CR-46 is the sharpest instance — created eighty lines from the CR-32 repair, in the same sitting. The design question is deferred to #257; this note records that the round produced a fourth and fifth instance after that deferral was taken.", "residual_not_blocking": "F4 could not extend scripts/_red-lib.sh (outside its boundary), so guard-fired skips use a file-local skip() that prints SKIP (LOUD) and returns 0; run_scenario then prints its own PASS on top. A guard firing in an OUTER run — possible only if RRC_INNER_RUN is exported into the environment — would silently pass three scenarios, mitigated but not prevented by the loud line. Carried into the sweep rather than fixed here." } } ```

jbr870 commented

2026-08-26 14:58:27 +00:00

Author

Owner

{
  "outcome": "issues-found",
  "summary": "SWEEP 2 (round 2 exit gate) — 9 findings against the post-fix tree at 8346f0f. No Critical; one High (CR-47) blocks. The round does NOT exit; next_state stays qa.",
  "findings": [
    {
      "id": "CR-47",
      "category": "in-scope-blocking",
      "severity": "High",
      "summary": "§7 step 4 speaks a two-outcome vocabulary that its own §4 test no longer emits — and both real overrun shapes fall to the permissive branch.",
      "reasoning": "Step 4 decides sole ownership by intersecting overran_resources against every other intersecting actor's claims '(same §4 test)', then reads the result in exactly two outcomes: 'nothing shared there means sole ownership (recorded, not voided); anything shared ... means void'. But §4 emits four verdicts — shared, unknown, budget, []. Driver ran the SHIPPED filter on the reference run's own overrun shapes. (a) A workers overrun, {workers:3} against a peer claim of workers:1, returns verdict 'budget' and zero 'shared' entries, so step 4 reads it as sole ownership and RECORDS it — meaning a worker-budget overrun can never void, on the very contention the contract was written for; 3 of this round's 4 real overruns were workers. (b) An overrun onto a class the peer never claimed — the typical scratch-surface case, F2's improvised git_object_store — returns all-unknown and again zero 'shared', so step 4 silently converts UNJUDGEABLE into DISJOINT. That is the one-output-two-answers inversion §4's own bold rule forbids, one section down, in the section this round has now repaired four times. Control confirms step 4 works for the case it was written against: an overrun onto a genuinely co-claimed database returns 'shared' and voids. This is CR-32/CR-46's shape a third time: a verdict was added to §4 and never reached the consumer that reads it.",
      "proposed_action": "Give step 4 a branch per verdict: 'budget' sums the overrun against the peer's claimed workers and the pool, 'unknown' routes to a remedy (never to 'recorded'), 'shared' voids as now.",
      "fix_cost": "low",
      "feature_value": "core",
      "adjacent_to_blocking": true
    },
    {
      "id": "CR-48",
      "category": "in-scope-deferrable",
      "severity": "Medium",
      "summary": "CR-35's widened disclosure duty never reached either consumer's paraphrase — the two documents that tell the driver to put the duty in the brief.",
      "reasoning": "qa-playbook.md:58 and develop/SKILL.md:116 both still read 'a database, port, worker budget or external resource its claim did not name' — the pre-widening four-class list — and both instruct the driver to spell the duty out in the brief the actor actually reads. Contract §5 now includes shared writable scratch/cache surfaces and any shared artefact one actor writes while another reads or executes it. Confirmed by direct grep at 8346f0f: the fix commit touched neither sentence. An actor briefed from these texts repeats T1's round-1 miss verbatim — recording overran_claim: false for a shared scratch path, correctly under the text it was given. Second drift of the same rule: CR-35 fixed §5 itself and stopped there.",
      "proposed_action": "Widen both paraphrases to defer to §2's vocabulary rather than re-enumerating it.",
      "fix_cost": "low",
      "feature_value": "core",
      "adjacent_to_blocking": true
    },
    {
      "id": "CR-49",
      "category": "in-scope-deferrable",
      "severity": "Medium",
      "summary": "§7's runnable output cannot be attributed to actors — 10 anonymous claim lines, 9 byte-identical, with the actor and timestamp keys deleted by its own trap.",
      "reasoning": "Driver-authorised sweep ran the shipped recipe verbatim against the real journal: it prints claims JSON only, no actor names or windows, and the trap removes $SCAN which held the actor:/timestamp: lines needed to pair claim to actor to window. To feed any pair into §4 — which is what steps 3 and 4 then ask for — the reader must redo the extraction from the journal by hand. A gap with a workaround, but it is exactly the manual re-derivation that 'answer it from the record' exists to remove.",
      "proposed_action": "Emit actor and window alongside each claim, or keep the scan available to the steps that need it.",
      "fix_cost": "medium",
      "feature_value": "core",
      "adjacent_to_blocking": false
    },
    {
      "id": "CR-50",
      "category": "in-scope-deferrable",
      "severity": "Low",
      "summary": "An exported RRC_INNER_RUN makes an outer run silently pass three guarded scenarios — a measured false-green vector with an exotic precondition.",
      "reasoning": "The residual the fix stage carried forward, now measured in both halves on scratch copies. (1) RRC_INNER_RUN=1 exported into an OUTER run: three SKIP (LOUD) lines, then PASS for all three guarded scenarios, suite rc=0, skip_count=3. (2) The same leak plus the CR-4 defect re-introduced: rc=0 — a false green; the identical masked tree in a clean environment reds, both cr4 scenarios FAIL, rc=1. Judged Low because it needs the operator or CI to export the variable, and the SKIP lines and skip_count are visible in the output. Cheap hardening exists: the outer run sets the guard to a per-run nonce and the inner guard compares equality, so an inherited stale value cannot match.",
      "proposed_action": "Nonce the recursion guard so an inherited value cannot satisfy it.",
      "fix_cost": "low",
      "feature_value": "incidental",
      "adjacent_to_blocking": false
    },
    {
      "id": "CR-51",
      "category": "in-scope-deferrable",
      "severity": "Low",
      "summary": "CR-40's fixture fallback keys on existence only, so a present-but-malformed real journal reds the required suite instead of falling back.",
      "reasoning": "Measured: scratch copy with the real journal replaced by garbage, scenario_cr1 FAILs and the suite exits 1, with no fixture fallback. The failure is loud and its diagnostic is correct, and only this feature's own local .devwork file can produce the state, so the blast radius is one machine. But CR-40's whole point was that a required Verification command must not red on a state the developer did not cause.",
      "proposed_action": "Fall back when the real journal is unusable, not only when it is absent.",
      "fix_cost": "low",
      "feature_value": "incidental",
      "adjacent_to_blocking": false
    },
    {
      "id": "CR-52",
      "category": "in-scope-deferrable",
      "severity": "Low",
      "summary": "CR-38's correction pattern cites journal-template.md as the shape authority, but journal-template.md defines no correction shape.",
      "reasoning": "§6 now names 'a new DISCOVERY entry (journal-template.md)' as the supersession pattern, but journal-template.md has no corrects: field and no mention of corrections at all — grepped and confirmed. The reference run improvised a corrects: key twice. So the contract points at a shape authority that does not carry the shape. Second drift of the same rule: the CR-38 fix landed in the contract and stopped at the document it cites.",
      "proposed_action": "Define the correction entry's shape in journal-template.md, including the corrects: field the run improvised.",
      "fix_cost": "low",
      "feature_value": "core",
      "adjacent_to_blocking": true
    },
    {
      "id": "CR-53",
      "category": "in-scope-deferrable",
      "severity": "Low",
      "summary": "journal-template's claims:/overran_resources: shapes show only the four suite classes and never say project-named keys are permitted, while §2 and §4 depend on them.",
      "reasoning": "Measured consequences from this round's own record: T4 misfiled a shared scratch path under external because no other box existed, and F2 minted git_object_store on the spot; the sweep then did the same in its own disclosure. The improvised-key route does work through the §4 filter — verified — so the mechanism is right and only the record shape is silent. This is CR-35's record-shape side, unfixed when CR-35 fixed the duty sentence.",
      "proposed_action": "State in journal-template.md that project-named keys are permitted alongside the four, and show one.",
      "fix_cost": "low",
      "feature_value": "core",
      "adjacent_to_blocking": true
    },
    {
      "id": "CR-54",
      "category": "in-scope-deferrable",
      "severity": "Low",
      "summary": "scenario_cr23's root-environment SKIP returns 1, so a required Verification command fails outright on any box where chmod 000 does not block reads.",
      "reasoning": "The skip guard added for the mode-000 case reports loudly but returns non-zero, failing the whole suite rather than reporting the check undetermined. Plausible on root boxes, including the devcontainers of #61. It also leaves two skip semantics in one repo: test-lint-conventions.sh's skip() returns 0, this one returns 1. Loud-but-red is defensible on its own terms; the inconsistency is not, and it is the CR-40 class — a required command red on a state the developer did not cause.",
      "proposed_action": "Make the undetermined case return 0 with a loud skip, consistent with the sibling harness.",
      "fix_cost": "low",
      "feature_value": "core",
      "adjacent_to_blocking": true
    },
    {
      "id": "CR-55",
      "category": "in-scope-deferrable",
      "severity": "Low",
      "summary": "A malformed workers value gets verdict 'budget' rather than 'unknown', routing garbage to the sum test instead of to §1's malformed-means-serialize.",
      "reasoning": "Measured: workers:[4] on both sides returns verdict 'budget'. The workers branch is tested before the element-type check CR-41 added, so a non-scalar workers value never reaches the malformed path. Same §4 verdict vocabulary as CR-47 and the same ordering hazard CR-41 fixed one class over.",
      "proposed_action": "Test the workers value's shape before assigning the budget verdict.",
      "fix_cost": "low",
      "feature_value": "core",
      "adjacent_to_blocking": true
    }
  ],
  "artifacts": {
    "report_path": ".devwork/feature-qa-intra-run-lane-ownership/code-report.md",
    "journal_path": ".devwork/feature-qa-intra-run-lane-ownership/code-journal.md",
    "dispatch_journal": ".devwork/feature-qa-intra-run-lane-ownership/dispatch-journal.md",
    "swept_head": "8346f0f"
  },
  "notes": {
    "executing_sweep": "Unlike round 1's sweep, this reviewer was explicitly AUTHORISED AND EXPECTED TO EXECUTE — gates, extracted snippets, mutated scratch copies — because every one of the round's worst defects had been invisible to reading. It ran the shipped §4 filter on ~15 input pairs, the shipped §7 recipe against the real journal and the committed fixture, a 7-mutation revert battery on full scratch trees (all 7 caught), and the leak and malformed-journal probes. That authorisation is what produced CR-47.",
    "cr47_verified_by_driver": "The driver re-measured CR-47 independently rather than accepting the report. A workers overrun ({workers:3} vs a peer claiming workers:1) returns verdict 'budget' with ZERO shared entries; an overrun onto a class the peer never claimed returns all-unknown, also zero shared. §7 step 4's two-outcome rule reads both as 'nothing shared' therefore sole ownership therefore RECORDED, never voided. A control overrun onto a genuinely co-claimed database still returns 'shared' and voids — so step 4 works for the one case it was written against and fails permissively for the two the reference run actually produced.",
    "convergence": "This is the class's THIRD escape. fix-workflow.md §2's convergence rule was already invoked at the round-1 sweep (CR-45) and its defer exit taken to #257; round 2 then produced CR-46 and this sweep produces CR-47, CR-48, CR-52, CR-53 and CR-55 — all the same shape: a normative rule and the mechanism implementing it drifting apart, every mechanical gate green across the gap. Round 3 therefore takes the rule's OTHER exit — a round explicitly FRAMED AT THE CLASS rather than a third finding-by-finding patch pass. Scope: every rule that has now drifted twice (step 4's verdict vocabulary, the disclosure duty's consumers, the correction pattern's shape authority, the record shape's class list), fixed by making each consumer defer to its source instead of re-enumerating it.",
    "deferred": "CR-49 (attribution in §7's output — real design work), CR-50 (the RRC_INNER_RUN nonce — measured but exotic precondition) and CR-51 (malformed-not-absent journal — one machine's blast radius) are deferred out of round 3 and carried to the follow-up issue.",
    "disclosure": "The reviewer disclosed overran_claim: true with a structured overran_resources including a git_object_store key the four-class schema has no room for — simultaneously an honest disclosure and first-hand evidence for its own finding CR-53.",
    "exit_invariant": "qa-playbook §7: QA is done when a full sweep completes with nothing modified after it. git status was verified clean at 8346f0f before and after this sweep, so the tree is untouched — but the sweep found findings, so this is a new round including its own sweep."
  }
}

```json { "outcome": "issues-found", "summary": "SWEEP 2 (round 2 exit gate) — 9 findings against the post-fix tree at 8346f0f. No Critical; one High (CR-47) blocks. The round does NOT exit; next_state stays qa.", "findings": [ { "id": "CR-47", "category": "in-scope-blocking", "severity": "High", "summary": "§7 step 4 speaks a two-outcome vocabulary that its own §4 test no longer emits — and both real overrun shapes fall to the permissive branch.", "reasoning": "Step 4 decides sole ownership by intersecting overran_resources against every other intersecting actor's claims '(same §4 test)', then reads the result in exactly two outcomes: 'nothing shared there means sole ownership (recorded, not voided); anything shared ... means void'. But §4 emits four verdicts — shared, unknown, budget, []. Driver ran the SHIPPED filter on the reference run's own overrun shapes. (a) A workers overrun, {workers:3} against a peer claim of workers:1, returns verdict 'budget' and zero 'shared' entries, so step 4 reads it as sole ownership and RECORDS it — meaning a worker-budget overrun can never void, on the very contention the contract was written for; 3 of this round's 4 real overruns were workers. (b) An overrun onto a class the peer never claimed — the typical scratch-surface case, F2's improvised git_object_store — returns all-unknown and again zero 'shared', so step 4 silently converts UNJUDGEABLE into DISJOINT. That is the one-output-two-answers inversion §4's own bold rule forbids, one section down, in the section this round has now repaired four times. Control confirms step 4 works for the case it was written against: an overrun onto a genuinely co-claimed database returns 'shared' and voids. This is CR-32/CR-46's shape a third time: a verdict was added to §4 and never reached the consumer that reads it.", "proposed_action": "Give step 4 a branch per verdict: 'budget' sums the overrun against the peer's claimed workers and the pool, 'unknown' routes to a remedy (never to 'recorded'), 'shared' voids as now.", "fix_cost": "low", "feature_value": "core", "adjacent_to_blocking": true }, { "id": "CR-48", "category": "in-scope-deferrable", "severity": "Medium", "summary": "CR-35's widened disclosure duty never reached either consumer's paraphrase — the two documents that tell the driver to put the duty in the brief.", "reasoning": "qa-playbook.md:58 and develop/SKILL.md:116 both still read 'a database, port, worker budget or external resource its claim did not name' — the pre-widening four-class list — and both instruct the driver to spell the duty out in the brief the actor actually reads. Contract §5 now includes shared writable scratch/cache surfaces and any shared artefact one actor writes while another reads or executes it. Confirmed by direct grep at 8346f0f: the fix commit touched neither sentence. An actor briefed from these texts repeats T1's round-1 miss verbatim — recording overran_claim: false for a shared scratch path, correctly under the text it was given. Second drift of the same rule: CR-35 fixed §5 itself and stopped there.", "proposed_action": "Widen both paraphrases to defer to §2's vocabulary rather than re-enumerating it.", "fix_cost": "low", "feature_value": "core", "adjacent_to_blocking": true }, { "id": "CR-49", "category": "in-scope-deferrable", "severity": "Medium", "summary": "§7's runnable output cannot be attributed to actors — 10 anonymous claim lines, 9 byte-identical, with the actor and timestamp keys deleted by its own trap.", "reasoning": "Driver-authorised sweep ran the shipped recipe verbatim against the real journal: it prints claims JSON only, no actor names or windows, and the trap removes $SCAN which held the actor:/timestamp: lines needed to pair claim to actor to window. To feed any pair into §4 — which is what steps 3 and 4 then ask for — the reader must redo the extraction from the journal by hand. A gap with a workaround, but it is exactly the manual re-derivation that 'answer it from the record' exists to remove.", "proposed_action": "Emit actor and window alongside each claim, or keep the scan available to the steps that need it.", "fix_cost": "medium", "feature_value": "core", "adjacent_to_blocking": false }, { "id": "CR-50", "category": "in-scope-deferrable", "severity": "Low", "summary": "An exported RRC_INNER_RUN makes an outer run silently pass three guarded scenarios — a measured false-green vector with an exotic precondition.", "reasoning": "The residual the fix stage carried forward, now measured in both halves on scratch copies. (1) RRC_INNER_RUN=1 exported into an OUTER run: three SKIP (LOUD) lines, then PASS for all three guarded scenarios, suite rc=0, skip_count=3. (2) The same leak plus the CR-4 defect re-introduced: rc=0 — a false green; the identical masked tree in a clean environment reds, both cr4 scenarios FAIL, rc=1. Judged Low because it needs the operator or CI to export the variable, and the SKIP lines and skip_count are visible in the output. Cheap hardening exists: the outer run sets the guard to a per-run nonce and the inner guard compares equality, so an inherited stale value cannot match.", "proposed_action": "Nonce the recursion guard so an inherited value cannot satisfy it.", "fix_cost": "low", "feature_value": "incidental", "adjacent_to_blocking": false }, { "id": "CR-51", "category": "in-scope-deferrable", "severity": "Low", "summary": "CR-40's fixture fallback keys on existence only, so a present-but-malformed real journal reds the required suite instead of falling back.", "reasoning": "Measured: scratch copy with the real journal replaced by garbage, scenario_cr1 FAILs and the suite exits 1, with no fixture fallback. The failure is loud and its diagnostic is correct, and only this feature's own local .devwork file can produce the state, so the blast radius is one machine. But CR-40's whole point was that a required Verification command must not red on a state the developer did not cause.", "proposed_action": "Fall back when the real journal is unusable, not only when it is absent.", "fix_cost": "low", "feature_value": "incidental", "adjacent_to_blocking": false }, { "id": "CR-52", "category": "in-scope-deferrable", "severity": "Low", "summary": "CR-38's correction pattern cites journal-template.md as the shape authority, but journal-template.md defines no correction shape.", "reasoning": "§6 now names 'a new DISCOVERY entry (journal-template.md)' as the supersession pattern, but journal-template.md has no corrects: field and no mention of corrections at all — grepped and confirmed. The reference run improvised a corrects: key twice. So the contract points at a shape authority that does not carry the shape. Second drift of the same rule: the CR-38 fix landed in the contract and stopped at the document it cites.", "proposed_action": "Define the correction entry's shape in journal-template.md, including the corrects: field the run improvised.", "fix_cost": "low", "feature_value": "core", "adjacent_to_blocking": true }, { "id": "CR-53", "category": "in-scope-deferrable", "severity": "Low", "summary": "journal-template's claims:/overran_resources: shapes show only the four suite classes and never say project-named keys are permitted, while §2 and §4 depend on them.", "reasoning": "Measured consequences from this round's own record: T4 misfiled a shared scratch path under external because no other box existed, and F2 minted git_object_store on the spot; the sweep then did the same in its own disclosure. The improvised-key route does work through the §4 filter — verified — so the mechanism is right and only the record shape is silent. This is CR-35's record-shape side, unfixed when CR-35 fixed the duty sentence.", "proposed_action": "State in journal-template.md that project-named keys are permitted alongside the four, and show one.", "fix_cost": "low", "feature_value": "core", "adjacent_to_blocking": true }, { "id": "CR-54", "category": "in-scope-deferrable", "severity": "Low", "summary": "scenario_cr23's root-environment SKIP returns 1, so a required Verification command fails outright on any box where chmod 000 does not block reads.", "reasoning": "The skip guard added for the mode-000 case reports loudly but returns non-zero, failing the whole suite rather than reporting the check undetermined. Plausible on root boxes, including the devcontainers of #61. It also leaves two skip semantics in one repo: test-lint-conventions.sh's skip() returns 0, this one returns 1. Loud-but-red is defensible on its own terms; the inconsistency is not, and it is the CR-40 class — a required command red on a state the developer did not cause.", "proposed_action": "Make the undetermined case return 0 with a loud skip, consistent with the sibling harness.", "fix_cost": "low", "feature_value": "core", "adjacent_to_blocking": true }, { "id": "CR-55", "category": "in-scope-deferrable", "severity": "Low", "summary": "A malformed workers value gets verdict 'budget' rather than 'unknown', routing garbage to the sum test instead of to §1's malformed-means-serialize.", "reasoning": "Measured: workers:[4] on both sides returns verdict 'budget'. The workers branch is tested before the element-type check CR-41 added, so a non-scalar workers value never reaches the malformed path. Same §4 verdict vocabulary as CR-47 and the same ordering hazard CR-41 fixed one class over.", "proposed_action": "Test the workers value's shape before assigning the budget verdict.", "fix_cost": "low", "feature_value": "core", "adjacent_to_blocking": true } ], "artifacts": { "report_path": ".devwork/feature-qa-intra-run-lane-ownership/code-report.md", "journal_path": ".devwork/feature-qa-intra-run-lane-ownership/code-journal.md", "dispatch_journal": ".devwork/feature-qa-intra-run-lane-ownership/dispatch-journal.md", "swept_head": "8346f0f" }, "notes": { "executing_sweep": "Unlike round 1's sweep, this reviewer was explicitly AUTHORISED AND EXPECTED TO EXECUTE — gates, extracted snippets, mutated scratch copies — because every one of the round's worst defects had been invisible to reading. It ran the shipped §4 filter on ~15 input pairs, the shipped §7 recipe against the real journal and the committed fixture, a 7-mutation revert battery on full scratch trees (all 7 caught), and the leak and malformed-journal probes. That authorisation is what produced CR-47.", "cr47_verified_by_driver": "The driver re-measured CR-47 independently rather than accepting the report. A workers overrun ({workers:3} vs a peer claiming workers:1) returns verdict 'budget' with ZERO shared entries; an overrun onto a class the peer never claimed returns all-unknown, also zero shared. §7 step 4's two-outcome rule reads both as 'nothing shared' therefore sole ownership therefore RECORDED, never voided. A control overrun onto a genuinely co-claimed database still returns 'shared' and voids — so step 4 works for the one case it was written against and fails permissively for the two the reference run actually produced.", "convergence": "This is the class's THIRD escape. fix-workflow.md §2's convergence rule was already invoked at the round-1 sweep (CR-45) and its defer exit taken to #257; round 2 then produced CR-46 and this sweep produces CR-47, CR-48, CR-52, CR-53 and CR-55 — all the same shape: a normative rule and the mechanism implementing it drifting apart, every mechanical gate green across the gap. Round 3 therefore takes the rule's OTHER exit — a round explicitly FRAMED AT THE CLASS rather than a third finding-by-finding patch pass. Scope: every rule that has now drifted twice (step 4's verdict vocabulary, the disclosure duty's consumers, the correction pattern's shape authority, the record shape's class list), fixed by making each consumer defer to its source instead of re-enumerating it.", "deferred": "CR-49 (attribution in §7's output — real design work), CR-50 (the RRC_INNER_RUN nonce — measured but exotic precondition) and CR-51 (malformed-not-absent journal — one machine's blast radius) are deferred out of round 3 and carried to the follow-up issue.", "disclosure": "The reviewer disclosed overran_claim: true with a structured overran_resources including a git_object_store key the four-class schema has no room for — simultaneously an honest disclosure and first-hand evidence for its own finding CR-53.", "exit_invariant": "qa-playbook §7: QA is done when a full sweep completes with nothing modified after it. git status was verified clean at 8346f0f before and after this sweep, so the tree is untouched — but the sweep found findings, so this is a new round including its own sweep." } } ```

jbr870 commented

2026-08-26 14:58:30 +00:00

Author

Owner

{
  "next_state": "qa",
  "produced": [
    {
      "kind": "qa-report",
      "ref": "2009",
      "summary": "code phase=fix — 14 findings fixed, all 4 gates green"
    },
    {
      "kind": "qa-report",
      "ref": "latest",
      "summary": "code phase=validate — sweep 2, 9 findings, 1 High blocking"
    },
    {
      "kind": "code-bundle",
      "ref": "8346f0f",
      "summary": "the swept HEAD: fix commit 8346f0f on test_commit 570afaa"
    }
  ],
  "findings": [
    {
      "category": "in-scope-blocking",
      "severity": "high",
      "summary": "[code CR-47] §7 step 4 speaks a two-outcome vocabulary that its own §4 test no longer emits — and both real overrun shapes fall to the permissive branch.",
      "reasoning": "Step 4 decides sole ownership by intersecting overran_resources against every other intersecting actor's claims '(same §4 test)', then reads the result in exactly two outcomes: 'nothing shared there means sole ownership (recorded, not voided); anything shared ... means void'. But §4 emits four verdicts — shared, unknown, budget, []. Driver ran the SHIPPED filter on the reference run's own overrun shapes. (a) A workers overrun, {workers:3} against a peer claim of workers:1, returns verdict 'budget' and zero 'shared' entries, so step 4 reads it as sole ownership and RECORDS it — meaning a worker-budget overrun can never void, on the very contention the contract was written for; 3 of this round's 4 real overruns were workers. (b) An overrun onto a class the peer never claimed — the typical scratch-surface case, F2's improvised git_object_store — returns all-unknown and again zero 'shared', so step 4 silently converts UNJUDGEABLE into DISJOINT. That is the one-output-two-answers inversion §4's own bold rule forbids, one section down, in the section this round has now repaired four times. Control confirms step 4 works for the case it was written against: an overrun onto a genuinely co-claimed database returns 'shared' and voids. This is CR-32/CR-46's shape a third time: a verdict was added to §4 and never reached the consumer that reads it.",
      "proposed_action": "Give step 4 a branch per verdict: 'budget' sums the overrun against the peer's claimed workers and the pool, 'unknown' routes to a remedy (never to 'recorded'), 'shared' voids as now.",
      "fix_cost": "low",
      "feature_value": "core",
      "adjacent_to_blocking": true,
      "id": "F-PO-43-6-1"
    },
    {
      "category": "in-scope-deferrable",
      "severity": "medium",
      "summary": "[code CR-48] CR-35's widened disclosure duty never reached either consumer's paraphrase — the two documents that tell the driver to put the duty in the brief.",
      "reasoning": "qa-playbook.md:58 and develop/SKILL.md:116 both still read 'a database, port, worker budget or external resource its claim did not name' — the pre-widening four-class list — and both instruct the driver to spell the duty out in the brief the actor actually reads. Contract §5 now includes shared writable scratch/cache surfaces and any shared artefact one actor writes while another reads or executes it. Confirmed by direct grep at 8346f0f: the fix commit touched neither sentence. An actor briefed from these texts repeats T1's round-1 miss verbatim — recording overran_claim: false for a shared scratch path, correctly under the text it was given. Second drift of the same rule: CR-35 fixed §5 itself and stopped there.",
      "proposed_action": "Widen both paraphrases to defer to §2's vocabulary rather than re-enumerating it.",
      "fix_cost": "low",
      "feature_value": "core",
      "adjacent_to_blocking": true,
      "id": "F-PO-43-6-2"
    },
    {
      "category": "in-scope-deferrable",
      "severity": "medium",
      "summary": "[code CR-49] §7's runnable output cannot be attributed to actors — 10 anonymous claim lines, 9 byte-identical, with the actor and timestamp keys deleted by its own trap.",
      "reasoning": "Driver-authorised sweep ran the shipped recipe verbatim against the real journal: it prints claims JSON only, no actor names or windows, and the trap removes $SCAN which held the actor:/timestamp: lines needed to pair claim to actor to window. To feed any pair into §4 — which is what steps 3 and 4 then ask for — the reader must redo the extraction from the journal by hand. A gap with a workaround, but it is exactly the manual re-derivation that 'answer it from the record' exists to remove.",
      "proposed_action": "Emit actor and window alongside each claim, or keep the scan available to the steps that need it.",
      "fix_cost": "medium",
      "feature_value": "core",
      "adjacent_to_blocking": false,
      "id": "F-PO-43-6-3"
    },
    {
      "category": "in-scope-deferrable",
      "severity": "low",
      "summary": "[code CR-50] An exported RRC_INNER_RUN makes an outer run silently pass three guarded scenarios — a measured false-green vector with an exotic precondition.",
      "reasoning": "The residual the fix stage carried forward, now measured in both halves on scratch copies. (1) RRC_INNER_RUN=1 exported into an OUTER run: three SKIP (LOUD) lines, then PASS for all three guarded scenarios, suite rc=0, skip_count=3. (2) The same leak plus the CR-4 defect re-introduced: rc=0 — a false green; the identical masked tree in a clean environment reds, both cr4 scenarios FAIL, rc=1. Judged Low because it needs the operator or CI to export the variable, and the SKIP lines and skip_count are visible in the output. Cheap hardening exists: the outer run sets the guard to a per-run nonce and the inner guard compares equality, so an inherited stale value cannot match.",
      "proposed_action": "Nonce the recursion guard so an inherited value cannot satisfy it.",
      "fix_cost": "low",
      "feature_value": "incidental",
      "adjacent_to_blocking": false,
      "id": "F-PO-43-6-4"
    },
    {
      "category": "in-scope-deferrable",
      "severity": "low",
      "summary": "[code CR-51] CR-40's fixture fallback keys on existence only, so a present-but-malformed real journal reds the required suite instead of falling back.",
      "reasoning": "Measured: scratch copy with the real journal replaced by garbage, scenario_cr1 FAILs and the suite exits 1, with no fixture fallback. The failure is loud and its diagnostic is correct, and only this feature's own local .devwork file can produce the state, so the blast radius is one machine. But CR-40's whole point was that a required Verification command must not red on a state the developer did not cause.",
      "proposed_action": "Fall back when the real journal is unusable, not only when it is absent.",
      "fix_cost": "low",
      "feature_value": "incidental",
      "adjacent_to_blocking": false,
      "id": "F-PO-43-6-5"
    },
    {
      "category": "in-scope-deferrable",
      "severity": "low",
      "summary": "[code CR-52] CR-38's correction pattern cites journal-template.md as the shape authority, but journal-template.md defines no correction shape.",
      "reasoning": "§6 now names 'a new DISCOVERY entry (journal-template.md)' as the supersession pattern, but journal-template.md has no corrects: field and no mention of corrections at all — grepped and confirmed. The reference run improvised a corrects: key twice. So the contract points at a shape authority that does not carry the shape. Second drift of the same rule: the CR-38 fix landed in the contract and stopped at the document it cites.",
      "proposed_action": "Define the correction entry's shape in journal-template.md, including the corrects: field the run improvised.",
      "fix_cost": "low",
      "feature_value": "core",
      "adjacent_to_blocking": true,
      "id": "F-PO-43-6-6"
    },
    {
      "category": "in-scope-deferrable",
      "severity": "low",
      "summary": "[code CR-53] journal-template's claims:/overran_resources: shapes show only the four suite classes and never say project-named keys are permitted, while §2 and §4 depend on them.",
      "reasoning": "Measured consequences from this round's own record: T4 misfiled a shared scratch path under external because no other box existed, and F2 minted git_object_store on the spot; the sweep then did the same in its own disclosure. The improvised-key route does work through the §4 filter — verified — so the mechanism is right and only the record shape is silent. This is CR-35's record-shape side, unfixed when CR-35 fixed the duty sentence.",
      "proposed_action": "State in journal-template.md that project-named keys are permitted alongside the four, and show one.",
      "fix_cost": "low",
      "feature_value": "core",
      "adjacent_to_blocking": true,
      "id": "F-PO-43-6-7"
    },
    {
      "category": "in-scope-deferrable",
      "severity": "low",
      "summary": "[code CR-54] scenario_cr23's root-environment SKIP returns 1, so a required Verification command fails outright on any box where chmod 000 does not block reads.",
      "reasoning": "The skip guard added for the mode-000 case reports loudly but returns non-zero, failing the whole suite rather than reporting the check undetermined. Plausible on root boxes, including the devcontainers of #61. It also leaves two skip semantics in one repo: test-lint-conventions.sh's skip() returns 0, this one returns 1. Loud-but-red is defensible on its own terms; the inconsistency is not, and it is the CR-40 class — a required command red on a state the developer did not cause.",
      "proposed_action": "Make the undetermined case return 0 with a loud skip, consistent with the sibling harness.",
      "fix_cost": "low",
      "feature_value": "core",
      "adjacent_to_blocking": true,
      "id": "F-PO-43-6-8"
    },
    {
      "category": "in-scope-deferrable",
      "severity": "low",
      "summary": "[code CR-55] A malformed workers value gets verdict 'budget' rather than 'unknown', routing garbage to the sum test instead of to §1's malformed-means-serialize.",
      "reasoning": "Measured: workers:[4] on both sides returns verdict 'budget'. The workers branch is tested before the element-type check CR-41 added, so a non-scalar workers value never reaches the malformed path. Same §4 verdict vocabulary as CR-47 and the same ordering hazard CR-41 fixed one class over.",
      "proposed_action": "Test the workers value's shape before assigning the budget verdict.",
      "fix_cost": "low",
      "feature_value": "core",
      "adjacent_to_blocking": true,
      "id": "F-PO-43-6-9"
    }
  ],
  "pending_decisions": [
    {
      "id": "D-PO-43-6-1",
      "type": "scope-disposition",
      "blocking": false,
      "question": "[CR-48] CR-35's widened disclosure duty never reached either consumer's paraphrase — the two documents that tell the driver to put the duty in the brief. — fix now, spawn a follow-up issue, or accept?",
      "options": [
        "fix-now",
        "defer-to-issue",
        "accept"
      ],
      "recommended": "defer-to-issue",
      "finding_ref": "F-PO-43-6-2",
      "reasoning": "Computed by disposition-recommend.sh from the finding's axes. Full evidence in the sweep qa-report:v1 (domain=code, phase=validate) and code-journal.md."
    },
    {
      "id": "D-PO-43-6-2",
      "type": "scope-disposition",
      "blocking": false,
      "question": "[CR-49] §7's runnable output cannot be attributed to actors — 10 anonymous claim lines, 9 byte-identical, with the actor and timestamp keys deleted by its own trap. — fix now, spawn a follow-up issue, or accept?",
      "options": [
        "fix-now",
        "defer-to-issue",
        "accept"
      ],
      "recommended": "defer-to-issue",
      "finding_ref": "F-PO-43-6-3",
      "reasoning": "Computed by disposition-recommend.sh from the finding's axes. Full evidence in the sweep qa-report:v1 (domain=code, phase=validate) and code-journal.md."
    },
    {
      "id": "D-PO-43-6-3",
      "type": "scope-disposition",
      "blocking": false,
      "question": "[CR-50] An exported RRC_INNER_RUN makes an outer run silently pass three guarded scenarios — a measured false-green vector with an exotic precondition. — fix now, spawn a follow-up issue, or accept?",
      "options": [
        "fix-now",
        "defer-to-issue",
        "accept"
      ],
      "recommended": "defer-to-issue",
      "finding_ref": "F-PO-43-6-4",
      "reasoning": "Computed by disposition-recommend.sh from the finding's axes. Full evidence in the sweep qa-report:v1 (domain=code, phase=validate) and code-journal.md."
    },
    {
      "id": "D-PO-43-6-4",
      "type": "scope-disposition",
      "blocking": false,
      "question": "[CR-51] CR-40's fixture fallback keys on existence only, so a present-but-malformed real journal reds the required suite instead of falling back. — fix now, spawn a follow-up issue, or accept?",
      "options": [
        "fix-now",
        "defer-to-issue",
        "accept"
      ],
      "recommended": "defer-to-issue",
      "finding_ref": "F-PO-43-6-5",
      "reasoning": "Computed by disposition-recommend.sh from the finding's axes. Full evidence in the sweep qa-report:v1 (domain=code, phase=validate) and code-journal.md."
    },
    {
      "id": "D-PO-43-6-5",
      "type": "scope-disposition",
      "blocking": false,
      "question": "[CR-52] CR-38's correction pattern cites journal-template.md as the shape authority, but journal-template.md defines no correction shape. — fix now, spawn a follow-up issue, or accept?",
      "options": [
        "fix-now",
        "defer-to-issue",
        "accept"
      ],
      "recommended": "defer-to-issue",
      "finding_ref": "F-PO-43-6-6",
      "reasoning": "Computed by disposition-recommend.sh from the finding's axes. Full evidence in the sweep qa-report:v1 (domain=code, phase=validate) and code-journal.md."
    },
    {
      "id": "D-PO-43-6-6",
      "type": "scope-disposition",
      "blocking": false,
      "question": "[CR-53] journal-template's claims:/overran_resources: shapes show only the four suite classes and never say project-named keys are permitted, while §2 and §4 depend on them. — fix now, spawn a follow-up issue, or accept?",
      "options": [
        "fix-now",
        "defer-to-issue",
        "accept"
      ],
      "recommended": "defer-to-issue",
      "finding_ref": "F-PO-43-6-7",
      "reasoning": "Computed by disposition-recommend.sh from the finding's axes. Full evidence in the sweep qa-report:v1 (domain=code, phase=validate) and code-journal.md."
    },
    {
      "id": "D-PO-43-6-7",
      "type": "scope-disposition",
      "blocking": false,
      "question": "[CR-54] scenario_cr23's root-environment SKIP returns 1, so a required Verification command fails outright on any box where chmod 000 does not block reads. — fix now, spawn a follow-up issue, or accept?",
      "options": [
        "fix-now",
        "defer-to-issue",
        "accept"
      ],
      "recommended": "defer-to-issue",
      "finding_ref": "F-PO-43-6-8",
      "reasoning": "Computed by disposition-recommend.sh from the finding's axes. Full evidence in the sweep qa-report:v1 (domain=code, phase=validate) and code-journal.md."
    },
    {
      "id": "D-PO-43-6-8",
      "type": "scope-disposition",
      "blocking": false,
      "question": "[CR-55] A malformed workers value gets verdict 'budget' rather than 'unknown', routing garbage to the sum test instead of to §1's malformed-means-serialize. — fix now, spawn a follow-up issue, or accept?",
      "options": [
        "fix-now",
        "defer-to-issue",
        "accept"
      ],
      "recommended": "defer-to-issue",
      "finding_ref": "F-PO-43-6-9",
      "reasoning": "Computed by disposition-recommend.sh from the finding's axes. Full evidence in the sweep qa-report:v1 (domain=code, phase=validate) and code-journal.md."
    }
  ],
  "suite": {
    "source": "git",
    "sha": "8346f0f2f549c1f555d8c180a3e3f7f73cc1d2d2",
    "dirty": false
  }
}

```json { "next_state": "qa", "produced": [ { "kind": "qa-report", "ref": "2009", "summary": "code phase=fix — 14 findings fixed, all 4 gates green" }, { "kind": "qa-report", "ref": "latest", "summary": "code phase=validate — sweep 2, 9 findings, 1 High blocking" }, { "kind": "code-bundle", "ref": "8346f0f", "summary": "the swept HEAD: fix commit 8346f0f on test_commit 570afaa" } ], "findings": [ { "category": "in-scope-blocking", "severity": "high", "summary": "[code CR-47] §7 step 4 speaks a two-outcome vocabulary that its own §4 test no longer emits — and both real overrun shapes fall to the permissive branch.", "reasoning": "Step 4 decides sole ownership by intersecting overran_resources against every other intersecting actor's claims '(same §4 test)', then reads the result in exactly two outcomes: 'nothing shared there means sole ownership (recorded, not voided); anything shared ... means void'. But §4 emits four verdicts — shared, unknown, budget, []. Driver ran the SHIPPED filter on the reference run's own overrun shapes. (a) A workers overrun, {workers:3} against a peer claim of workers:1, returns verdict 'budget' and zero 'shared' entries, so step 4 reads it as sole ownership and RECORDS it — meaning a worker-budget overrun can never void, on the very contention the contract was written for; 3 of this round's 4 real overruns were workers. (b) An overrun onto a class the peer never claimed — the typical scratch-surface case, F2's improvised git_object_store — returns all-unknown and again zero 'shared', so step 4 silently converts UNJUDGEABLE into DISJOINT. That is the one-output-two-answers inversion §4's own bold rule forbids, one section down, in the section this round has now repaired four times. Control confirms step 4 works for the case it was written against: an overrun onto a genuinely co-claimed database returns 'shared' and voids. This is CR-32/CR-46's shape a third time: a verdict was added to §4 and never reached the consumer that reads it.", "proposed_action": "Give step 4 a branch per verdict: 'budget' sums the overrun against the peer's claimed workers and the pool, 'unknown' routes to a remedy (never to 'recorded'), 'shared' voids as now.", "fix_cost": "low", "feature_value": "core", "adjacent_to_blocking": true, "id": "F-PO-43-6-1" }, { "category": "in-scope-deferrable", "severity": "medium", "summary": "[code CR-48] CR-35's widened disclosure duty never reached either consumer's paraphrase — the two documents that tell the driver to put the duty in the brief.", "reasoning": "qa-playbook.md:58 and develop/SKILL.md:116 both still read 'a database, port, worker budget or external resource its claim did not name' — the pre-widening four-class list — and both instruct the driver to spell the duty out in the brief the actor actually reads. Contract §5 now includes shared writable scratch/cache surfaces and any shared artefact one actor writes while another reads or executes it. Confirmed by direct grep at 8346f0f: the fix commit touched neither sentence. An actor briefed from these texts repeats T1's round-1 miss verbatim — recording overran_claim: false for a shared scratch path, correctly under the text it was given. Second drift of the same rule: CR-35 fixed §5 itself and stopped there.", "proposed_action": "Widen both paraphrases to defer to §2's vocabulary rather than re-enumerating it.", "fix_cost": "low", "feature_value": "core", "adjacent_to_blocking": true, "id": "F-PO-43-6-2" }, { "category": "in-scope-deferrable", "severity": "medium", "summary": "[code CR-49] §7's runnable output cannot be attributed to actors — 10 anonymous claim lines, 9 byte-identical, with the actor and timestamp keys deleted by its own trap.", "reasoning": "Driver-authorised sweep ran the shipped recipe verbatim against the real journal: it prints claims JSON only, no actor names or windows, and the trap removes $SCAN which held the actor:/timestamp: lines needed to pair claim to actor to window. To feed any pair into §4 — which is what steps 3 and 4 then ask for — the reader must redo the extraction from the journal by hand. A gap with a workaround, but it is exactly the manual re-derivation that 'answer it from the record' exists to remove.", "proposed_action": "Emit actor and window alongside each claim, or keep the scan available to the steps that need it.", "fix_cost": "medium", "feature_value": "core", "adjacent_to_blocking": false, "id": "F-PO-43-6-3" }, { "category": "in-scope-deferrable", "severity": "low", "summary": "[code CR-50] An exported RRC_INNER_RUN makes an outer run silently pass three guarded scenarios — a measured false-green vector with an exotic precondition.", "reasoning": "The residual the fix stage carried forward, now measured in both halves on scratch copies. (1) RRC_INNER_RUN=1 exported into an OUTER run: three SKIP (LOUD) lines, then PASS for all three guarded scenarios, suite rc=0, skip_count=3. (2) The same leak plus the CR-4 defect re-introduced: rc=0 — a false green; the identical masked tree in a clean environment reds, both cr4 scenarios FAIL, rc=1. Judged Low because it needs the operator or CI to export the variable, and the SKIP lines and skip_count are visible in the output. Cheap hardening exists: the outer run sets the guard to a per-run nonce and the inner guard compares equality, so an inherited stale value cannot match.", "proposed_action": "Nonce the recursion guard so an inherited value cannot satisfy it.", "fix_cost": "low", "feature_value": "incidental", "adjacent_to_blocking": false, "id": "F-PO-43-6-4" }, { "category": "in-scope-deferrable", "severity": "low", "summary": "[code CR-51] CR-40's fixture fallback keys on existence only, so a present-but-malformed real journal reds the required suite instead of falling back.", "reasoning": "Measured: scratch copy with the real journal replaced by garbage, scenario_cr1 FAILs and the suite exits 1, with no fixture fallback. The failure is loud and its diagnostic is correct, and only this feature's own local .devwork file can produce the state, so the blast radius is one machine. But CR-40's whole point was that a required Verification command must not red on a state the developer did not cause.", "proposed_action": "Fall back when the real journal is unusable, not only when it is absent.", "fix_cost": "low", "feature_value": "incidental", "adjacent_to_blocking": false, "id": "F-PO-43-6-5" }, { "category": "in-scope-deferrable", "severity": "low", "summary": "[code CR-52] CR-38's correction pattern cites journal-template.md as the shape authority, but journal-template.md defines no correction shape.", "reasoning": "§6 now names 'a new DISCOVERY entry (journal-template.md)' as the supersession pattern, but journal-template.md has no corrects: field and no mention of corrections at all — grepped and confirmed. The reference run improvised a corrects: key twice. So the contract points at a shape authority that does not carry the shape. Second drift of the same rule: the CR-38 fix landed in the contract and stopped at the document it cites.", "proposed_action": "Define the correction entry's shape in journal-template.md, including the corrects: field the run improvised.", "fix_cost": "low", "feature_value": "core", "adjacent_to_blocking": true, "id": "F-PO-43-6-6" }, { "category": "in-scope-deferrable", "severity": "low", "summary": "[code CR-53] journal-template's claims:/overran_resources: shapes show only the four suite classes and never say project-named keys are permitted, while §2 and §4 depend on them.", "reasoning": "Measured consequences from this round's own record: T4 misfiled a shared scratch path under external because no other box existed, and F2 minted git_object_store on the spot; the sweep then did the same in its own disclosure. The improvised-key route does work through the §4 filter — verified — so the mechanism is right and only the record shape is silent. This is CR-35's record-shape side, unfixed when CR-35 fixed the duty sentence.", "proposed_action": "State in journal-template.md that project-named keys are permitted alongside the four, and show one.", "fix_cost": "low", "feature_value": "core", "adjacent_to_blocking": true, "id": "F-PO-43-6-7" }, { "category": "in-scope-deferrable", "severity": "low", "summary": "[code CR-54] scenario_cr23's root-environment SKIP returns 1, so a required Verification command fails outright on any box where chmod 000 does not block reads.", "reasoning": "The skip guard added for the mode-000 case reports loudly but returns non-zero, failing the whole suite rather than reporting the check undetermined. Plausible on root boxes, including the devcontainers of #61. It also leaves two skip semantics in one repo: test-lint-conventions.sh's skip() returns 0, this one returns 1. Loud-but-red is defensible on its own terms; the inconsistency is not, and it is the CR-40 class — a required command red on a state the developer did not cause.", "proposed_action": "Make the undetermined case return 0 with a loud skip, consistent with the sibling harness.", "fix_cost": "low", "feature_value": "core", "adjacent_to_blocking": true, "id": "F-PO-43-6-8" }, { "category": "in-scope-deferrable", "severity": "low", "summary": "[code CR-55] A malformed workers value gets verdict 'budget' rather than 'unknown', routing garbage to the sum test instead of to §1's malformed-means-serialize.", "reasoning": "Measured: workers:[4] on both sides returns verdict 'budget'. The workers branch is tested before the element-type check CR-41 added, so a non-scalar workers value never reaches the malformed path. Same §4 verdict vocabulary as CR-47 and the same ordering hazard CR-41 fixed one class over.", "proposed_action": "Test the workers value's shape before assigning the budget verdict.", "fix_cost": "low", "feature_value": "core", "adjacent_to_blocking": true, "id": "F-PO-43-6-9" } ], "pending_decisions": [ { "id": "D-PO-43-6-1", "type": "scope-disposition", "blocking": false, "question": "[CR-48] CR-35's widened disclosure duty never reached either consumer's paraphrase — the two documents that tell the driver to put the duty in the brief. — fix now, spawn a follow-up issue, or accept?", "options": [ "fix-now", "defer-to-issue", "accept" ], "recommended": "defer-to-issue", "finding_ref": "F-PO-43-6-2", "reasoning": "Computed by disposition-recommend.sh from the finding's axes. Full evidence in the sweep qa-report:v1 (domain=code, phase=validate) and code-journal.md." }, { "id": "D-PO-43-6-2", "type": "scope-disposition", "blocking": false, "question": "[CR-49] §7's runnable output cannot be attributed to actors — 10 anonymous claim lines, 9 byte-identical, with the actor and timestamp keys deleted by its own trap. — fix now, spawn a follow-up issue, or accept?", "options": [ "fix-now", "defer-to-issue", "accept" ], "recommended": "defer-to-issue", "finding_ref": "F-PO-43-6-3", "reasoning": "Computed by disposition-recommend.sh from the finding's axes. Full evidence in the sweep qa-report:v1 (domain=code, phase=validate) and code-journal.md." }, { "id": "D-PO-43-6-3", "type": "scope-disposition", "blocking": false, "question": "[CR-50] An exported RRC_INNER_RUN makes an outer run silently pass three guarded scenarios — a measured false-green vector with an exotic precondition. — fix now, spawn a follow-up issue, or accept?", "options": [ "fix-now", "defer-to-issue", "accept" ], "recommended": "defer-to-issue", "finding_ref": "F-PO-43-6-4", "reasoning": "Computed by disposition-recommend.sh from the finding's axes. Full evidence in the sweep qa-report:v1 (domain=code, phase=validate) and code-journal.md." }, { "id": "D-PO-43-6-4", "type": "scope-disposition", "blocking": false, "question": "[CR-51] CR-40's fixture fallback keys on existence only, so a present-but-malformed real journal reds the required suite instead of falling back. — fix now, spawn a follow-up issue, or accept?", "options": [ "fix-now", "defer-to-issue", "accept" ], "recommended": "defer-to-issue", "finding_ref": "F-PO-43-6-5", "reasoning": "Computed by disposition-recommend.sh from the finding's axes. Full evidence in the sweep qa-report:v1 (domain=code, phase=validate) and code-journal.md." }, { "id": "D-PO-43-6-5", "type": "scope-disposition", "blocking": false, "question": "[CR-52] CR-38's correction pattern cites journal-template.md as the shape authority, but journal-template.md defines no correction shape. — fix now, spawn a follow-up issue, or accept?", "options": [ "fix-now", "defer-to-issue", "accept" ], "recommended": "defer-to-issue", "finding_ref": "F-PO-43-6-6", "reasoning": "Computed by disposition-recommend.sh from the finding's axes. Full evidence in the sweep qa-report:v1 (domain=code, phase=validate) and code-journal.md." }, { "id": "D-PO-43-6-6", "type": "scope-disposition", "blocking": false, "question": "[CR-53] journal-template's claims:/overran_resources: shapes show only the four suite classes and never say project-named keys are permitted, while §2 and §4 depend on them. — fix now, spawn a follow-up issue, or accept?", "options": [ "fix-now", "defer-to-issue", "accept" ], "recommended": "defer-to-issue", "finding_ref": "F-PO-43-6-7", "reasoning": "Computed by disposition-recommend.sh from the finding's axes. Full evidence in the sweep qa-report:v1 (domain=code, phase=validate) and code-journal.md." }, { "id": "D-PO-43-6-7", "type": "scope-disposition", "blocking": false, "question": "[CR-54] scenario_cr23's root-environment SKIP returns 1, so a required Verification command fails outright on any box where chmod 000 does not block reads. — fix now, spawn a follow-up issue, or accept?", "options": [ "fix-now", "defer-to-issue", "accept" ], "recommended": "defer-to-issue", "finding_ref": "F-PO-43-6-8", "reasoning": "Computed by disposition-recommend.sh from the finding's axes. Full evidence in the sweep qa-report:v1 (domain=code, phase=validate) and code-journal.md." }, { "id": "D-PO-43-6-8", "type": "scope-disposition", "blocking": false, "question": "[CR-55] A malformed workers value gets verdict 'budget' rather than 'unknown', routing garbage to the sum test instead of to §1's malformed-means-serialize. — fix now, spawn a follow-up issue, or accept?", "options": [ "fix-now", "defer-to-issue", "accept" ], "recommended": "defer-to-issue", "finding_ref": "F-PO-43-6-9", "reasoning": "Computed by disposition-recommend.sh from the finding's axes. Full evidence in the sweep qa-report:v1 (domain=code, phase=validate) and code-journal.md." } ], "suite": { "source": "git", "sha": "8346f0f2f549c1f555d8c180a3e3f7f73cc1d2d2", "dirty": false } } ```

jbr870 commented

2026-08-26 14:59:44 +00:00

Author

Owner

{
  "status": "resolved",
  "chosen_option": "fix-now",
  "rationale": "[CR-48] OVERRIDES the recommender, deliberately and as part of a framed round. Taken alone this is a Medium text drift and defer is the right call; taken as one of five instances of a class that has now escaped two patch rounds, deferring it is the third pass of exactly the shape fix-workflow section 2 forbids. Round 3 takes that rule's OTHER exit — a round framed at the class — and this finding is the class's clearest case: the two documents that tell the driver to put the disclosure duty in a brief both still enumerate the pre-CR-35 four classes, so the widened rule reaches no actor who is briefed from them. The fix is to make each consumer defer to section 2's vocabulary rather than re-enumerate it, which is the structural repair, not another patch. Resolved by the driver under the operator's standing authority to run the QA phase to completion, stopping only on a blocking decision. Where this resolution differs from disposition-recommend.sh's answer it says so explicitly and gives the reason; the recommender scores each finding in isolation and cannot see that five of these are one recurring class.",
  "rejected_alternative": "defer-to-issue was the recommender's answer and would be correct for an isolated instance. Turned down because the round is already reopening both files for CR-47, and because a rule that has drifted twice will drift a third time unless the consumers stop restating it."
}

```json { "status": "resolved", "chosen_option": "fix-now", "rationale": "[CR-48] OVERRIDES the recommender, deliberately and as part of a framed round. Taken alone this is a Medium text drift and defer is the right call; taken as one of five instances of a class that has now escaped two patch rounds, deferring it is the third pass of exactly the shape fix-workflow section 2 forbids. Round 3 takes that rule's OTHER exit — a round framed at the class — and this finding is the class's clearest case: the two documents that tell the driver to put the disclosure duty in a brief both still enumerate the pre-CR-35 four classes, so the widened rule reaches no actor who is briefed from them. The fix is to make each consumer defer to section 2's vocabulary rather than re-enumerate it, which is the structural repair, not another patch. Resolved by the driver under the operator's standing authority to run the QA phase to completion, stopping only on a blocking decision. Where this resolution differs from disposition-recommend.sh's answer it says so explicitly and gives the reason; the recommender scores each finding in isolation and cannot see that five of these are one recurring class.", "rejected_alternative": "defer-to-issue was the recommender's answer and would be correct for an isolated instance. Turned down because the round is already reopening both files for CR-47, and because a rule that has drifted twice will drift a third time unless the consumers stop restating it." } ```

jbr870 commented

2026-08-26 14:59:44 +00:00

Author

Owner

{
  "status": "resolved",
  "chosen_option": "defer-to-issue",
  "rationale": "[CR-49] Real design work, not a text repair: making section 7's output attributable means deciding what the recipe emits and what survives its own trap, which is a change to the contract's interface rather than to its wording. The recommender is right and the framed round does not reach it — this is not a rule and its mechanism drifting apart, it is a capability the recipe never had. Deferring keeps round 3 what it is: one class, closed properly. Resolved by the driver under the operator's standing authority to run the QA phase to completion, stopping only on a blocking decision. Where this resolution differs from disposition-recommend.sh's answer it says so explicitly and gives the reason; the recommender scores each finding in isolation and cannot see that five of these are one recurring class.",
  "rejected_alternative": "fix-now was weighed because the finding is Medium and sits in section 7, which round 3 is opening anyway for CR-47. Turned down because the two changes are unrelated in kind, and bundling a design change into a class-framed repair is how the class got here."
}

```json { "status": "resolved", "chosen_option": "defer-to-issue", "rationale": "[CR-49] Real design work, not a text repair: making section 7's output attributable means deciding what the recipe emits and what survives its own trap, which is a change to the contract's interface rather than to its wording. The recommender is right and the framed round does not reach it — this is not a rule and its mechanism drifting apart, it is a capability the recipe never had. Deferring keeps round 3 what it is: one class, closed properly. Resolved by the driver under the operator's standing authority to run the QA phase to completion, stopping only on a blocking decision. Where this resolution differs from disposition-recommend.sh's answer it says so explicitly and gives the reason; the recommender scores each finding in isolation and cannot see that five of these are one recurring class.", "rejected_alternative": "fix-now was weighed because the finding is Medium and sits in section 7, which round 3 is opening anyway for CR-47. Turned down because the two changes are unrelated in kind, and bundling a design change into a class-framed repair is how the class got here." } ```

jbr870 commented

Author

Owner

{
  "status": "resolved",
  "chosen_option": "defer-to-issue",
  "rationale": "[CR-50] The precondition is an exported RRC_INNER_RUN, which requires the operator or CI to set it, and the failure is visible as three loud SKIP lines and a non-zero skip_count. The measured false green is real and worth recording, but the nonce hardening is a change to the harness's guard protocol and belongs with the other harness-protocol question already deferred, not inside a documentation-class round. Resolved by the driver under the operator's standing authority to run the QA phase to completion, stopping only on a blocking decision. Where this resolution differs from disposition-recommend.sh's answer it says so explicitly and gives the reason; the recommender scores each finding in isolation and cannot see that five of these are one recurring class.",
  "rejected_alternative": "fix-now had a genuine case: it is a MEASURED false green, and this round's whole thesis is that false greens are the defect class that matters. Turned down on precondition — every other false green this round fired in a clean environment with no special setup, and this one cannot."
}

```json { "status": "resolved", "chosen_option": "defer-to-issue", "rationale": "[CR-50] The precondition is an exported RRC_INNER_RUN, which requires the operator or CI to set it, and the failure is visible as three loud SKIP lines and a non-zero skip_count. The measured false green is real and worth recording, but the nonce hardening is a change to the harness's guard protocol and belongs with the other harness-protocol question already deferred, not inside a documentation-class round. Resolved by the driver under the operator's standing authority to run the QA phase to completion, stopping only on a blocking decision. Where this resolution differs from disposition-recommend.sh's answer it says so explicitly and gives the reason; the recommender scores each finding in isolation and cannot see that five of these are one recurring class.", "rejected_alternative": "fix-now had a genuine case: it is a MEASURED false green, and this round's whole thesis is that false greens are the defect class that matters. Turned down on precondition — every other false green this round fired in a clean environment with no special setup, and this one cannot." } ```

jbr870 commented

Author

Owner

{
  "status": "resolved",
  "chosen_option": "defer-to-issue",
  "rationale": "[CR-51] Blast radius is one machine's own .devwork file, in a state no developer produces by accident, and the failure is loud with a correct diagnostic. CR-40's requirement — that a required Verification command not red on a state the developer did not cause — is satisfied for the case that actually occurs, which is absence. Resolved by the driver under the operator's standing authority to run the QA phase to completion, stopping only on a blocking decision. Where this resolution differs from disposition-recommend.sh's answer it says so explicitly and gives the reason; the recommender scores each finding in isolation and cannot see that five of these are one recurring class.",
  "rejected_alternative": "fix-now was arguable because it is the CR-40 class and the fix is small. Turned down because a malformed local journal is a state worth failing on: falling back silently there would hide a corrupted run record, which is worse than a loud red."
}

```json { "status": "resolved", "chosen_option": "defer-to-issue", "rationale": "[CR-51] Blast radius is one machine's own .devwork file, in a state no developer produces by accident, and the failure is loud with a correct diagnostic. CR-40's requirement — that a required Verification command not red on a state the developer did not cause — is satisfied for the case that actually occurs, which is absence. Resolved by the driver under the operator's standing authority to run the QA phase to completion, stopping only on a blocking decision. Where this resolution differs from disposition-recommend.sh's answer it says so explicitly and gives the reason; the recommender scores each finding in isolation and cannot see that five of these are one recurring class.", "rejected_alternative": "fix-now was arguable because it is the CR-40 class and the fix is small. Turned down because a malformed local journal is a state worth failing on: falling back silently there would hide a corrupted run record, which is worse than a loud red." } ```

jbr870 commented

Author

Owner

{
  "status": "resolved",
  "chosen_option": "fix-now",
  "rationale": "[CR-52] OVERRIDES the recommender as part of the framed round. The contract now names a correction pattern and cites journal-template.md as its shape authority, and that document defines no correction shape at all — so the citation points at nothing and the reference run improvised the corrects: key twice. This is the CR-38 rule's second drift, in the same relationship as CR-48: the rule was fixed where the finding pointed and stopped at the document it names. Low severity, but the class is the point, and the fix is to define the shape where the contract already says it lives. Resolved by the driver under the operator's standing authority to run the QA phase to completion, stopping only on a blocking decision. Where this resolution differs from disposition-recommend.sh's answer it says so explicitly and gives the reason; the recommender scores each finding in isolation and cannot see that five of these are one recurring class.",
  "rejected_alternative": "defer-to-issue is defensible on severity alone. Turned down because deferring a Low that is structurally identical to the Medium being fixed in the same sitting splits one repair across two rounds, and the second half is the half that gets forgotten."
}

```json { "status": "resolved", "chosen_option": "fix-now", "rationale": "[CR-52] OVERRIDES the recommender as part of the framed round. The contract now names a correction pattern and cites journal-template.md as its shape authority, and that document defines no correction shape at all — so the citation points at nothing and the reference run improvised the corrects: key twice. This is the CR-38 rule's second drift, in the same relationship as CR-48: the rule was fixed where the finding pointed and stopped at the document it names. Low severity, but the class is the point, and the fix is to define the shape where the contract already says it lives. Resolved by the driver under the operator's standing authority to run the QA phase to completion, stopping only on a blocking decision. Where this resolution differs from disposition-recommend.sh's answer it says so explicitly and gives the reason; the recommender scores each finding in isolation and cannot see that five of these are one recurring class.", "rejected_alternative": "defer-to-issue is defensible on severity alone. Turned down because deferring a Low that is structurally identical to the Medium being fixed in the same sitting splits one repair across two rounds, and the second half is the half that gets forgotten." } ```

jbr870 commented

Author

Owner

{
  "status": "resolved",
  "chosen_option": "fix-now",
  "rationale": "[CR-53] OVERRIDES the recommender as part of the framed round. Three separate actors this round hit the same wall — T4 misfiled a scratch path under external, F2 minted git_object_store, the sweep did the same in its own disclosure — because the record shape shows only four classes and never says project-named keys are allowed, while the mechanism accepts them and was verified to work. This is CR-35's record-shape side, left behind when CR-35 fixed the duty sentence. Three measured instances in one round is not a Low in any sense that matters for deferral. Resolved by the driver under the operator's standing authority to run the QA phase to completion, stopping only on a blocking decision. Where this resolution differs from disposition-recommend.sh's answer it says so explicitly and gives the reason; the recommender scores each finding in isolation and cannot see that five of these are one recurring class.",
  "rejected_alternative": "defer-to-issue matches the severity label. Turned down because the severity label understates it: the finding is Low only in the sense that the improvised workaround happens to function, and the round has three instances of actors improvising it independently."
}

```json { "status": "resolved", "chosen_option": "fix-now", "rationale": "[CR-53] OVERRIDES the recommender as part of the framed round. Three separate actors this round hit the same wall — T4 misfiled a scratch path under external, F2 minted git_object_store, the sweep did the same in its own disclosure — because the record shape shows only four classes and never says project-named keys are allowed, while the mechanism accepts them and was verified to work. This is CR-35's record-shape side, left behind when CR-35 fixed the duty sentence. Three measured instances in one round is not a Low in any sense that matters for deferral. Resolved by the driver under the operator's standing authority to run the QA phase to completion, stopping only on a blocking decision. Where this resolution differs from disposition-recommend.sh's answer it says so explicitly and gives the reason; the recommender scores each finding in isolation and cannot see that five of these are one recurring class.", "rejected_alternative": "defer-to-issue matches the severity label. Turned down because the severity label understates it: the finding is Low only in the sense that the improvised workaround happens to function, and the round has three instances of actors improvising it independently." } ```

jbr870 commented

2026-08-26 14:59:46 +00:00

Author

Owner

{
  "status": "resolved",
  "chosen_option": "fix-now",
  "rationale": "[CR-54] OVERRIDES the recommender. One line, and it is the CR-40 class the round has already accepted as worth fixing: a required Verification command that fails outright on an environment the developer did not choose. Root is not hypothetical here — the devcontainers of issue 61 are the immediate case. It also leaves two contradictory skip semantics in one repo, which is precisely the drift shape round 3 is framed at, expressed in shell rather than prose. Resolved by the driver under the operator's standing authority to run the QA phase to completion, stopping only on a blocking decision. Where this resolution differs from disposition-recommend.sh's answer it says so explicitly and gives the reason; the recommender scores each finding in isolation and cannot see that five of these are one recurring class.",
  "rejected_alternative": "accept was considered on the argument that loud-but-red is a defensible reading of an undetermined check. Turned down because the sibling harness already chose the other reading, and an inconsistency between two harnesses in the same repo is the thing that makes a future reader pick wrong."
}

```json { "status": "resolved", "chosen_option": "fix-now", "rationale": "[CR-54] OVERRIDES the recommender. One line, and it is the CR-40 class the round has already accepted as worth fixing: a required Verification command that fails outright on an environment the developer did not choose. Root is not hypothetical here — the devcontainers of issue 61 are the immediate case. It also leaves two contradictory skip semantics in one repo, which is precisely the drift shape round 3 is framed at, expressed in shell rather than prose. Resolved by the driver under the operator's standing authority to run the QA phase to completion, stopping only on a blocking decision. Where this resolution differs from disposition-recommend.sh's answer it says so explicitly and gives the reason; the recommender scores each finding in isolation and cannot see that five of these are one recurring class.", "rejected_alternative": "accept was considered on the argument that loud-but-red is a defensible reading of an undetermined check. Turned down because the sibling harness already chose the other reading, and an inconsistency between two harnesses in the same repo is the thing that makes a future reader pick wrong." } ```

jbr870 commented

Author

Owner

{
  "status": "resolved",
  "chosen_option": "fix-now",
  "rationale": "[CR-55] OVERRIDES the recommender. Same section 4 verdict vocabulary as the blocking CR-47 and the same ordering hazard CR-41 fixed one class over: the workers branch is tested before the element-type check, so a malformed workers value is routed to the sum test instead of to section 1's malformed-means-serialize. The fixer will be inside this exact jq program for CR-47; fixing the branch order there and not here would be the drift the round exists to stop. Resolved by the driver under the operator's standing authority to run the QA phase to completion, stopping only on a blocking decision. Where this resolution differs from disposition-recommend.sh's answer it says so explicitly and gives the reason; the recommender scores each finding in isolation and cannot see that five of these are one recurring class.",
  "rejected_alternative": "defer-to-issue matches the Low severity and the input does not occur in this repo today. Turned down on adjacency alone — it is the same expression, edited in the same sitting, and leaving it would mean re-opening the filter a third time."
}

```json { "status": "resolved", "chosen_option": "fix-now", "rationale": "[CR-55] OVERRIDES the recommender. Same section 4 verdict vocabulary as the blocking CR-47 and the same ordering hazard CR-41 fixed one class over: the workers branch is tested before the element-type check, so a malformed workers value is routed to the sum test instead of to section 1's malformed-means-serialize. The fixer will be inside this exact jq program for CR-47; fixing the branch order there and not here would be the drift the round exists to stop. Resolved by the driver under the operator's standing authority to run the QA phase to completion, stopping only on a blocking decision. Where this resolution differs from disposition-recommend.sh's answer it says so explicitly and gives the reason; the recommender scores each finding in isolation and cannot see that five of these are one recurring class.", "rejected_alternative": "defer-to-issue matches the Low severity and the input does not occur in this repo today. Turned down on adjacency alone — it is the same expression, edited in the same sitting, and leaving it would mean re-opening the filter a third time." } ```

jbr870 referenced this issue

2026-08-26 15:00:16 +00:00

run-resource-claims: three capability gaps the contract never had — §7 attribution, recursion-guard nonce, malformed-journal fallback #354

jbr870 commented

2026-08-26 15:00:17 +00:00

Author

Owner

Linked: this issue is sibling #354 (recorded by the devwork pipeline).

Linked: this issue is **sibling** #354 (recorded by the devwork pipeline).

jbr870 commented

2026-08-26 15:18:06 +00:00

Author

Owner

{
  "outcome": "clean",
  "summary": "Round 3 tests stage. 6 red scenarios for the 6 in-scope findings, all in scripts/test-run-resource-claims.sh. Written as AGREEMENT tests rather than wording tests, because round 3 is framed at a class whose fix rewrites the very prose a wording test would pin.",
  "findings": [],
  "artifacts": {
    "test_commit": "b691a4d4f02ae742c09cc7cc8fd80c70e90e4076",
    "test_files": [
      "scripts/test-run-resource-claims.sh"
    ],
    "test_marker": {
      "runner": "shell harness (bash) — scripts/test-*.sh",
      "write": "red_scenario \"<ID>\" <scenario_fn>   # <ID>: unfixed",
      "promote": "swap `red_scenario \"<ID>\" <fn>` for `run_scenario <fn>` — never a bare call"
    },
    "coverage": [
      "CR-47 (blocking)",
      "CR-48",
      "CR-52",
      "CR-53",
      "CR-54",
      "CR-55"
    ],
    "gates_at_test_commit": {
      "lint-conventions.sh": "clean",
      "test-lint-conventions.sh": "29 PASS / 0 FAIL / 0 RED",
      "test-run-resource-claims.sh": "35 PASS / 0 FAIL / 6 RED (expected) / 0 XPASS"
    }
  },
  "notes": {
    "framing": "Round 3 takes fix-workflow.md §2's FIRST convergence exit — a round explicitly framed at the class — because round 2 took the second (defer to #257) and the class escaped anyway, producing five more instances in one sweep. Scope is every rule that has now drifted TWICE. The fix is to make each consumer defer to its source rather than re-enumerate it, which is a structural repair rather than another patch.",
    "agreement_not_wording": "The scenarios assert that a consumer no longer enumerates a NARROWER set than its source, and that §7 step 4 disposes of the verdicts the shipped §4 filter actually returns. A test pinning the fix's phrasing would break on the correct fix and teach the next reader to weaken it — which is how this class survives.",
    "coupling_spot_verified": "The driver mutation-tested the two highest-risk scenarios rather than accepting the actor's green proofs. CR-54 because its observable is a RETURN CODE, which is precisely the CR-31 hazard: flipping scenario_cr23's root guard to return 0 in a scratch copy yields XPASS and suite rc=1. CR-47 because it blocks: rewriting step 4 to dispose of every verdict also yields XPASS and rc=1. The remaining four are document-agreement greps; an unearned promotion among them will be caught by the post-fix revert battery, which is how all ten of round 2's promotions were checked.",
    "cr54_technique": "Root could not be obtained, so the scenario puts a no-op chmod earlier in PATH and exports the real scenario function into a fresh bash — driving the genuine root-guard branch without root. Simulate the condition the guard checks, not the privilege. Worth reusing for environment-dependent tests.",
    "fixer_warning_from_the_actor": "The actor reported, unprompted, that a naive CR-55 type-guard does NOT incidentally satisfy CR-47's scenario — the two findings share the §4/§7 vocabulary but are genuinely separate edits."
  }
}

```json { "outcome": "clean", "summary": "Round 3 tests stage. 6 red scenarios for the 6 in-scope findings, all in scripts/test-run-resource-claims.sh. Written as AGREEMENT tests rather than wording tests, because round 3 is framed at a class whose fix rewrites the very prose a wording test would pin.", "findings": [], "artifacts": { "test_commit": "b691a4d4f02ae742c09cc7cc8fd80c70e90e4076", "test_files": [ "scripts/test-run-resource-claims.sh" ], "test_marker": { "runner": "shell harness (bash) — scripts/test-*.sh", "write": "red_scenario \"<ID>\" <scenario_fn> # <ID>: unfixed", "promote": "swap `red_scenario \"<ID>\" <fn>` for `run_scenario <fn>` — never a bare call" }, "coverage": [ "CR-47 (blocking)", "CR-48", "CR-52", "CR-53", "CR-54", "CR-55" ], "gates_at_test_commit": { "lint-conventions.sh": "clean", "test-lint-conventions.sh": "29 PASS / 0 FAIL / 0 RED", "test-run-resource-claims.sh": "35 PASS / 0 FAIL / 6 RED (expected) / 0 XPASS" } }, "notes": { "framing": "Round 3 takes fix-workflow.md §2's FIRST convergence exit — a round explicitly framed at the class — because round 2 took the second (defer to #257) and the class escaped anyway, producing five more instances in one sweep. Scope is every rule that has now drifted TWICE. The fix is to make each consumer defer to its source rather than re-enumerate it, which is a structural repair rather than another patch.", "agreement_not_wording": "The scenarios assert that a consumer no longer enumerates a NARROWER set than its source, and that §7 step 4 disposes of the verdicts the shipped §4 filter actually returns. A test pinning the fix's phrasing would break on the correct fix and teach the next reader to weaken it — which is how this class survives.", "coupling_spot_verified": "The driver mutation-tested the two highest-risk scenarios rather than accepting the actor's green proofs. CR-54 because its observable is a RETURN CODE, which is precisely the CR-31 hazard: flipping scenario_cr23's root guard to return 0 in a scratch copy yields XPASS and suite rc=1. CR-47 because it blocks: rewriting step 4 to dispose of every verdict also yields XPASS and rc=1. The remaining four are document-agreement greps; an unearned promotion among them will be caught by the post-fix revert battery, which is how all ten of round 2's promotions were checked.", "cr54_technique": "Root could not be obtained, so the scenario puts a no-op chmod earlier in PATH and exports the real scenario function into a fresh bash — driving the genuine root-guard branch without root. Simulate the condition the guard checks, not the privilege. Worth reusing for environment-dependent tests.", "fixer_warning_from_the_actor": "The actor reported, unprompted, that a naive CR-55 type-guard does NOT incidentally satisfy CR-47's scenario — the two findings share the §4/§7 vocabulary but are genuinely separate edits." } } ```

jbr870 commented

2026-08-26 15:28:47 +00:00

Author

Owner

{
  "outcome": "clean",
  "summary": "Round 3 fix stage. All 6 in-scope findings fixed STRUCTURALLY — consumers now defer to their source rather than restating it — and all 6 markers promoted. Both suites fully green, all four gates green at this commit.",
  "findings": [],
  "artifacts": {
    "fix_commit": "a3a0e044c7cb9fe0fad14a8a58831217d3c7c5bb",
    "test_commit": "b691a4d",
    "fixed": [
      "CR-47 (blocking)",
      "CR-48",
      "CR-52",
      "CR-53",
      "CR-54",
      "CR-55"
    ],
    "files": [
      "plugin/skills/_shared/procedures/run-resource-claims.md",
      "plugin/skills/_shared/procedures/journal-template.md",
      "plugin/skills/_shared/procedures/qa-playbook.md",
      "plugin/skills/develop/SKILL.md",
      "scripts/test-run-resource-claims.sh"
    ],
    "gates_at_fix_commit": {
      "lint-conventions.sh": "clean",
      "test-lint-conventions.sh": "29 PASS / 0 FAIL / 0 RED",
      "test-run-resource-claims.sh": "41 PASS / 0 FAIL / 0 RED / 0 XPASS",
      "test-plugin-gates.sh": "17 passed, 0 failed, 0 skipped — run AFTER the commit, since it measures HEAD"
    }
  },
  "notes": {
    "the_structural_fix": "Where a document restated a list that lives elsewhere, the restatement is replaced by a REFERENCE, and the text now says why: a copy here would only drift the next time the source widens. That is the class's own failure mode written down as a warning to the next editor. Updating today's copy is exactly what CR-35 and CR-38 did, and both returned this round as CR-48 and CR-52 — which is the evidence that the textual fix does not hold.",
    "cr47_was_the_class_stated_plainly": "A verdict (`budget`) was added to §4 in round 2 and never reached the consumer that reads it. §7 step 4 kept a two-outcome vocabulary — shared versus nothing-shared — so a worker-budget overrun could never void, on the runner contention the contract exists for, and an overrun onto a class the peer never claimed turned UNJUDGEABLE into DISJOINT, the inversion §4's own bold rule forbids one section down. Step 4 now disposes of every verdict the filter can emit, and routes `unknown` to §1's remedy as void-pending, never to `recorded`.",
    "every_promotion_earned": "Driver-verified, not accepted from the report. Reverting the four documents to test_commit b691a4d while KEEPING the promoted markers put CR-47, CR-48, CR-52, CR-53 and CR-55 back to red; separately flipping CR-54's guard from return 0 back to return 1 put CR-54 back to red. Two batteries were needed because CR-54's fix lives in the same harness file that holds the promotions.",
    "behaviour_not_wording": "The shipped §4 filter was extracted and run: a malformed workers:[4] now returns `unknown` while a well-formed workers:8 still returns `budget`; the T3/T4 pair this round dispatched concurrently still reads `budget` rather than being forced to serialize; both identity controls still read `shared`. So CR-55 landed without regressing CR-46 or CR-2. Step 4 was READ IN FULL rather than grepped for keywords — word-presence would have passed a wrong disposition.",
    "class_swept": "The fixer also grepped validate-workflow.md, fix-workflow.md and worktree-discipline.md for further instances of the restatement pattern and found none, so the class is closed as far as this round can see.",
    "one_actor_by_design": "Rounds 1 and 2 split the fix stage by file, which twice produced the writer-versus-executor hazard — one fixer rewriting a gate another fixer executes, a collision neither the §4 claim comparison nor develop §3.1's file-boundary rule can express. Round 3 used a SINGLE actor across all five files: no concurrency, hazard gone, and the fixer could see the whole class rather than one slice of it."
  }
}

```json { "outcome": "clean", "summary": "Round 3 fix stage. All 6 in-scope findings fixed STRUCTURALLY — consumers now defer to their source rather than restating it — and all 6 markers promoted. Both suites fully green, all four gates green at this commit.", "findings": [], "artifacts": { "fix_commit": "a3a0e044c7cb9fe0fad14a8a58831217d3c7c5bb", "test_commit": "b691a4d", "fixed": [ "CR-47 (blocking)", "CR-48", "CR-52", "CR-53", "CR-54", "CR-55" ], "files": [ "plugin/skills/_shared/procedures/run-resource-claims.md", "plugin/skills/_shared/procedures/journal-template.md", "plugin/skills/_shared/procedures/qa-playbook.md", "plugin/skills/develop/SKILL.md", "scripts/test-run-resource-claims.sh" ], "gates_at_fix_commit": { "lint-conventions.sh": "clean", "test-lint-conventions.sh": "29 PASS / 0 FAIL / 0 RED", "test-run-resource-claims.sh": "41 PASS / 0 FAIL / 0 RED / 0 XPASS", "test-plugin-gates.sh": "17 passed, 0 failed, 0 skipped — run AFTER the commit, since it measures HEAD" } }, "notes": { "the_structural_fix": "Where a document restated a list that lives elsewhere, the restatement is replaced by a REFERENCE, and the text now says why: a copy here would only drift the next time the source widens. That is the class's own failure mode written down as a warning to the next editor. Updating today's copy is exactly what CR-35 and CR-38 did, and both returned this round as CR-48 and CR-52 — which is the evidence that the textual fix does not hold.", "cr47_was_the_class_stated_plainly": "A verdict (`budget`) was added to §4 in round 2 and never reached the consumer that reads it. §7 step 4 kept a two-outcome vocabulary — shared versus nothing-shared — so a worker-budget overrun could never void, on the runner contention the contract exists for, and an overrun onto a class the peer never claimed turned UNJUDGEABLE into DISJOINT, the inversion §4's own bold rule forbids one section down. Step 4 now disposes of every verdict the filter can emit, and routes `unknown` to §1's remedy as void-pending, never to `recorded`.", "every_promotion_earned": "Driver-verified, not accepted from the report. Reverting the four documents to test_commit b691a4d while KEEPING the promoted markers put CR-47, CR-48, CR-52, CR-53 and CR-55 back to red; separately flipping CR-54's guard from return 0 back to return 1 put CR-54 back to red. Two batteries were needed because CR-54's fix lives in the same harness file that holds the promotions.", "behaviour_not_wording": "The shipped §4 filter was extracted and run: a malformed workers:[4] now returns `unknown` while a well-formed workers:8 still returns `budget`; the T3/T4 pair this round dispatched concurrently still reads `budget` rather than being forced to serialize; both identity controls still read `shared`. So CR-55 landed without regressing CR-46 or CR-2. Step 4 was READ IN FULL rather than grepped for keywords — word-presence would have passed a wrong disposition.", "class_swept": "The fixer also grepped validate-workflow.md, fix-workflow.md and worktree-discipline.md for further instances of the restatement pattern and found none, so the class is closed as far as this round can see.", "one_actor_by_design": "Rounds 1 and 2 split the fix stage by file, which twice produced the writer-versus-executor hazard — one fixer rewriting a gate another fixer executes, a collision neither the §4 claim comparison nor develop §3.1's file-boundary rule can express. Round 3 used a SINGLE actor across all five files: no concurrency, hazard gone, and the fixer could see the whole class rather than one slice of it." } } ```

jbr870 commented

2026-08-26 15:50:41 +00:00

Author

Owner

{
  "outcome": "issues-found",
  "summary": "SWEEP 3 (round 3 exit gate) — 10 findings against the post-fix tree at a3a0e04. No Critical; two High (CR-56, CR-57) block. The round does NOT exit; next_state stays qa.",
  "findings": [
    {
      "id": "CR-56",
      "category": "in-scope-blocking",
      "severity": "High",
      "summary": "scenario_cr23's missing-vs-empty assertion is dead for the realistic regression shape — the sixth dead assertion on this feature, in a scenario round 3 had just edited.",
      "reasoning": "The scenario compares the recipe's output for a missing journal against its output for an empty one, but runs the two cases from DIFFERENT folders ($dest/case-missing, $dest/case-empty) while every recipe branch interpolates $JOURNAL. So the two strings differ by the path alone, and the comparison cannot fire for any regression whose message still names the path — which is every branch the recipe has. Driver measured it in two steps. First probe collapsed both branch messages to a constant with NO path in it: outputs became byte-identical and the assertion correctly FIRED (rc=1, FAIL) — which does not test the claim and would have exonerated the scenario. Second probe collapsed them to an identical template that STILL interpolates $JOURNAL — the realistic shape: the two states become indistinguishable and the scenario PASSES, suite rc=0. Compounding, the CR-54 root guard's `return 0` sits after cases A/B but before `reasons` is evaluated, so on a box where chmod 000 has no effect it discards an already-detected A/B failure. Fix needs both halves: one FEATURE_FOLDER (or a path-stripped comparison), and the guard must not run before the accumulated reasons are flushed.",
      "proposed_action": "Compare the two cases from one folder or strip the path before comparing; move the root guard after the A/B verdict.",
      "fix_cost": "low",
      "feature_value": "core",
      "adjacent_to_blocking": true
    },
    {
      "id": "CR-57",
      "category": "in-scope-blocking",
      "severity": "High",
      "summary": "overran_resources has no defined absence semantics, so the same overrun is voided or recorded depending on whether the writer padded empty keys — and the punitive branch lands on the honest discloser.",
      "reasoning": "§7 step 4 reuses 'the SAME §4 filter' to intersect overran_resources against a peer's claims. §4's absent-key rule (absent means unknown) is correct for a CLAIM and wrong for an overrun RECORD, where an absent key means 'did not overrun this class' — demonstrably nothing, not unknown. Driver measured on the shipped filter, same fact, two spellings: {\"workers\":3} against a conforming peer claim yields THREE unknown verdicts (database/port/external 'absent from a claim') plus one budget — and step 4 routes any unknown to void-pending, so the budget branch is unreachable; the padded spelling {\"database\":[],\"port\":[],\"workers\":3,\"external\":[]} yields exactly ONE budget entry, which reaches the sum test and is recorded. The reference journal's own structured overran_resources entries are the SPARSE spelling. So a workers-shaped overrun — 3 of this feature's 4 real overruns — is voided or recorded on an unstated formatting choice, and the spelling the run actually produced is the one that gets punished. That re-creates the disclosure disincentive §8.4 was narrowed to remove, through the mechanism round 3 shipped, and violates the contract's own rule that one output may never stand for two answers.",
      "proposed_action": "Define overran_resources as total over the vocabulary (absent = did-not-overrun), or have step 4 restrict the filter's class union to the keys the overrun names.",
      "fix_cost": "low",
      "feature_value": "core",
      "adjacent_to_blocking": true
    },
    {
      "id": "CR-58",
      "category": "in-scope-deferrable",
      "severity": "Medium",
      "summary": "Step 4's budget disposal restates §4's sum test as pairwise when §4 defines it as global, and the sentence does not parse as a comparison.",
      "reasoning": "§4's sum test is explicitly global — 'total = the workers claimed by every actor dispatched and not yet released; collision when total > pool' — and §4 even warns that two claims 'collide only once a third claim pushes the total past the pool'. Step 4 says 'sum the overrun against that peer's claimed workers plus the pool', which is per-peer pairwise inside a loop over peers and misses oversubscription whenever three or more actors are active (overrun 2 + peer 4 is under an 8 pool pairwise, while 2+4+4 is over it globally). 'Against ... plus the pool' also does not parse as a comparison. A fresh instance of the drift class inside the commit that closed it, which is the honest answer to round 3's framing question: the class is closed where someone looked.",
      "proposed_action": "Defer to §4's sum test rather than restating it.",
      "fix_cost": "low",
      "feature_value": "core",
      "adjacent_to_blocking": true
    },
    {
      "id": "CR-59",
      "category": "in-scope-deferrable",
      "severity": "Medium",
      "summary": "The reference journal violates journal-template's UTC rule in every entry written after that rule shipped — no mechanism checks it.",
      "reasoning": "The CR-8 fix states the stamp IS UTC, 'whatever zone the operator is in', and shipped in round 1's fix commit on 2026-08-25. All eight entries appended on 2026-08-26 carry +02:00, because the driver's dispatch/release helpers called `date -Iseconds` rather than `date -u -Iseconds`. No wrong answer today — the offset is uniform, so ordering and intervals are unaffected — but this is the third instance of 'a rule with no enforcement path is a rule that will be missed', after CR-26 (a suite no gate invoked) and CR-36 (a required field the writing helper had no parameter for). DRIVER HAS ALREADY FIXED THE HELPERS and appended a correction entry using the very supersession shape CR-52 added; what remains deferrable is the absence of a mechanical check.",
      "proposed_action": "Add a mechanical check that journal stamps are UTC.",
      "fix_cost": "low",
      "feature_value": "incidental",
      "adjacent_to_blocking": false
    },
    {
      "id": "CR-60",
      "category": "in-scope-deferrable",
      "severity": "Medium",
      "summary": "§7 step 3's quoting sed corrupts a quoted identity containing a comma, producing invalid JSON.",
      "reasoning": "Measured: a claims line carrying external: [\"gitea:host/repo issues 43 and 256, read-only, 3 calls\"] — the exact identity shape the sweep's own RELEASE recorded — emerges as [\"gitea:host/repo issues 43 and 256, \"read-only\", \"3\" calls\"], which is invalid JSON. The bare-item-quoting regex fires inside an already-quoted string after each comma. Checked against #256's eleven listed gaps and it is not among them. A new concrete parser instance that belongs with that set.",
      "proposed_action": "Fold into #256.",
      "fix_cost": "low",
      "feature_value": "incidental",
      "adjacent_to_blocking": false
    },
    {
      "id": "CR-61",
      "category": "in-scope-deferrable",
      "severity": "Medium",
      "summary": "§4's port-range expansion is unbounded and its intersection quadratic, so one typo'd digit hangs the dispatch decision with no diagnostic.",
      "reasoning": "Measured scaling: 1000-port ranges intersect in 0.1s, 5000-port in 0.6s, '1024-65535' against a single port exceeds 30s, and '1-999999999' — one extra digit — satisfies the ^[0-9]+-[0-9]+$ regex, passes malformed_range (start is less than end) and hangs indefinitely with no output. Not producible in this repo, which declares no ports, so Medium rather than High. A width ceiling in malformed_range is the cheap fix.",
      "proposed_action": "Add a range-width ceiling to malformed_range.",
      "fix_cost": "low",
      "feature_value": "incidental",
      "adjacent_to_blocking": false
    },
    {
      "id": "CR-62",
      "category": "in-scope-deferrable",
      "severity": "Low",
      "summary": "Non-integer and negative workers values are accepted as budget, and a negative claim deflates the sum test.",
      "reasoning": "Fuzz-measured: workers: 1.5 returns budget; workers: -3 against 2 returns budget. §3 says 'budget (integer)'. The CR-55 fix checks type == \"number\", which admits both. Same jq expression the blocking CR-57/CR-58 fix must open.",
      "proposed_action": "Check integerhood and non-negativity, not merely numeric type.",
      "fix_cost": "low",
      "feature_value": "core",
      "adjacent_to_blocking": true
    },
    {
      "id": "CR-63",
      "category": "in-scope-deferrable",
      "severity": "Low",
      "summary": "One restatement narrower than §2 survives, in a file round 3's fixer reported clean.",
      "reasoning": "worktree-discipline.md:91's void-cause sentence enumerates 'the same database, port or runner workers' — omitting external, project-named classes and the shared-artefact shape, so it is already narrower than §2 today rather than merely drift-prone. Mitigated by the following sentence ('a pointer to it, not a second copy'), which is why it is Low. But it is a concrete counterexample to the fixer's report that the class is closed as far as this round can see, and the round's framing makes that claim worth correcting on the record.",
      "proposed_action": "Replace the enumeration with a reference to §2.",
      "fix_cost": "low",
      "feature_value": "core",
      "adjacent_to_blocking": true
    },
    {
      "id": "CR-64",
      "category": "in-scope-deferrable",
      "severity": "Low",
      "summary": "CR-47's regression scenario is vocabulary-coupled only: it detects a missing verdict word, not a wrong disposition.",
      "reasoning": "Measured: rewriting step 4's budget line to 'ignore budget entries entirely; they never affect triage' — semantics inverted, the word budget retained — leaves scenario_cr47_step4_lacks_verdict_branch PASSING, suite rc=0. The fix report already conceded word-presence cannot check disposition, and the driver read step 4 in full for exactly that reason. Recording the measurement so the limit is on the record rather than in a reviewer's memory: the class's only mechanical guard sees vocabulary drift and not disposition drift — which is precisely what CR-58 is.",
      "proposed_action": "Record as a known limit; strengthening it is a design question for #257.",
      "fix_cost": "medium",
      "feature_value": "incidental",
      "adjacent_to_blocking": false
    },
    {
      "id": "CR-65",
      "category": "in-scope-deferrable",
      "severity": "Low",
      "summary": "Step 4's unknown branch prescribes §1's dispatch-time remedies for a completed result at triage time.",
      "reasoning": "Reassign-or-serialize are things you do BEFORE dispatching; step 4 runs at triage, after the fact, where the applicable remedy is §8.1's driver-owned isolated re-run. Followable only by charitable reading — 'void pending it' carries the actionable content. Same sentence CR-58 must rewrite.",
      "proposed_action": "Point the unknown branch at §8.1's re-run rather than §1's dispatch remedies.",
      "fix_cost": "low",
      "feature_value": "core",
      "adjacent_to_blocking": true
    }
  ],
  "artifacts": {
    "report_path": ".devwork/feature-qa-intra-run-lane-ownership/code-report.md",
    "journal_path": ".devwork/feature-qa-intra-run-lane-ownership/code-journal.md",
    "dispatch_journal": ".devwork/feature-qa-intra-run-lane-ownership/dispatch-journal.md",
    "swept_head": "a3a0e04"
  },
  "notes": {
    "the_structural_fix_held": "This is the round's most important result and it is a NEGATIVE one. Round 3 was framed at the drift class and the sweep attacked that framing directly: consumers genuinely defer (qa-playbook, develop/SKILL.md, fix-workflow, validate-workflow, test-plan all cite by path and the targets say what they point at), the §4 verdict set is CLOSED under a 20-shape fuzz battery (only shared/unknown/budget/empty ever appear, and a non-object claims block fails loudly rather than silently), and every promoted marker is earned. Exactly ONE surviving restatement was found (CR-63), against the fixer's report that there were none. The residue is concentrated in ten lines of §7 step 4 plus one harness scenario — which is what makes a narrow round 4 the right response rather than a re-think.",
    "cr57_is_the_serious_one": "Driver re-measured on the shipped filter. The SAME overrun fact, {\"workers\":3} sparse versus {\"database\":[],\"port\":[],\"workers\":3,\"external\":[]} padded, against a conforming peer claim: the sparse spelling yields THREE unknown verdicts and step 4 voids; the padded spelling yields ONE budget entry, reaches the sum test, and is recorded. §4's absent-key-means-unknown rule is right for a CLAIM and wrong for an overrun RECORD, where an absent key means did-not-overrun. The reference journal's own entries use the sparse spelling — so the contract punishes the shape its own run produced, which re-creates the disclosure disincentive §8.4 exists to remove, via the mechanism round 3 just shipped.",
    "cr56_needed_a_second_probe": "The driver's FIRST probe would have exonerated the scenario. Collapsing the recipe's two branch messages to a constant with no path in it made the outputs byte-identical and the assertion correctly FIRED (rc=1). That does not test the claim: every recipe branch interpolates $JOURNAL, and the two cases run from different folders, so the realistic regression leaves the outputs differing by the path alone. Re-run collapsing them to an identical template that STILL names the path: the two states become indistinguishable and the scenario PASSES, rc=0. Confirmed dead for the shape that matters. Second time this round a first probe was wrong in the direction the driver expected; both times the correction came from asking what the probe actually reached.",
    "convergence_state": "Findings per sweep: 15, then 9, then 10. The count is not falling and the exit invariant explicitly does not read the trend. What HAS changed is severity and locus: 2 Critical, then 1 High, now 2 High with no Critical, and the residue narrowing from across the contract to ten lines of one step. Round 4 is scoped to the two blockers plus the four findings that sit in the same ten lines or the same jq expression; everything else defers.",
    "deferred": "CR-59 (a mechanical UTC check — the DRIVER HAS ALREADY FIXED ITS OWN HELPERS and appended a correction entry in the shape CR-52 defined, so only the enforcement path remains), CR-60 (comma-in-quoted-identity parser gap — folds into #256), CR-61 (unbounded port-range expansion — folds into #256), CR-64 (CR-47's guard is vocabulary-coupled only, which is a known limit and a design question for #257).",
    "disclosure": "The reviewer disclosed overran_claim: true with workers, external and git_object_store — the third consecutive sweep to disclose a project-named class the four-key schema has no room for, and the third to exceed workers: 1 because test-plugin-gates clones the repo and nested harness runs fan out."
  }
}

```json { "outcome": "issues-found", "summary": "SWEEP 3 (round 3 exit gate) — 10 findings against the post-fix tree at a3a0e04. No Critical; two High (CR-56, CR-57) block. The round does NOT exit; next_state stays qa.", "findings": [ { "id": "CR-56", "category": "in-scope-blocking", "severity": "High", "summary": "scenario_cr23's missing-vs-empty assertion is dead for the realistic regression shape — the sixth dead assertion on this feature, in a scenario round 3 had just edited.", "reasoning": "The scenario compares the recipe's output for a missing journal against its output for an empty one, but runs the two cases from DIFFERENT folders ($dest/case-missing, $dest/case-empty) while every recipe branch interpolates $JOURNAL. So the two strings differ by the path alone, and the comparison cannot fire for any regression whose message still names the path — which is every branch the recipe has. Driver measured it in two steps. First probe collapsed both branch messages to a constant with NO path in it: outputs became byte-identical and the assertion correctly FIRED (rc=1, FAIL) — which does not test the claim and would have exonerated the scenario. Second probe collapsed them to an identical template that STILL interpolates $JOURNAL — the realistic shape: the two states become indistinguishable and the scenario PASSES, suite rc=0. Compounding, the CR-54 root guard's `return 0` sits after cases A/B but before `reasons` is evaluated, so on a box where chmod 000 has no effect it discards an already-detected A/B failure. Fix needs both halves: one FEATURE_FOLDER (or a path-stripped comparison), and the guard must not run before the accumulated reasons are flushed.", "proposed_action": "Compare the two cases from one folder or strip the path before comparing; move the root guard after the A/B verdict.", "fix_cost": "low", "feature_value": "core", "adjacent_to_blocking": true }, { "id": "CR-57", "category": "in-scope-blocking", "severity": "High", "summary": "overran_resources has no defined absence semantics, so the same overrun is voided or recorded depending on whether the writer padded empty keys — and the punitive branch lands on the honest discloser.", "reasoning": "§7 step 4 reuses 'the SAME §4 filter' to intersect overran_resources against a peer's claims. §4's absent-key rule (absent means unknown) is correct for a CLAIM and wrong for an overrun RECORD, where an absent key means 'did not overrun this class' — demonstrably nothing, not unknown. Driver measured on the shipped filter, same fact, two spellings: {\"workers\":3} against a conforming peer claim yields THREE unknown verdicts (database/port/external 'absent from a claim') plus one budget — and step 4 routes any unknown to void-pending, so the budget branch is unreachable; the padded spelling {\"database\":[],\"port\":[],\"workers\":3,\"external\":[]} yields exactly ONE budget entry, which reaches the sum test and is recorded. The reference journal's own structured overran_resources entries are the SPARSE spelling. So a workers-shaped overrun — 3 of this feature's 4 real overruns — is voided or recorded on an unstated formatting choice, and the spelling the run actually produced is the one that gets punished. That re-creates the disclosure disincentive §8.4 was narrowed to remove, through the mechanism round 3 shipped, and violates the contract's own rule that one output may never stand for two answers.", "proposed_action": "Define overran_resources as total over the vocabulary (absent = did-not-overrun), or have step 4 restrict the filter's class union to the keys the overrun names.", "fix_cost": "low", "feature_value": "core", "adjacent_to_blocking": true }, { "id": "CR-58", "category": "in-scope-deferrable", "severity": "Medium", "summary": "Step 4's budget disposal restates §4's sum test as pairwise when §4 defines it as global, and the sentence does not parse as a comparison.", "reasoning": "§4's sum test is explicitly global — 'total = the workers claimed by every actor dispatched and not yet released; collision when total > pool' — and §4 even warns that two claims 'collide only once a third claim pushes the total past the pool'. Step 4 says 'sum the overrun against that peer's claimed workers plus the pool', which is per-peer pairwise inside a loop over peers and misses oversubscription whenever three or more actors are active (overrun 2 + peer 4 is under an 8 pool pairwise, while 2+4+4 is over it globally). 'Against ... plus the pool' also does not parse as a comparison. A fresh instance of the drift class inside the commit that closed it, which is the honest answer to round 3's framing question: the class is closed where someone looked.", "proposed_action": "Defer to §4's sum test rather than restating it.", "fix_cost": "low", "feature_value": "core", "adjacent_to_blocking": true }, { "id": "CR-59", "category": "in-scope-deferrable", "severity": "Medium", "summary": "The reference journal violates journal-template's UTC rule in every entry written after that rule shipped — no mechanism checks it.", "reasoning": "The CR-8 fix states the stamp IS UTC, 'whatever zone the operator is in', and shipped in round 1's fix commit on 2026-08-25. All eight entries appended on 2026-08-26 carry +02:00, because the driver's dispatch/release helpers called `date -Iseconds` rather than `date -u -Iseconds`. No wrong answer today — the offset is uniform, so ordering and intervals are unaffected — but this is the third instance of 'a rule with no enforcement path is a rule that will be missed', after CR-26 (a suite no gate invoked) and CR-36 (a required field the writing helper had no parameter for). DRIVER HAS ALREADY FIXED THE HELPERS and appended a correction entry using the very supersession shape CR-52 added; what remains deferrable is the absence of a mechanical check.", "proposed_action": "Add a mechanical check that journal stamps are UTC.", "fix_cost": "low", "feature_value": "incidental", "adjacent_to_blocking": false }, { "id": "CR-60", "category": "in-scope-deferrable", "severity": "Medium", "summary": "§7 step 3's quoting sed corrupts a quoted identity containing a comma, producing invalid JSON.", "reasoning": "Measured: a claims line carrying external: [\"gitea:host/repo issues 43 and 256, read-only, 3 calls\"] — the exact identity shape the sweep's own RELEASE recorded — emerges as [\"gitea:host/repo issues 43 and 256, \"read-only\", \"3\" calls\"], which is invalid JSON. The bare-item-quoting regex fires inside an already-quoted string after each comma. Checked against #256's eleven listed gaps and it is not among them. A new concrete parser instance that belongs with that set.", "proposed_action": "Fold into #256.", "fix_cost": "low", "feature_value": "incidental", "adjacent_to_blocking": false }, { "id": "CR-61", "category": "in-scope-deferrable", "severity": "Medium", "summary": "§4's port-range expansion is unbounded and its intersection quadratic, so one typo'd digit hangs the dispatch decision with no diagnostic.", "reasoning": "Measured scaling: 1000-port ranges intersect in 0.1s, 5000-port in 0.6s, '1024-65535' against a single port exceeds 30s, and '1-999999999' — one extra digit — satisfies the ^[0-9]+-[0-9]+$ regex, passes malformed_range (start is less than end) and hangs indefinitely with no output. Not producible in this repo, which declares no ports, so Medium rather than High. A width ceiling in malformed_range is the cheap fix.", "proposed_action": "Add a range-width ceiling to malformed_range.", "fix_cost": "low", "feature_value": "incidental", "adjacent_to_blocking": false }, { "id": "CR-62", "category": "in-scope-deferrable", "severity": "Low", "summary": "Non-integer and negative workers values are accepted as budget, and a negative claim deflates the sum test.", "reasoning": "Fuzz-measured: workers: 1.5 returns budget; workers: -3 against 2 returns budget. §3 says 'budget (integer)'. The CR-55 fix checks type == \"number\", which admits both. Same jq expression the blocking CR-57/CR-58 fix must open.", "proposed_action": "Check integerhood and non-negativity, not merely numeric type.", "fix_cost": "low", "feature_value": "core", "adjacent_to_blocking": true }, { "id": "CR-63", "category": "in-scope-deferrable", "severity": "Low", "summary": "One restatement narrower than §2 survives, in a file round 3's fixer reported clean.", "reasoning": "worktree-discipline.md:91's void-cause sentence enumerates 'the same database, port or runner workers' — omitting external, project-named classes and the shared-artefact shape, so it is already narrower than §2 today rather than merely drift-prone. Mitigated by the following sentence ('a pointer to it, not a second copy'), which is why it is Low. But it is a concrete counterexample to the fixer's report that the class is closed as far as this round can see, and the round's framing makes that claim worth correcting on the record.", "proposed_action": "Replace the enumeration with a reference to §2.", "fix_cost": "low", "feature_value": "core", "adjacent_to_blocking": true }, { "id": "CR-64", "category": "in-scope-deferrable", "severity": "Low", "summary": "CR-47's regression scenario is vocabulary-coupled only: it detects a missing verdict word, not a wrong disposition.", "reasoning": "Measured: rewriting step 4's budget line to 'ignore budget entries entirely; they never affect triage' — semantics inverted, the word budget retained — leaves scenario_cr47_step4_lacks_verdict_branch PASSING, suite rc=0. The fix report already conceded word-presence cannot check disposition, and the driver read step 4 in full for exactly that reason. Recording the measurement so the limit is on the record rather than in a reviewer's memory: the class's only mechanical guard sees vocabulary drift and not disposition drift — which is precisely what CR-58 is.", "proposed_action": "Record as a known limit; strengthening it is a design question for #257.", "fix_cost": "medium", "feature_value": "incidental", "adjacent_to_blocking": false }, { "id": "CR-65", "category": "in-scope-deferrable", "severity": "Low", "summary": "Step 4's unknown branch prescribes §1's dispatch-time remedies for a completed result at triage time.", "reasoning": "Reassign-or-serialize are things you do BEFORE dispatching; step 4 runs at triage, after the fact, where the applicable remedy is §8.1's driver-owned isolated re-run. Followable only by charitable reading — 'void pending it' carries the actionable content. Same sentence CR-58 must rewrite.", "proposed_action": "Point the unknown branch at §8.1's re-run rather than §1's dispatch remedies.", "fix_cost": "low", "feature_value": "core", "adjacent_to_blocking": true } ], "artifacts": { "report_path": ".devwork/feature-qa-intra-run-lane-ownership/code-report.md", "journal_path": ".devwork/feature-qa-intra-run-lane-ownership/code-journal.md", "dispatch_journal": ".devwork/feature-qa-intra-run-lane-ownership/dispatch-journal.md", "swept_head": "a3a0e04" }, "notes": { "the_structural_fix_held": "This is the round's most important result and it is a NEGATIVE one. Round 3 was framed at the drift class and the sweep attacked that framing directly: consumers genuinely defer (qa-playbook, develop/SKILL.md, fix-workflow, validate-workflow, test-plan all cite by path and the targets say what they point at), the §4 verdict set is CLOSED under a 20-shape fuzz battery (only shared/unknown/budget/empty ever appear, and a non-object claims block fails loudly rather than silently), and every promoted marker is earned. Exactly ONE surviving restatement was found (CR-63), against the fixer's report that there were none. The residue is concentrated in ten lines of §7 step 4 plus one harness scenario — which is what makes a narrow round 4 the right response rather than a re-think.", "cr57_is_the_serious_one": "Driver re-measured on the shipped filter. The SAME overrun fact, {\"workers\":3} sparse versus {\"database\":[],\"port\":[],\"workers\":3,\"external\":[]} padded, against a conforming peer claim: the sparse spelling yields THREE unknown verdicts and step 4 voids; the padded spelling yields ONE budget entry, reaches the sum test, and is recorded. §4's absent-key-means-unknown rule is right for a CLAIM and wrong for an overrun RECORD, where an absent key means did-not-overrun. The reference journal's own entries use the sparse spelling — so the contract punishes the shape its own run produced, which re-creates the disclosure disincentive §8.4 exists to remove, via the mechanism round 3 just shipped.", "cr56_needed_a_second_probe": "The driver's FIRST probe would have exonerated the scenario. Collapsing the recipe's two branch messages to a constant with no path in it made the outputs byte-identical and the assertion correctly FIRED (rc=1). That does not test the claim: every recipe branch interpolates $JOURNAL, and the two cases run from different folders, so the realistic regression leaves the outputs differing by the path alone. Re-run collapsing them to an identical template that STILL names the path: the two states become indistinguishable and the scenario PASSES, rc=0. Confirmed dead for the shape that matters. Second time this round a first probe was wrong in the direction the driver expected; both times the correction came from asking what the probe actually reached.", "convergence_state": "Findings per sweep: 15, then 9, then 10. The count is not falling and the exit invariant explicitly does not read the trend. What HAS changed is severity and locus: 2 Critical, then 1 High, now 2 High with no Critical, and the residue narrowing from across the contract to ten lines of one step. Round 4 is scoped to the two blockers plus the four findings that sit in the same ten lines or the same jq expression; everything else defers.", "deferred": "CR-59 (a mechanical UTC check — the DRIVER HAS ALREADY FIXED ITS OWN HELPERS and appended a correction entry in the shape CR-52 defined, so only the enforcement path remains), CR-60 (comma-in-quoted-identity parser gap — folds into #256), CR-61 (unbounded port-range expansion — folds into #256), CR-64 (CR-47's guard is vocabulary-coupled only, which is a known limit and a design question for #257).", "disclosure": "The reviewer disclosed overran_claim: true with workers, external and git_object_store — the third consecutive sweep to disclose a project-named class the four-key schema has no room for, and the third to exceed workers: 1 because test-plugin-gates clones the repo and nested harness runs fan out." } } ```

jbr870 commented

2026-08-26 15:50:45 +00:00

Author

Owner

{
  "next_state": "qa",
  "produced": [
    {
      "kind": "qa-report",
      "ref": "2079",
      "summary": "code phase=fix — 6 findings fixed structurally, all 4 gates green"
    },
    {
      "kind": "qa-report",
      "ref": "latest",
      "summary": "code phase=validate — sweep 3, 10 findings, 2 High blocking"
    },
    {
      "kind": "code-bundle",
      "ref": "a3a0e04",
      "summary": "the swept HEAD: fix commit a3a0e04 on test_commit b691a4d"
    }
  ],
  "findings": [
    {
      "category": "in-scope-blocking",
      "severity": "high",
      "summary": "[code CR-56] scenario_cr23's missing-vs-empty assertion is dead for the realistic regression shape — the sixth dead assertion on this feature, in a scenario round 3 had just edited.",
      "reasoning": "The scenario compares the recipe's output for a missing journal against its output for an empty one, but runs the two cases from DIFFERENT folders ($dest/case-missing, $dest/case-empty) while every recipe branch interpolates $JOURNAL. So the two strings differ by the path alone, and the comparison cannot fire for any regression whose message still names the path — which is every branch the recipe has. Driver measured it in two steps. First probe collapsed both branch messages to a constant with NO path in it: outputs became byte-identical and the assertion correctly FIRED (rc=1, FAIL) — which does not test the claim and would have exonerated the scenario. Second probe collapsed them to an identical template that STILL interpolates $JOURNAL — the realistic shape: the two states become indistinguishable and the scenario PASSES, suite rc=0. Compounding, the CR-54 root guard's `return 0` sits after cases A/B but before `reasons` is evaluated, so on a box where chmod 000 has no effect it discards an already-detected A/B failure. Fix needs both halves: one FEATURE_FOLDER (or a path-stripped comparison), and the guard must not run before the accumulated reasons are flushed.",
      "proposed_action": "Compare the two cases from one folder or strip the path before comparing; move the root guard after the A/B verdict.",
      "fix_cost": "low",
      "feature_value": "core",
      "adjacent_to_blocking": true,
      "id": "F-PO-43-7-1"
    },
    {
      "category": "in-scope-blocking",
      "severity": "high",
      "summary": "[code CR-57] overran_resources has no defined absence semantics, so the same overrun is voided or recorded depending on whether the writer padded empty keys — and the punitive branch lands on the honest discloser.",
      "reasoning": "§7 step 4 reuses 'the SAME §4 filter' to intersect overran_resources against a peer's claims. §4's absent-key rule (absent means unknown) is correct for a CLAIM and wrong for an overrun RECORD, where an absent key means 'did not overrun this class' — demonstrably nothing, not unknown. Driver measured on the shipped filter, same fact, two spellings: {\"workers\":3} against a conforming peer claim yields THREE unknown verdicts (database/port/external 'absent from a claim') plus one budget — and step 4 routes any unknown to void-pending, so the budget branch is unreachable; the padded spelling {\"database\":[],\"port\":[],\"workers\":3,\"external\":[]} yields exactly ONE budget entry, which reaches the sum test and is recorded. The reference journal's own structured overran_resources entries are the SPARSE spelling. So a workers-shaped overrun — 3 of this feature's 4 real overruns — is voided or recorded on an unstated formatting choice, and the spelling the run actually produced is the one that gets punished. That re-creates the disclosure disincentive §8.4 was narrowed to remove, through the mechanism round 3 shipped, and violates the contract's own rule that one output may never stand for two answers.",
      "proposed_action": "Define overran_resources as total over the vocabulary (absent = did-not-overrun), or have step 4 restrict the filter's class union to the keys the overrun names.",
      "fix_cost": "low",
      "feature_value": "core",
      "adjacent_to_blocking": true,
      "id": "F-PO-43-7-2"
    },
    {
      "category": "in-scope-deferrable",
      "severity": "medium",
      "summary": "[code CR-58] Step 4's budget disposal restates §4's sum test as pairwise when §4 defines it as global, and the sentence does not parse as a comparison.",
      "reasoning": "§4's sum test is explicitly global — 'total = the workers claimed by every actor dispatched and not yet released; collision when total > pool' — and §4 even warns that two claims 'collide only once a third claim pushes the total past the pool'. Step 4 says 'sum the overrun against that peer's claimed workers plus the pool', which is per-peer pairwise inside a loop over peers and misses oversubscription whenever three or more actors are active (overrun 2 + peer 4 is under an 8 pool pairwise, while 2+4+4 is over it globally). 'Against ... plus the pool' also does not parse as a comparison. A fresh instance of the drift class inside the commit that closed it, which is the honest answer to round 3's framing question: the class is closed where someone looked.",
      "proposed_action": "Defer to §4's sum test rather than restating it.",
      "fix_cost": "low",
      "feature_value": "core",
      "adjacent_to_blocking": true,
      "id": "F-PO-43-7-3"
    },
    {
      "category": "in-scope-deferrable",
      "severity": "medium",
      "summary": "[code CR-59] The reference journal violates journal-template's UTC rule in every entry written after that rule shipped — no mechanism checks it.",
      "reasoning": "The CR-8 fix states the stamp IS UTC, 'whatever zone the operator is in', and shipped in round 1's fix commit on 2026-08-25. All eight entries appended on 2026-08-26 carry +02:00, because the driver's dispatch/release helpers called `date -Iseconds` rather than `date -u -Iseconds`. No wrong answer today — the offset is uniform, so ordering and intervals are unaffected — but this is the third instance of 'a rule with no enforcement path is a rule that will be missed', after CR-26 (a suite no gate invoked) and CR-36 (a required field the writing helper had no parameter for). DRIVER HAS ALREADY FIXED THE HELPERS and appended a correction entry using the very supersession shape CR-52 added; what remains deferrable is the absence of a mechanical check.",
      "proposed_action": "Add a mechanical check that journal stamps are UTC.",
      "fix_cost": "low",
      "feature_value": "incidental",
      "adjacent_to_blocking": false,
      "id": "F-PO-43-7-4"
    },
    {
      "category": "in-scope-deferrable",
      "severity": "medium",
      "summary": "[code CR-60] §7 step 3's quoting sed corrupts a quoted identity containing a comma, producing invalid JSON.",
      "reasoning": "Measured: a claims line carrying external: [\"gitea:host/repo issues 43 and 256, read-only, 3 calls\"] — the exact identity shape the sweep's own RELEASE recorded — emerges as [\"gitea:host/repo issues 43 and 256, \"read-only\", \"3\" calls\"], which is invalid JSON. The bare-item-quoting regex fires inside an already-quoted string after each comma. Checked against #256's eleven listed gaps and it is not among them. A new concrete parser instance that belongs with that set.",
      "proposed_action": "Fold into #256.",
      "fix_cost": "low",
      "feature_value": "incidental",
      "adjacent_to_blocking": false,
      "id": "F-PO-43-7-5"
    },
    {
      "category": "in-scope-deferrable",
      "severity": "medium",
      "summary": "[code CR-61] §4's port-range expansion is unbounded and its intersection quadratic, so one typo'd digit hangs the dispatch decision with no diagnostic.",
      "reasoning": "Measured scaling: 1000-port ranges intersect in 0.1s, 5000-port in 0.6s, '1024-65535' against a single port exceeds 30s, and '1-999999999' — one extra digit — satisfies the ^[0-9]+-[0-9]+$ regex, passes malformed_range (start is less than end) and hangs indefinitely with no output. Not producible in this repo, which declares no ports, so Medium rather than High. A width ceiling in malformed_range is the cheap fix.",
      "proposed_action": "Add a range-width ceiling to malformed_range.",
      "fix_cost": "low",
      "feature_value": "incidental",
      "adjacent_to_blocking": false,
      "id": "F-PO-43-7-6"
    },
    {
      "category": "in-scope-deferrable",
      "severity": "low",
      "summary": "[code CR-62] Non-integer and negative workers values are accepted as budget, and a negative claim deflates the sum test.",
      "reasoning": "Fuzz-measured: workers: 1.5 returns budget; workers: -3 against 2 returns budget. §3 says 'budget (integer)'. The CR-55 fix checks type == \"number\", which admits both. Same jq expression the blocking CR-57/CR-58 fix must open.",
      "proposed_action": "Check integerhood and non-negativity, not merely numeric type.",
      "fix_cost": "low",
      "feature_value": "core",
      "adjacent_to_blocking": true,
      "id": "F-PO-43-7-7"
    },
    {
      "category": "in-scope-deferrable",
      "severity": "low",
      "summary": "[code CR-63] One restatement narrower than §2 survives, in a file round 3's fixer reported clean.",
      "reasoning": "worktree-discipline.md:91's void-cause sentence enumerates 'the same database, port or runner workers' — omitting external, project-named classes and the shared-artefact shape, so it is already narrower than §2 today rather than merely drift-prone. Mitigated by the following sentence ('a pointer to it, not a second copy'), which is why it is Low. But it is a concrete counterexample to the fixer's report that the class is closed as far as this round can see, and the round's framing makes that claim worth correcting on the record.",
      "proposed_action": "Replace the enumeration with a reference to §2.",
      "fix_cost": "low",
      "feature_value": "core",
      "adjacent_to_blocking": true,
      "id": "F-PO-43-7-8"
    },
    {
      "category": "in-scope-deferrable",
      "severity": "low",
      "summary": "[code CR-64] CR-47's regression scenario is vocabulary-coupled only: it detects a missing verdict word, not a wrong disposition.",
      "reasoning": "Measured: rewriting step 4's budget line to 'ignore budget entries entirely; they never affect triage' — semantics inverted, the word budget retained — leaves scenario_cr47_step4_lacks_verdict_branch PASSING, suite rc=0. The fix report already conceded word-presence cannot check disposition, and the driver read step 4 in full for exactly that reason. Recording the measurement so the limit is on the record rather than in a reviewer's memory: the class's only mechanical guard sees vocabulary drift and not disposition drift — which is precisely what CR-58 is.",
      "proposed_action": "Record as a known limit; strengthening it is a design question for #257.",
      "fix_cost": "medium",
      "feature_value": "incidental",
      "adjacent_to_blocking": false,
      "id": "F-PO-43-7-9"
    },
    {
      "category": "in-scope-deferrable",
      "severity": "low",
      "summary": "[code CR-65] Step 4's unknown branch prescribes §1's dispatch-time remedies for a completed result at triage time.",
      "reasoning": "Reassign-or-serialize are things you do BEFORE dispatching; step 4 runs at triage, after the fact, where the applicable remedy is §8.1's driver-owned isolated re-run. Followable only by charitable reading — 'void pending it' carries the actionable content. Same sentence CR-58 must rewrite.",
      "proposed_action": "Point the unknown branch at §8.1's re-run rather than §1's dispatch remedies.",
      "fix_cost": "low",
      "feature_value": "core",
      "adjacent_to_blocking": true,
      "id": "F-PO-43-7-10"
    }
  ],
  "pending_decisions": [
    {
      "id": "D-PO-43-7-1",
      "type": "scope-disposition",
      "blocking": false,
      "question": "[CR-58] Step 4's budget disposal restates §4's sum test as pairwise when §4 defines it as global, and the sentence does not parse as a comparison. — fix now, spawn a follow-up issue, or accept?",
      "options": [
        "fix-now",
        "defer-to-issue",
        "accept"
      ],
      "recommended": "defer-to-issue",
      "finding_ref": "F-PO-43-7-3",
      "reasoning": "Computed by disposition-recommend.sh from the finding's axes. Full evidence in the sweep qa-report:v1 (domain=code, phase=validate) and code-journal.md."
    },
    {
      "id": "D-PO-43-7-2",
      "type": "scope-disposition",
      "blocking": false,
      "question": "[CR-59] The reference journal violates journal-template's UTC rule in every entry written after that rule shipped — no mechanism checks it. — fix now, spawn a follow-up issue, or accept?",
      "options": [
        "fix-now",
        "defer-to-issue",
        "accept"
      ],
      "recommended": "defer-to-issue",
      "finding_ref": "F-PO-43-7-4",
      "reasoning": "Computed by disposition-recommend.sh from the finding's axes. Full evidence in the sweep qa-report:v1 (domain=code, phase=validate) and code-journal.md."
    },
    {
      "id": "D-PO-43-7-3",
      "type": "scope-disposition",
      "blocking": false,
      "question": "[CR-60] §7 step 3's quoting sed corrupts a quoted identity containing a comma, producing invalid JSON. — fix now, spawn a follow-up issue, or accept?",
      "options": [
        "fix-now",
        "defer-to-issue",
        "accept"
      ],
      "recommended": "defer-to-issue",
      "finding_ref": "F-PO-43-7-5",
      "reasoning": "Computed by disposition-recommend.sh from the finding's axes. Full evidence in the sweep qa-report:v1 (domain=code, phase=validate) and code-journal.md."
    },
    {
      "id": "D-PO-43-7-4",
      "type": "scope-disposition",
      "blocking": false,
      "question": "[CR-61] §4's port-range expansion is unbounded and its intersection quadratic, so one typo'd digit hangs the dispatch decision with no diagnostic. — fix now, spawn a follow-up issue, or accept?",
      "options": [
        "fix-now",
        "defer-to-issue",
        "accept"
      ],
      "recommended": "defer-to-issue",
      "finding_ref": "F-PO-43-7-6",
      "reasoning": "Computed by disposition-recommend.sh from the finding's axes. Full evidence in the sweep qa-report:v1 (domain=code, phase=validate) and code-journal.md."
    },
    {
      "id": "D-PO-43-7-5",
      "type": "scope-disposition",
      "blocking": false,
      "question": "[CR-62] Non-integer and negative workers values are accepted as budget, and a negative claim deflates the sum test. — fix now, spawn a follow-up issue, or accept?",
      "options": [
        "fix-now",
        "defer-to-issue",
        "accept"
      ],
      "recommended": "defer-to-issue",
      "finding_ref": "F-PO-43-7-7",
      "reasoning": "Computed by disposition-recommend.sh from the finding's axes. Full evidence in the sweep qa-report:v1 (domain=code, phase=validate) and code-journal.md."
    },
    {
      "id": "D-PO-43-7-6",
      "type": "scope-disposition",
      "blocking": false,
      "question": "[CR-63] One restatement narrower than §2 survives, in a file round 3's fixer reported clean. — fix now, spawn a follow-up issue, or accept?",
      "options": [
        "fix-now",
        "defer-to-issue",
        "accept"
      ],
      "recommended": "defer-to-issue",
      "finding_ref": "F-PO-43-7-8",
      "reasoning": "Computed by disposition-recommend.sh from the finding's axes. Full evidence in the sweep qa-report:v1 (domain=code, phase=validate) and code-journal.md."
    },
    {
      "id": "D-PO-43-7-7",
      "type": "scope-disposition",
      "blocking": false,
      "question": "[CR-64] CR-47's regression scenario is vocabulary-coupled only: it detects a missing verdict word, not a wrong disposition. — fix now, spawn a follow-up issue, or accept?",
      "options": [
        "fix-now",
        "defer-to-issue",
        "accept"
      ],
      "recommended": "defer-to-issue",
      "finding_ref": "F-PO-43-7-9",
      "reasoning": "Computed by disposition-recommend.sh from the finding's axes. Full evidence in the sweep qa-report:v1 (domain=code, phase=validate) and code-journal.md."
    },
    {
      "id": "D-PO-43-7-8",
      "type": "scope-disposition",
      "blocking": false,
      "question": "[CR-65] Step 4's unknown branch prescribes §1's dispatch-time remedies for a completed result at triage time. — fix now, spawn a follow-up issue, or accept?",
      "options": [
        "fix-now",
        "defer-to-issue",
        "accept"
      ],
      "recommended": "defer-to-issue",
      "finding_ref": "F-PO-43-7-10",
      "reasoning": "Computed by disposition-recommend.sh from the finding's axes. Full evidence in the sweep qa-report:v1 (domain=code, phase=validate) and code-journal.md."
    }
  ],
  "suite": {
    "source": "git",
    "sha": "a3a0e044c7cb9fe0fad14a8a58831217d3c7c5bb",
    "dirty": false
  }
}

```json { "next_state": "qa", "produced": [ { "kind": "qa-report", "ref": "2079", "summary": "code phase=fix — 6 findings fixed structurally, all 4 gates green" }, { "kind": "qa-report", "ref": "latest", "summary": "code phase=validate — sweep 3, 10 findings, 2 High blocking" }, { "kind": "code-bundle", "ref": "a3a0e04", "summary": "the swept HEAD: fix commit a3a0e04 on test_commit b691a4d" } ], "findings": [ { "category": "in-scope-blocking", "severity": "high", "summary": "[code CR-56] scenario_cr23's missing-vs-empty assertion is dead for the realistic regression shape — the sixth dead assertion on this feature, in a scenario round 3 had just edited.", "reasoning": "The scenario compares the recipe's output for a missing journal against its output for an empty one, but runs the two cases from DIFFERENT folders ($dest/case-missing, $dest/case-empty) while every recipe branch interpolates $JOURNAL. So the two strings differ by the path alone, and the comparison cannot fire for any regression whose message still names the path — which is every branch the recipe has. Driver measured it in two steps. First probe collapsed both branch messages to a constant with NO path in it: outputs became byte-identical and the assertion correctly FIRED (rc=1, FAIL) — which does not test the claim and would have exonerated the scenario. Second probe collapsed them to an identical template that STILL interpolates $JOURNAL — the realistic shape: the two states become indistinguishable and the scenario PASSES, suite rc=0. Compounding, the CR-54 root guard's `return 0` sits after cases A/B but before `reasons` is evaluated, so on a box where chmod 000 has no effect it discards an already-detected A/B failure. Fix needs both halves: one FEATURE_FOLDER (or a path-stripped comparison), and the guard must not run before the accumulated reasons are flushed.", "proposed_action": "Compare the two cases from one folder or strip the path before comparing; move the root guard after the A/B verdict.", "fix_cost": "low", "feature_value": "core", "adjacent_to_blocking": true, "id": "F-PO-43-7-1" }, { "category": "in-scope-blocking", "severity": "high", "summary": "[code CR-57] overran_resources has no defined absence semantics, so the same overrun is voided or recorded depending on whether the writer padded empty keys — and the punitive branch lands on the honest discloser.", "reasoning": "§7 step 4 reuses 'the SAME §4 filter' to intersect overran_resources against a peer's claims. §4's absent-key rule (absent means unknown) is correct for a CLAIM and wrong for an overrun RECORD, where an absent key means 'did not overrun this class' — demonstrably nothing, not unknown. Driver measured on the shipped filter, same fact, two spellings: {\"workers\":3} against a conforming peer claim yields THREE unknown verdicts (database/port/external 'absent from a claim') plus one budget — and step 4 routes any unknown to void-pending, so the budget branch is unreachable; the padded spelling {\"database\":[],\"port\":[],\"workers\":3,\"external\":[]} yields exactly ONE budget entry, which reaches the sum test and is recorded. The reference journal's own structured overran_resources entries are the SPARSE spelling. So a workers-shaped overrun — 3 of this feature's 4 real overruns — is voided or recorded on an unstated formatting choice, and the spelling the run actually produced is the one that gets punished. That re-creates the disclosure disincentive §8.4 was narrowed to remove, through the mechanism round 3 shipped, and violates the contract's own rule that one output may never stand for two answers.", "proposed_action": "Define overran_resources as total over the vocabulary (absent = did-not-overrun), or have step 4 restrict the filter's class union to the keys the overrun names.", "fix_cost": "low", "feature_value": "core", "adjacent_to_blocking": true, "id": "F-PO-43-7-2" }, { "category": "in-scope-deferrable", "severity": "medium", "summary": "[code CR-58] Step 4's budget disposal restates §4's sum test as pairwise when §4 defines it as global, and the sentence does not parse as a comparison.", "reasoning": "§4's sum test is explicitly global — 'total = the workers claimed by every actor dispatched and not yet released; collision when total > pool' — and §4 even warns that two claims 'collide only once a third claim pushes the total past the pool'. Step 4 says 'sum the overrun against that peer's claimed workers plus the pool', which is per-peer pairwise inside a loop over peers and misses oversubscription whenever three or more actors are active (overrun 2 + peer 4 is under an 8 pool pairwise, while 2+4+4 is over it globally). 'Against ... plus the pool' also does not parse as a comparison. A fresh instance of the drift class inside the commit that closed it, which is the honest answer to round 3's framing question: the class is closed where someone looked.", "proposed_action": "Defer to §4's sum test rather than restating it.", "fix_cost": "low", "feature_value": "core", "adjacent_to_blocking": true, "id": "F-PO-43-7-3" }, { "category": "in-scope-deferrable", "severity": "medium", "summary": "[code CR-59] The reference journal violates journal-template's UTC rule in every entry written after that rule shipped — no mechanism checks it.", "reasoning": "The CR-8 fix states the stamp IS UTC, 'whatever zone the operator is in', and shipped in round 1's fix commit on 2026-08-25. All eight entries appended on 2026-08-26 carry +02:00, because the driver's dispatch/release helpers called `date -Iseconds` rather than `date -u -Iseconds`. No wrong answer today — the offset is uniform, so ordering and intervals are unaffected — but this is the third instance of 'a rule with no enforcement path is a rule that will be missed', after CR-26 (a suite no gate invoked) and CR-36 (a required field the writing helper had no parameter for). DRIVER HAS ALREADY FIXED THE HELPERS and appended a correction entry using the very supersession shape CR-52 added; what remains deferrable is the absence of a mechanical check.", "proposed_action": "Add a mechanical check that journal stamps are UTC.", "fix_cost": "low", "feature_value": "incidental", "adjacent_to_blocking": false, "id": "F-PO-43-7-4" }, { "category": "in-scope-deferrable", "severity": "medium", "summary": "[code CR-60] §7 step 3's quoting sed corrupts a quoted identity containing a comma, producing invalid JSON.", "reasoning": "Measured: a claims line carrying external: [\"gitea:host/repo issues 43 and 256, read-only, 3 calls\"] — the exact identity shape the sweep's own RELEASE recorded — emerges as [\"gitea:host/repo issues 43 and 256, \"read-only\", \"3\" calls\"], which is invalid JSON. The bare-item-quoting regex fires inside an already-quoted string after each comma. Checked against #256's eleven listed gaps and it is not among them. A new concrete parser instance that belongs with that set.", "proposed_action": "Fold into #256.", "fix_cost": "low", "feature_value": "incidental", "adjacent_to_blocking": false, "id": "F-PO-43-7-5" }, { "category": "in-scope-deferrable", "severity": "medium", "summary": "[code CR-61] §4's port-range expansion is unbounded and its intersection quadratic, so one typo'd digit hangs the dispatch decision with no diagnostic.", "reasoning": "Measured scaling: 1000-port ranges intersect in 0.1s, 5000-port in 0.6s, '1024-65535' against a single port exceeds 30s, and '1-999999999' — one extra digit — satisfies the ^[0-9]+-[0-9]+$ regex, passes malformed_range (start is less than end) and hangs indefinitely with no output. Not producible in this repo, which declares no ports, so Medium rather than High. A width ceiling in malformed_range is the cheap fix.", "proposed_action": "Add a range-width ceiling to malformed_range.", "fix_cost": "low", "feature_value": "incidental", "adjacent_to_blocking": false, "id": "F-PO-43-7-6" }, { "category": "in-scope-deferrable", "severity": "low", "summary": "[code CR-62] Non-integer and negative workers values are accepted as budget, and a negative claim deflates the sum test.", "reasoning": "Fuzz-measured: workers: 1.5 returns budget; workers: -3 against 2 returns budget. §3 says 'budget (integer)'. The CR-55 fix checks type == \"number\", which admits both. Same jq expression the blocking CR-57/CR-58 fix must open.", "proposed_action": "Check integerhood and non-negativity, not merely numeric type.", "fix_cost": "low", "feature_value": "core", "adjacent_to_blocking": true, "id": "F-PO-43-7-7" }, { "category": "in-scope-deferrable", "severity": "low", "summary": "[code CR-63] One restatement narrower than §2 survives, in a file round 3's fixer reported clean.", "reasoning": "worktree-discipline.md:91's void-cause sentence enumerates 'the same database, port or runner workers' — omitting external, project-named classes and the shared-artefact shape, so it is already narrower than §2 today rather than merely drift-prone. Mitigated by the following sentence ('a pointer to it, not a second copy'), which is why it is Low. But it is a concrete counterexample to the fixer's report that the class is closed as far as this round can see, and the round's framing makes that claim worth correcting on the record.", "proposed_action": "Replace the enumeration with a reference to §2.", "fix_cost": "low", "feature_value": "core", "adjacent_to_blocking": true, "id": "F-PO-43-7-8" }, { "category": "in-scope-deferrable", "severity": "low", "summary": "[code CR-64] CR-47's regression scenario is vocabulary-coupled only: it detects a missing verdict word, not a wrong disposition.", "reasoning": "Measured: rewriting step 4's budget line to 'ignore budget entries entirely; they never affect triage' — semantics inverted, the word budget retained — leaves scenario_cr47_step4_lacks_verdict_branch PASSING, suite rc=0. The fix report already conceded word-presence cannot check disposition, and the driver read step 4 in full for exactly that reason. Recording the measurement so the limit is on the record rather than in a reviewer's memory: the class's only mechanical guard sees vocabulary drift and not disposition drift — which is precisely what CR-58 is.", "proposed_action": "Record as a known limit; strengthening it is a design question for #257.", "fix_cost": "medium", "feature_value": "incidental", "adjacent_to_blocking": false, "id": "F-PO-43-7-9" }, { "category": "in-scope-deferrable", "severity": "low", "summary": "[code CR-65] Step 4's unknown branch prescribes §1's dispatch-time remedies for a completed result at triage time.", "reasoning": "Reassign-or-serialize are things you do BEFORE dispatching; step 4 runs at triage, after the fact, where the applicable remedy is §8.1's driver-owned isolated re-run. Followable only by charitable reading — 'void pending it' carries the actionable content. Same sentence CR-58 must rewrite.", "proposed_action": "Point the unknown branch at §8.1's re-run rather than §1's dispatch remedies.", "fix_cost": "low", "feature_value": "core", "adjacent_to_blocking": true, "id": "F-PO-43-7-10" } ], "pending_decisions": [ { "id": "D-PO-43-7-1", "type": "scope-disposition", "blocking": false, "question": "[CR-58] Step 4's budget disposal restates §4's sum test as pairwise when §4 defines it as global, and the sentence does not parse as a comparison. — fix now, spawn a follow-up issue, or accept?", "options": [ "fix-now", "defer-to-issue", "accept" ], "recommended": "defer-to-issue", "finding_ref": "F-PO-43-7-3", "reasoning": "Computed by disposition-recommend.sh from the finding's axes. Full evidence in the sweep qa-report:v1 (domain=code, phase=validate) and code-journal.md." }, { "id": "D-PO-43-7-2", "type": "scope-disposition", "blocking": false, "question": "[CR-59] The reference journal violates journal-template's UTC rule in every entry written after that rule shipped — no mechanism checks it. — fix now, spawn a follow-up issue, or accept?", "options": [ "fix-now", "defer-to-issue", "accept" ], "recommended": "defer-to-issue", "finding_ref": "F-PO-43-7-4", "reasoning": "Computed by disposition-recommend.sh from the finding's axes. Full evidence in the sweep qa-report:v1 (domain=code, phase=validate) and code-journal.md." }, { "id": "D-PO-43-7-3", "type": "scope-disposition", "blocking": false, "question": "[CR-60] §7 step 3's quoting sed corrupts a quoted identity containing a comma, producing invalid JSON. — fix now, spawn a follow-up issue, or accept?", "options": [ "fix-now", "defer-to-issue", "accept" ], "recommended": "defer-to-issue", "finding_ref": "F-PO-43-7-5", "reasoning": "Computed by disposition-recommend.sh from the finding's axes. Full evidence in the sweep qa-report:v1 (domain=code, phase=validate) and code-journal.md." }, { "id": "D-PO-43-7-4", "type": "scope-disposition", "blocking": false, "question": "[CR-61] §4's port-range expansion is unbounded and its intersection quadratic, so one typo'd digit hangs the dispatch decision with no diagnostic. — fix now, spawn a follow-up issue, or accept?", "options": [ "fix-now", "defer-to-issue", "accept" ], "recommended": "defer-to-issue", "finding_ref": "F-PO-43-7-6", "reasoning": "Computed by disposition-recommend.sh from the finding's axes. Full evidence in the sweep qa-report:v1 (domain=code, phase=validate) and code-journal.md." }, { "id": "D-PO-43-7-5", "type": "scope-disposition", "blocking": false, "question": "[CR-62] Non-integer and negative workers values are accepted as budget, and a negative claim deflates the sum test. — fix now, spawn a follow-up issue, or accept?", "options": [ "fix-now", "defer-to-issue", "accept" ], "recommended": "defer-to-issue", "finding_ref": "F-PO-43-7-7", "reasoning": "Computed by disposition-recommend.sh from the finding's axes. Full evidence in the sweep qa-report:v1 (domain=code, phase=validate) and code-journal.md." }, { "id": "D-PO-43-7-6", "type": "scope-disposition", "blocking": false, "question": "[CR-63] One restatement narrower than §2 survives, in a file round 3's fixer reported clean. — fix now, spawn a follow-up issue, or accept?", "options": [ "fix-now", "defer-to-issue", "accept" ], "recommended": "defer-to-issue", "finding_ref": "F-PO-43-7-8", "reasoning": "Computed by disposition-recommend.sh from the finding's axes. Full evidence in the sweep qa-report:v1 (domain=code, phase=validate) and code-journal.md." }, { "id": "D-PO-43-7-7", "type": "scope-disposition", "blocking": false, "question": "[CR-64] CR-47's regression scenario is vocabulary-coupled only: it detects a missing verdict word, not a wrong disposition. — fix now, spawn a follow-up issue, or accept?", "options": [ "fix-now", "defer-to-issue", "accept" ], "recommended": "defer-to-issue", "finding_ref": "F-PO-43-7-9", "reasoning": "Computed by disposition-recommend.sh from the finding's axes. Full evidence in the sweep qa-report:v1 (domain=code, phase=validate) and code-journal.md." }, { "id": "D-PO-43-7-8", "type": "scope-disposition", "blocking": false, "question": "[CR-65] Step 4's unknown branch prescribes §1's dispatch-time remedies for a completed result at triage time. — fix now, spawn a follow-up issue, or accept?", "options": [ "fix-now", "defer-to-issue", "accept" ], "recommended": "defer-to-issue", "finding_ref": "F-PO-43-7-10", "reasoning": "Computed by disposition-recommend.sh from the finding's axes. Full evidence in the sweep qa-report:v1 (domain=code, phase=validate) and code-journal.md." } ], "suite": { "source": "git", "sha": "a3a0e044c7cb9fe0fad14a8a58831217d3c7c5bb", "dirty": false } } ```

jbr870 commented

2026-08-26 15:51:34 +00:00

Author

Owner

{
  "status": "resolved",
  "chosen_option": "fix-now",
  "rationale": "[CR-58] Same ten lines as the blocking CR-57, and the same edit must rewrite them either way. It is also a fresh instance of the drift class inside the commit that closed it — step 4 restates §4 s sum test as pairwise where §4 defines it as global, and misses oversubscription the moment three actors are live. The fix is the same structural move round 3 made everywhere else: defer to §4 s sum test rather than restate it. Leaving it would mean shipping a rule that reads correctly and computes wrongly, in the one section this round has now touched three times. Resolved by the driver under the operator's standing authority to run the QA phase to completion, stopping only on a blocking decision. Where this resolution differs from disposition-recommend.sh's answer it says so explicitly and gives the reason; the recommender scores each finding in isolation and cannot see that five of these are one recurring class.",
  "rejected_alternative": "defer-to-issue was the recommender s answer and is defensible on severity. Turned down on adjacency: the fixer is rewriting this sentence for CR-57 regardless, and a restatement left in place beside a freshly-corrected one is how the class propagates."
}

```json { "status": "resolved", "chosen_option": "fix-now", "rationale": "[CR-58] Same ten lines as the blocking CR-57, and the same edit must rewrite them either way. It is also a fresh instance of the drift class inside the commit that closed it — step 4 restates §4 s sum test as pairwise where §4 defines it as global, and misses oversubscription the moment three actors are live. The fix is the same structural move round 3 made everywhere else: defer to §4 s sum test rather than restate it. Leaving it would mean shipping a rule that reads correctly and computes wrongly, in the one section this round has now touched three times. Resolved by the driver under the operator's standing authority to run the QA phase to completion, stopping only on a blocking decision. Where this resolution differs from disposition-recommend.sh's answer it says so explicitly and gives the reason; the recommender scores each finding in isolation and cannot see that five of these are one recurring class.", "rejected_alternative": "defer-to-issue was the recommender s answer and is defensible on severity. Turned down on adjacency: the fixer is rewriting this sentence for CR-57 regardless, and a restatement left in place beside a freshly-corrected one is how the class propagates." } ```

jbr870 commented

2026-08-26 15:51:34 +00:00

Author

Owner

{
  "status": "resolved",
  "chosen_option": "defer-to-issue",
  "rationale": "[CR-59] The driver has already fixed the half that was actually wrong — its own helpers now stamp UTC, and a correction entry naming the superseded entries has been appended using the shape CR-52 defined, which is that mechanism s first real use. What remains is a mechanical check that a stamp is UTC, and that is enforcement machinery rather than a contract defect. It belongs with the other enforcement-path gaps rather than inside a round scoped to ten lines of step 4. Resolved by the driver under the operator's standing authority to run the QA phase to completion, stopping only on a blocking decision. Where this resolution differs from disposition-recommend.sh's answer it says so explicitly and gives the reason; the recommender scores each finding in isolation and cannot see that five of these are one recurring class.",
  "rejected_alternative": "fix-now was weighed because this is the THIRD instance of a rule with no enforcement path being missed, after CR-26 and CR-36, and that recurrence is real. Turned down because the recurrence is an argument for a general enforcement mechanism, which is design work, not for bolting a third one-off check into a narrow round."
}

```json { "status": "resolved", "chosen_option": "defer-to-issue", "rationale": "[CR-59] The driver has already fixed the half that was actually wrong — its own helpers now stamp UTC, and a correction entry naming the superseded entries has been appended using the shape CR-52 defined, which is that mechanism s first real use. What remains is a mechanical check that a stamp is UTC, and that is enforcement machinery rather than a contract defect. It belongs with the other enforcement-path gaps rather than inside a round scoped to ten lines of step 4. Resolved by the driver under the operator's standing authority to run the QA phase to completion, stopping only on a blocking decision. Where this resolution differs from disposition-recommend.sh's answer it says so explicitly and gives the reason; the recommender scores each finding in isolation and cannot see that five of these are one recurring class.", "rejected_alternative": "fix-now was weighed because this is the THIRD instance of a rule with no enforcement path being missed, after CR-26 and CR-36, and that recurrence is real. Turned down because the recurrence is an argument for a general enforcement mechanism, which is design work, not for bolting a third one-off check into a narrow round." } ```

jbr870 commented

2026-08-26 15:51:34 +00:00

Author

Owner

{
  "status": "resolved",
  "chosen_option": "defer-to-issue",
  "rationale": "[CR-60] A parser gap of exactly the kind #256 was created to hold, confirmed by the sweep against #256 s existing eleven and found not to duplicate any of them. Folding it there keeps the set together, which is how that set will actually get fixed. It is also not reachable from anything this round touches. Resolved by the driver under the operator's standing authority to run the QA phase to completion, stopping only on a blocking decision. Where this resolution differs from disposition-recommend.sh's answer it says so explicitly and gives the reason; the recommender scores each finding in isolation and cannot see that five of these are one recurring class.",
  "rejected_alternative": "fix-now had a case: the corrupting input is the shape the sweep s own RELEASE recorded, so it is demonstrably producible by this very run. Turned down because the corruption is in §7 s step 3 quoting sed, a different mechanism from the step 4 work, and opening it here would widen a round whose narrowness is the point."
}

```json { "status": "resolved", "chosen_option": "defer-to-issue", "rationale": "[CR-60] A parser gap of exactly the kind #256 was created to hold, confirmed by the sweep against #256 s existing eleven and found not to duplicate any of them. Folding it there keeps the set together, which is how that set will actually get fixed. It is also not reachable from anything this round touches. Resolved by the driver under the operator's standing authority to run the QA phase to completion, stopping only on a blocking decision. Where this resolution differs from disposition-recommend.sh's answer it says so explicitly and gives the reason; the recommender scores each finding in isolation and cannot see that five of these are one recurring class.", "rejected_alternative": "fix-now had a case: the corrupting input is the shape the sweep s own RELEASE recorded, so it is demonstrably producible by this very run. Turned down because the corruption is in §7 s step 3 quoting sed, a different mechanism from the step 4 work, and opening it here would widen a round whose narrowness is the point." } ```

jbr870 commented

Author

Owner

{
  "status": "resolved",
  "chosen_option": "defer-to-issue",
  "rationale": "[CR-61] Not producible in this repo — it declares no ports — and the fix is a width ceiling in a regex that no other finding in this round touches. It belongs with #256 s parser set for the same reason CR-60 does. Resolved by the driver under the operator's standing authority to run the QA phase to completion, stopping only on a blocking decision. Where this resolution differs from disposition-recommend.sh's answer it says so explicitly and gives the reason; the recommender scores each finding in isolation and cannot see that five of these are one recurring class.",
  "rejected_alternative": "fix-now was arguable because a silent unbounded hang is a nasty failure mode and the fix is one clause. Turned down on reachability: every other finding in this round s scope is reachable from the reference run, and mixing in one that is not blurs what the round is for."
}

```json { "status": "resolved", "chosen_option": "defer-to-issue", "rationale": "[CR-61] Not producible in this repo — it declares no ports — and the fix is a width ceiling in a regex that no other finding in this round touches. It belongs with #256 s parser set for the same reason CR-60 does. Resolved by the driver under the operator's standing authority to run the QA phase to completion, stopping only on a blocking decision. Where this resolution differs from disposition-recommend.sh's answer it says so explicitly and gives the reason; the recommender scores each finding in isolation and cannot see that five of these are one recurring class.", "rejected_alternative": "fix-now was arguable because a silent unbounded hang is a nasty failure mode and the fix is one clause. Turned down on reachability: every other finding in this round s scope is reachable from the reference run, and mixing in one that is not blurs what the round is for." } ```

jbr870 commented

Author

Owner

{
  "status": "resolved",
  "chosen_option": "fix-now",
  "rationale": "[CR-62] OVERRIDES the recommender. It is the same jq expression the CR-57 fix must open, and it is the residue of round 3 s own CR-55 fix, which checked type == number and thereby admitted 1.5 and -3 while §3 says integer. A negative claim deflates the sum test the CR-57/CR-58 work is making load-bearing, so leaving it undermines the fix landing beside it. Resolved by the driver under the operator's standing authority to run the QA phase to completion, stopping only on a blocking decision. Where this resolution differs from disposition-recommend.sh's answer it says so explicitly and gives the reason; the recommender scores each finding in isolation and cannot see that five of these are one recurring class.",
  "rejected_alternative": "defer-to-issue matches the Low severity and neither input occurs here today. Turned down on adjacency and on interaction: this is the sum test s input validation, and the same round is making the sum test decide voiding."
}

```json { "status": "resolved", "chosen_option": "fix-now", "rationale": "[CR-62] OVERRIDES the recommender. It is the same jq expression the CR-57 fix must open, and it is the residue of round 3 s own CR-55 fix, which checked type == number and thereby admitted 1.5 and -3 while §3 says integer. A negative claim deflates the sum test the CR-57/CR-58 work is making load-bearing, so leaving it undermines the fix landing beside it. Resolved by the driver under the operator's standing authority to run the QA phase to completion, stopping only on a blocking decision. Where this resolution differs from disposition-recommend.sh's answer it says so explicitly and gives the reason; the recommender scores each finding in isolation and cannot see that five of these are one recurring class.", "rejected_alternative": "defer-to-issue matches the Low severity and neither input occurs here today. Turned down on adjacency and on interaction: this is the sum test s input validation, and the same round is making the sum test decide voiding." } ```

jbr870 commented

Author

Owner

{
  "status": "resolved",
  "chosen_option": "fix-now",
  "rationale": "[CR-63] OVERRIDES the recommender. One line, and it is the single counterexample to round 3 s central claim. The fixer reported the class closed after sweeping three files; the sweep found a surviving restatement in a fourth, and one that is already narrower than §2 today rather than merely drift-prone. Leaving the one known counterexample unfixed while recording that the class is closed would put a false statement on the record. Resolved by the driver under the operator's standing authority to run the QA phase to completion, stopping only on a blocking decision. Where this resolution differs from disposition-recommend.sh's answer it says so explicitly and gives the reason; the recommender scores each finding in isolation and cannot see that five of these are one recurring class.",
  "rejected_alternative": "accept was considered because the following sentence mitigates it (a pointer, not a second copy) and the severity is genuinely Low. Turned down because the cost is one line and the value is that the round s own claim becomes true."
}

```json { "status": "resolved", "chosen_option": "fix-now", "rationale": "[CR-63] OVERRIDES the recommender. One line, and it is the single counterexample to round 3 s central claim. The fixer reported the class closed after sweeping three files; the sweep found a surviving restatement in a fourth, and one that is already narrower than §2 today rather than merely drift-prone. Leaving the one known counterexample unfixed while recording that the class is closed would put a false statement on the record. Resolved by the driver under the operator's standing authority to run the QA phase to completion, stopping only on a blocking decision. Where this resolution differs from disposition-recommend.sh's answer it says so explicitly and gives the reason; the recommender scores each finding in isolation and cannot see that five of these are one recurring class.", "rejected_alternative": "accept was considered because the following sentence mitigates it (a pointer, not a second copy) and the severity is genuinely Low. Turned down because the cost is one line and the value is that the round s own claim becomes true." } ```

jbr870 commented

2026-08-26 15:51:36 +00:00

Author

Owner

{
  "status": "resolved",
  "chosen_option": "defer-to-issue",
  "rationale": "[CR-64] This is a measured LIMIT, not a defect: CR-47 s guard detects vocabulary drift and not disposition drift, which is why the driver read step 4 in full rather than trusting the green. Recording the measurement is the useful act; strengthening the guard so it checks disposition is the same design question already deferred to #257, and answering it inside a ten-line round would be the category error #257 exists to avoid. Resolved by the driver under the operator's standing authority to run the QA phase to completion, stopping only on a blocking decision. Where this resolution differs from disposition-recommend.sh's answer it says so explicitly and gives the reason; the recommender scores each finding in isolation and cannot see that five of these are one recurring class.",
  "rejected_alternative": "fix-now was tempting because CR-58 is precisely the disposition drift this guard cannot see, so the limit has already cost something. Turned down because a guard that checks disposition needs a way to express intended disposition, which is design, and because CR-58 is being fixed on this round regardless."
}

```json { "status": "resolved", "chosen_option": "defer-to-issue", "rationale": "[CR-64] This is a measured LIMIT, not a defect: CR-47 s guard detects vocabulary drift and not disposition drift, which is why the driver read step 4 in full rather than trusting the green. Recording the measurement is the useful act; strengthening the guard so it checks disposition is the same design question already deferred to #257, and answering it inside a ten-line round would be the category error #257 exists to avoid. Resolved by the driver under the operator's standing authority to run the QA phase to completion, stopping only on a blocking decision. Where this resolution differs from disposition-recommend.sh's answer it says so explicitly and gives the reason; the recommender scores each finding in isolation and cannot see that five of these are one recurring class.", "rejected_alternative": "fix-now was tempting because CR-58 is precisely the disposition drift this guard cannot see, so the limit has already cost something. Turned down because a guard that checks disposition needs a way to express intended disposition, which is design, and because CR-58 is being fixed on this round regardless." } ```

jbr870 commented

Author

Owner

{
  "status": "resolved",
  "chosen_option": "fix-now",
  "rationale": "[CR-65] OVERRIDES the recommender. It is the same sentence CR-58 rewrites and the same branch CR-57 corrects, so the marginal cost is zero. It also matters for the round s purpose: step 4 s unknown branch currently prescribes dispatch-time remedies for a triage-time decision, and the branch that routes an unjudgeable overrun is exactly the one CR-57 is making consequential. A reader following it literally at triage would try to reassign work that has already run. Resolved by the driver under the operator's standing authority to run the QA phase to completion, stopping only on a blocking decision. Where this resolution differs from disposition-recommend.sh's answer it says so explicitly and gives the reason; the recommender scores each finding in isolation and cannot see that five of these are one recurring class.",
  "rejected_alternative": "defer-to-issue matches the severity and the sentence is followable by charitable reading. Turned down because the round is rewriting that sentence anyway and because charitable reading is what the contract exists to make unnecessary."
}

```json { "status": "resolved", "chosen_option": "fix-now", "rationale": "[CR-65] OVERRIDES the recommender. It is the same sentence CR-58 rewrites and the same branch CR-57 corrects, so the marginal cost is zero. It also matters for the round s purpose: step 4 s unknown branch currently prescribes dispatch-time remedies for a triage-time decision, and the branch that routes an unjudgeable overrun is exactly the one CR-57 is making consequential. A reader following it literally at triage would try to reassign work that has already run. Resolved by the driver under the operator's standing authority to run the QA phase to completion, stopping only on a blocking decision. Where this resolution differs from disposition-recommend.sh's answer it says so explicitly and gives the reason; the recommender scores each finding in isolation and cannot see that five of these are one recurring class.", "rejected_alternative": "defer-to-issue matches the severity and the sentence is followable by charitable reading. Turned down because the round is rewriting that sentence anyway and because charitable reading is what the contract exists to make unnecessary." } ```

jbr870 referenced this issue

2026-08-26 15:51:58 +00:00

run-resource-claims: eleven parser and vocabulary gaps in the shipped recipes and helpers #256

jbr870 referenced this issue

2026-08-26 15:51:58 +00:00

run-resource-claims: three capability gaps the contract never had — §7 attribution, recursion-guard nonce, malformed-journal fallback #354

jbr870 referenced this issue

2026-08-26 15:51:58 +00:00

A fix lands where the finding pointed, not everywhere the rule lives — six measured instances in one sweep #257

jbr870 commented

2026-08-26 16:35:45 +00:00

Author

Owner

{
  "outcome": "clean",
  "summary": "Round 4 fix stage. All 6 in-scope findings fixed and promoted, including both blockers. CR-57 was closed by adding a fourth verdict to the shared §4 filter rather than by either shape the brief proposed. All four gates green at this commit.",
  "findings": [],
  "artifacts": {
    "fix_commit": "911c9eaadf48de68bf351fc0e6de4a7b498416e9",
    "test_commit": "9926e11",
    "fixed": [
      "CR-56 (blocking)",
      "CR-57 (blocking)",
      "CR-58",
      "CR-62",
      "CR-63",
      "CR-65"
    ],
    "files": [
      "plugin/skills/_shared/procedures/run-resource-claims.md",
      "plugin/skills/_shared/procedures/worktree-discipline.md",
      "scripts/test-run-resource-claims.sh"
    ],
    "gates_at_fix_commit": {
      "lint-conventions.sh": "clean",
      "test-lint-conventions.sh": "29 PASS / 0 FAIL / 0 RED",
      "test-run-resource-claims.sh": "47 PASS / 0 FAIL / 0 RED / 0 XPASS",
      "test-plugin-gates.sh": "17 passed, 0 failed, 0 skipped — run AFTER the commit, since it measures HEAD"
    }
  },
  "notes": {
    "cr57_took_a_third_shape": "The brief offered two fix shapes (pad the overrun record before filtering, or restrict the filter's class union to the keys the overrun names). The fixer took neither, adding a fourth verdict to the SHARED filter instead: `vacant` — a class claimed on exactly one side where that side names []. The argument is that a class is genuinely ambiguous only when the naming side might hold something real; if that side already proved [], the other side's silence has nothing to collide with. It rejected padding on the ground that it converges sparse and padded to byte-identical output, which trips the scenario's own must-still-differ sanity check, and that padding baked into a shared filter risks becoming order-dependent.",
    "the_boundary_was_measured_not_the_happy_path": "`vacant` reaches claim-versus-claim DISPATCH decisions, not only overrun triage, and it widens what is dispatched concurrently — the permissive direction. So the driver tested the boundary. Six cases, all correct: one side [] with the other ABSENT reads vacant, and symmetrically under reversal; one side NON-EMPTY with the other absent stays `unknown` — this is the case that would have been a safety inversion and it does not fire; both sides absent stays `unknown`; both naming the same identity stays `shared`; both [] on one class still vanishes as a true disjoint. CR-62's validity checks survive the change (1.5 and -3 unknown, 4 budget). And CR-57's actual requirement holds: sparse and padded overran_resources now both contain no `unknown`, so both reach the same disposition.",
    "the_class_predicted_its_own_next_instance": "Adding a verdict means §7 step 4 must name it, or CR-47's guard goes red — which is exactly the drift the round-3 class describes, arriving one more time. The fixer saw it and closed it in the same edit rather than discovering it at the sweep. That is the first time on this feature the class has been anticipated instead of measured after the fact.",
    "every_promotion_earned": "Two batteries, driver-run. Reverting the two plugin documents to test_commit 9926e11 while KEEPING the promoted markers put CR-57, CR-58, CR-62, CR-63 and CR-65 back to red. CR-56's fix lives in the harness file that holds the markers, so it got a targeted revert instead — putting its two comparison cases back on separate folders puts it back to red.",
    "driver_probe_defects_this_round": "Two, both invisible from the result and both caught only because each mutation prints a before/after count. A line-scoped sed could not match worktree-discipline's phrase because it is HARD-WRAPPED across lines 91-92 — this repo's own documented wrapped-anchor hazard, biting the probe rather than a gate. And a perl replacement carried unescaped $a[$k], which perl interpolated as its own empty array element and emitted `( | type)`: the filter exited 3, the scenario stayed red, and the reading \"still red, so uncoupled\" was available and wrong. Third and fourth probe defect on this feature; the pattern is stable enough to state — here the probe is about as likely to be wrong as the code, and the probe returning the expected answer is the one to distrust."
  }
}

```json { "outcome": "clean", "summary": "Round 4 fix stage. All 6 in-scope findings fixed and promoted, including both blockers. CR-57 was closed by adding a fourth verdict to the shared §4 filter rather than by either shape the brief proposed. All four gates green at this commit.", "findings": [], "artifacts": { "fix_commit": "911c9eaadf48de68bf351fc0e6de4a7b498416e9", "test_commit": "9926e11", "fixed": [ "CR-56 (blocking)", "CR-57 (blocking)", "CR-58", "CR-62", "CR-63", "CR-65" ], "files": [ "plugin/skills/_shared/procedures/run-resource-claims.md", "plugin/skills/_shared/procedures/worktree-discipline.md", "scripts/test-run-resource-claims.sh" ], "gates_at_fix_commit": { "lint-conventions.sh": "clean", "test-lint-conventions.sh": "29 PASS / 0 FAIL / 0 RED", "test-run-resource-claims.sh": "47 PASS / 0 FAIL / 0 RED / 0 XPASS", "test-plugin-gates.sh": "17 passed, 0 failed, 0 skipped — run AFTER the commit, since it measures HEAD" } }, "notes": { "cr57_took_a_third_shape": "The brief offered two fix shapes (pad the overrun record before filtering, or restrict the filter's class union to the keys the overrun names). The fixer took neither, adding a fourth verdict to the SHARED filter instead: `vacant` — a class claimed on exactly one side where that side names []. The argument is that a class is genuinely ambiguous only when the naming side might hold something real; if that side already proved [], the other side's silence has nothing to collide with. It rejected padding on the ground that it converges sparse and padded to byte-identical output, which trips the scenario's own must-still-differ sanity check, and that padding baked into a shared filter risks becoming order-dependent.", "the_boundary_was_measured_not_the_happy_path": "`vacant` reaches claim-versus-claim DISPATCH decisions, not only overrun triage, and it widens what is dispatched concurrently — the permissive direction. So the driver tested the boundary. Six cases, all correct: one side [] with the other ABSENT reads vacant, and symmetrically under reversal; one side NON-EMPTY with the other absent stays `unknown` — this is the case that would have been a safety inversion and it does not fire; both sides absent stays `unknown`; both naming the same identity stays `shared`; both [] on one class still vanishes as a true disjoint. CR-62's validity checks survive the change (1.5 and -3 unknown, 4 budget). And CR-57's actual requirement holds: sparse and padded overran_resources now both contain no `unknown`, so both reach the same disposition.", "the_class_predicted_its_own_next_instance": "Adding a verdict means §7 step 4 must name it, or CR-47's guard goes red — which is exactly the drift the round-3 class describes, arriving one more time. The fixer saw it and closed it in the same edit rather than discovering it at the sweep. That is the first time on this feature the class has been anticipated instead of measured after the fact.", "every_promotion_earned": "Two batteries, driver-run. Reverting the two plugin documents to test_commit 9926e11 while KEEPING the promoted markers put CR-57, CR-58, CR-62, CR-63 and CR-65 back to red. CR-56's fix lives in the harness file that holds the markers, so it got a targeted revert instead — putting its two comparison cases back on separate folders puts it back to red.", "driver_probe_defects_this_round": "Two, both invisible from the result and both caught only because each mutation prints a before/after count. A line-scoped sed could not match worktree-discipline's phrase because it is HARD-WRAPPED across lines 91-92 — this repo's own documented wrapped-anchor hazard, biting the probe rather than a gate. And a perl replacement carried unescaped $a[$k], which perl interpolated as its own empty array element and emitted `( | type)`: the filter exited 3, the scenario stayed red, and the reading \"still red, so uncoupled\" was available and wrong. Third and fourth probe defect on this feature; the pattern is stable enough to state — here the probe is about as likely to be wrong as the code, and the probe returning the expected answer is the one to distrust." } } ```

jbr870 commented

2026-08-26 17:57:54 +00:00

Author

Owner

{
  "outcome": "issues-found",
  "summary": "SWEEP 4 (round 4 exit gate) — 5 findings against the post-fix tree at 911c9ea. No Critical; three High (CR-66, CR-67, CR-68) block. The round does NOT exit. The operator has authorised a fifth round, scoped at the ROOT CAUSE this sweep identified.",
  "findings": [
    {
      "id": "CR-66",
      "category": "in-scope-blocking",
      "severity": "High",
      "summary": "§4's decision rule has no affirmative branch for a `budget` entry, so the rule as written licenses neither dispatch nor remedy for every pair that claims workers.",
      "reasoning": "The bold rule reads 'empty output — or output made up only of vacant entries — means dispatch concurrently; any shared or unknown entry means apply a remedy.' A budget entry satisfies neither clause. Measured on the shipped filter: the T3-vs-T4 pair the reference journal actually DISPATCHED concurrently returns [{class:workers, verdict:budget}] — not empty, not vacant-only, no shared or unknown — so the rule licenses neither the dispatch that was performed nor a remedy. Disjoint non-empty identities plus workers on both sides give the same budget-only output, and the []+absent case gives [vacant, budget], also stranded because it is not vacant-ONLY. §3's own example claim always carries workers, so every realistic pair produces a budget entry: an implementer coding the stated shape rule serializes everything. This is the residual of the CR-46 Critical surviving its own fix. The budget paragraph lets a charitable reader compose the right answer, but the sentence claiming 'it is the shape that decides' never returns one.",
      "proposed_action": "One clause: output made up only of vacant and/or budget entries (each budget passing the sum test) means dispatch concurrently.",
      "fix_cost": "low",
      "feature_value": "core",
      "adjacent_to_blocking": true
    },
    {
      "id": "CR-67",
      "category": "in-scope-blocking",
      "severity": "High",
      "summary": "CR-57's fix holds only when the peer claims all-`[]` — this repo's own dogfood shape — so the sparse-versus-padded divergence persists for every realistic project.",
      "reasoning": "§7 step 4 now asserts that an overran_resources record omitting a class reads as did-not-overrun, never unknown. Measured against a realistic peer {database:[app_test], port:[4090], workers:4, external:[]}: the sparse record {port:[4080]} yields unknown(database) + unknown(workers) + vacant(external) and disposes to VOID, while the padded record {database:[], port:[4080], workers:0, external:[]} yields budget only and disposes to RECORDED. Same fact, opposite dispositions — CR-57's exact defect, on inputs any project with non-empty claims produces. `vacant` only rescues a class when the PEER side names [], and the CR-57 scenario uses precisely this repo's all-[] peer, which is the only shape the fix covers. `workers` can never be rescued at all: a record omitting workers against any peer naming it is always unknown, always void-pending. Secondary contradiction: journal-template.md prescribes the PADDED shape and the real journal's three corrected overruns are padded, while step 4's new sentence endorses SPARSE — two normative sources now disagree on the spelling that flips the disposition. ROOT CAUSE, now nameable rather than guessed: every round validated against the reference journal, and that journal is all-[]. It is an unrepresentative fixture and four rounds of scenarios inherited its blind spot.",
      "proposed_action": "Define absence semantics so they hold against any peer shape, and reconcile journal-template with step 4 on the canonical spelling.",
      "fix_cost": "medium",
      "feature_value": "core",
      "adjacent_to_blocking": true
    },
    {
      "id": "CR-68",
      "category": "in-scope-blocking",
      "severity": "High",
      "summary": "Nothing in the harness pins `vacant`'s permissive boundary — a mutation that turns the safety inversion on leaves all 47 scenarios green.",
      "reasoning": "Driver-reproduced. Mutating the vacant branch's guard so that ANY one-sided claim becomes vacant — including NON-EMPTY plus absent, which licenses concurrent dispatch onto a resource the silent peer may be holding — leaves the suite at 47 PASS, 0 FAIL, rc=0. Verified the mutation genuinely inverts the boundary first (a non-empty claim against an absent one reads vacant), so this is not a no-op probe. Cause: scenario_cr2_one_side_only_class asserts class PRESENCE via overlap_reports_class, and a vacant entry is present, so the scenario stays green while the entry has changed meaning from 'apply a remedy' to 'dispatch concurrently'. The control direction is pinned — disabling the vacant branch entirely does go red, via CR-57's scenario — so the round's widest change is guarded in exactly one direction, and the unguarded one is the direction §1 says costs hours.",
      "proposed_action": "Assert the verdict, not the presence: pin that NON-EMPTY plus absent stays unknown.",
      "fix_cost": "low",
      "feature_value": "core",
      "adjacent_to_blocking": true
    },
    {
      "id": "CR-69",
      "category": "in-scope-deferrable",
      "severity": "Low",
      "summary": "A present-but-malformed one-sided value gets the right verdict with a false explanation.",
      "reasoning": "Measured: database:\"\", database:{} and database:[[]] on one side with the other absent all yield verdict unknown — the safe answer — but carry why 'absent from a claim, which §3 reads as unknown'. The key was present and the value malformed. Verdict right, message false. Adjacent to but not covered by #256, which is about §7's sed parser rather than the §4 filter's why text.",
      "proposed_action": "Give the malformed-value case its own why.",
      "fix_cost": "low",
      "feature_value": "core",
      "adjacent_to_blocking": true
    },
    {
      "id": "CR-70",
      "category": "in-scope-deferrable",
      "severity": "Low",
      "summary": "CR-57's scenario comment states the reference journal uses the sparse spelling; it uses the padded one.",
      "reasoning": "The journal's three corrected overran_resources entries are all padded. Comment-only — the scenario's logic does not depend on it — but it is a false statement about the evidence sitting directly above the assertion that evidence is supposed to justify, and it is the same claim CR-67 shows the fix was built on.",
      "proposed_action": "Correct the comment.",
      "fix_cost": "low",
      "feature_value": "core",
      "adjacent_to_blocking": true
    }
  ],
  "artifacts": {
    "report_path": ".devwork/feature-qa-intra-run-lane-ownership/code-report.md",
    "journal_path": ".devwork/feature-qa-intra-run-lane-ownership/code-journal.md",
    "dispatch_journal": ".devwork/feature-qa-intra-run-lane-ownership/dispatch-journal.md",
    "swept_head": "911c9ea"
  },
  "notes": {
    "the_root_cause_is_now_nameable": "Four rounds each produced a fix that was correct against this repo's own journal and wrong against a realistic one. The reason is a single unrepresentative fixture: the reference journal claims all-[] on every class, so `vacant` rescues every absent key in it, and four rounds of scenarios inherited that blind spot. CR-67 is the demonstration — the CR-57 fix holds for an all-[] peer and fails for a peer with non-empty databases and ports, which is any project but this one. This is why round 5 is scoped at the cause rather than the instances: every scenario it writes must use a realistic NON-EMPTY peer.",
    "cr68_is_the_one_that_changes_the_picture": "Driver-reproduced. Mutating the vacant guard so ANY one-sided claim reads vacant — including NON-EMPTY plus absent, a genuine safety inversion licensing dispatch onto a resource a peer may hold — leaves the harness at 47 PASS, 0 FAIL, rc=0. The mutation was verified to actually invert the boundary before the suite was run, because four driver probes were wrong earlier in this round and each produced a plausible reading. So the round's widest change is pinned in exactly one direction, and the unguarded direction is the permissive one.",
    "what_is_genuinely_correct": "The sweep reported real negatives and they matter at an exit gate. No false green in the SHIPPED tree and no permissive defect in shipped BEHAVIOUR: all six of the driver's vacant boundary cases reproduce, vacant is unreachable for workers and for malformed naming-side values, CR-62's validity checks survive, §7 step 4 names all five output shapes, and mixed vacant-plus-shared output still routes to a remedy. The a3a0e04 defer-to-source fix held through F6's change — zero consumers restate the decision rule or mention vacant. CR-56's folder collapse broke nothing around it. The §7 recipe run against the real journal extracts 16 of 16 claims lines as valid JSON and step 3a still flags exactly the three known round-1 gaps.",
    "escalation": "The driver escalated rather than opening round 5 on its own judgement, per a commitment made when round 4 was dispatched: anything above Low in §4/§7 again is the signal that the residue may be design work for #257 rather than another patch. The operator chose a fifth round scoped at the root cause, on the grounds that this is the first round where the cause is identified rather than guessed.",
    "disclosure": "The reviewer's disclosure is the most complete of the four sweeps: workers fan-out, the git object store, and — correctly — /tmp/dispatch-scan.txt as a FIXED shared scratch path written and removed by scenario_cr23 on each of its three suite runs. That is the same surface T4 claimed under external in round 2, and the third consecutive sweep to disclose a class the four-key schema has no room for."
  }
}

```json { "outcome": "issues-found", "summary": "SWEEP 4 (round 4 exit gate) — 5 findings against the post-fix tree at 911c9ea. No Critical; three High (CR-66, CR-67, CR-68) block. The round does NOT exit. The operator has authorised a fifth round, scoped at the ROOT CAUSE this sweep identified.", "findings": [ { "id": "CR-66", "category": "in-scope-blocking", "severity": "High", "summary": "§4's decision rule has no affirmative branch for a `budget` entry, so the rule as written licenses neither dispatch nor remedy for every pair that claims workers.", "reasoning": "The bold rule reads 'empty output — or output made up only of vacant entries — means dispatch concurrently; any shared or unknown entry means apply a remedy.' A budget entry satisfies neither clause. Measured on the shipped filter: the T3-vs-T4 pair the reference journal actually DISPATCHED concurrently returns [{class:workers, verdict:budget}] — not empty, not vacant-only, no shared or unknown — so the rule licenses neither the dispatch that was performed nor a remedy. Disjoint non-empty identities plus workers on both sides give the same budget-only output, and the []+absent case gives [vacant, budget], also stranded because it is not vacant-ONLY. §3's own example claim always carries workers, so every realistic pair produces a budget entry: an implementer coding the stated shape rule serializes everything. This is the residual of the CR-46 Critical surviving its own fix. The budget paragraph lets a charitable reader compose the right answer, but the sentence claiming 'it is the shape that decides' never returns one.", "proposed_action": "One clause: output made up only of vacant and/or budget entries (each budget passing the sum test) means dispatch concurrently.", "fix_cost": "low", "feature_value": "core", "adjacent_to_blocking": true }, { "id": "CR-67", "category": "in-scope-blocking", "severity": "High", "summary": "CR-57's fix holds only when the peer claims all-`[]` — this repo's own dogfood shape — so the sparse-versus-padded divergence persists for every realistic project.", "reasoning": "§7 step 4 now asserts that an overran_resources record omitting a class reads as did-not-overrun, never unknown. Measured against a realistic peer {database:[app_test], port:[4090], workers:4, external:[]}: the sparse record {port:[4080]} yields unknown(database) + unknown(workers) + vacant(external) and disposes to VOID, while the padded record {database:[], port:[4080], workers:0, external:[]} yields budget only and disposes to RECORDED. Same fact, opposite dispositions — CR-57's exact defect, on inputs any project with non-empty claims produces. `vacant` only rescues a class when the PEER side names [], and the CR-57 scenario uses precisely this repo's all-[] peer, which is the only shape the fix covers. `workers` can never be rescued at all: a record omitting workers against any peer naming it is always unknown, always void-pending. Secondary contradiction: journal-template.md prescribes the PADDED shape and the real journal's three corrected overruns are padded, while step 4's new sentence endorses SPARSE — two normative sources now disagree on the spelling that flips the disposition. ROOT CAUSE, now nameable rather than guessed: every round validated against the reference journal, and that journal is all-[]. It is an unrepresentative fixture and four rounds of scenarios inherited its blind spot.", "proposed_action": "Define absence semantics so they hold against any peer shape, and reconcile journal-template with step 4 on the canonical spelling.", "fix_cost": "medium", "feature_value": "core", "adjacent_to_blocking": true }, { "id": "CR-68", "category": "in-scope-blocking", "severity": "High", "summary": "Nothing in the harness pins `vacant`'s permissive boundary — a mutation that turns the safety inversion on leaves all 47 scenarios green.", "reasoning": "Driver-reproduced. Mutating the vacant branch's guard so that ANY one-sided claim becomes vacant — including NON-EMPTY plus absent, which licenses concurrent dispatch onto a resource the silent peer may be holding — leaves the suite at 47 PASS, 0 FAIL, rc=0. Verified the mutation genuinely inverts the boundary first (a non-empty claim against an absent one reads vacant), so this is not a no-op probe. Cause: scenario_cr2_one_side_only_class asserts class PRESENCE via overlap_reports_class, and a vacant entry is present, so the scenario stays green while the entry has changed meaning from 'apply a remedy' to 'dispatch concurrently'. The control direction is pinned — disabling the vacant branch entirely does go red, via CR-57's scenario — so the round's widest change is guarded in exactly one direction, and the unguarded one is the direction §1 says costs hours.", "proposed_action": "Assert the verdict, not the presence: pin that NON-EMPTY plus absent stays unknown.", "fix_cost": "low", "feature_value": "core", "adjacent_to_blocking": true }, { "id": "CR-69", "category": "in-scope-deferrable", "severity": "Low", "summary": "A present-but-malformed one-sided value gets the right verdict with a false explanation.", "reasoning": "Measured: database:\"\", database:{} and database:[[]] on one side with the other absent all yield verdict unknown — the safe answer — but carry why 'absent from a claim, which §3 reads as unknown'. The key was present and the value malformed. Verdict right, message false. Adjacent to but not covered by #256, which is about §7's sed parser rather than the §4 filter's why text.", "proposed_action": "Give the malformed-value case its own why.", "fix_cost": "low", "feature_value": "core", "adjacent_to_blocking": true }, { "id": "CR-70", "category": "in-scope-deferrable", "severity": "Low", "summary": "CR-57's scenario comment states the reference journal uses the sparse spelling; it uses the padded one.", "reasoning": "The journal's three corrected overran_resources entries are all padded. Comment-only — the scenario's logic does not depend on it — but it is a false statement about the evidence sitting directly above the assertion that evidence is supposed to justify, and it is the same claim CR-67 shows the fix was built on.", "proposed_action": "Correct the comment.", "fix_cost": "low", "feature_value": "core", "adjacent_to_blocking": true } ], "artifacts": { "report_path": ".devwork/feature-qa-intra-run-lane-ownership/code-report.md", "journal_path": ".devwork/feature-qa-intra-run-lane-ownership/code-journal.md", "dispatch_journal": ".devwork/feature-qa-intra-run-lane-ownership/dispatch-journal.md", "swept_head": "911c9ea" }, "notes": { "the_root_cause_is_now_nameable": "Four rounds each produced a fix that was correct against this repo's own journal and wrong against a realistic one. The reason is a single unrepresentative fixture: the reference journal claims all-[] on every class, so `vacant` rescues every absent key in it, and four rounds of scenarios inherited that blind spot. CR-67 is the demonstration — the CR-57 fix holds for an all-[] peer and fails for a peer with non-empty databases and ports, which is any project but this one. This is why round 5 is scoped at the cause rather than the instances: every scenario it writes must use a realistic NON-EMPTY peer.", "cr68_is_the_one_that_changes_the_picture": "Driver-reproduced. Mutating the vacant guard so ANY one-sided claim reads vacant — including NON-EMPTY plus absent, a genuine safety inversion licensing dispatch onto a resource a peer may hold — leaves the harness at 47 PASS, 0 FAIL, rc=0. The mutation was verified to actually invert the boundary before the suite was run, because four driver probes were wrong earlier in this round and each produced a plausible reading. So the round's widest change is pinned in exactly one direction, and the unguarded direction is the permissive one.", "what_is_genuinely_correct": "The sweep reported real negatives and they matter at an exit gate. No false green in the SHIPPED tree and no permissive defect in shipped BEHAVIOUR: all six of the driver's vacant boundary cases reproduce, vacant is unreachable for workers and for malformed naming-side values, CR-62's validity checks survive, §7 step 4 names all five output shapes, and mixed vacant-plus-shared output still routes to a remedy. The a3a0e04 defer-to-source fix held through F6's change — zero consumers restate the decision rule or mention vacant. CR-56's folder collapse broke nothing around it. The §7 recipe run against the real journal extracts 16 of 16 claims lines as valid JSON and step 3a still flags exactly the three known round-1 gaps.", "escalation": "The driver escalated rather than opening round 5 on its own judgement, per a commitment made when round 4 was dispatched: anything above Low in §4/§7 again is the signal that the residue may be design work for #257 rather than another patch. The operator chose a fifth round scoped at the root cause, on the grounds that this is the first round where the cause is identified rather than guessed.", "disclosure": "The reviewer's disclosure is the most complete of the four sweeps: workers fan-out, the git object store, and — correctly — /tmp/dispatch-scan.txt as a FIXED shared scratch path written and removed by scenario_cr23 on each of its three suite runs. That is the same surface T4 claimed under external in round 2, and the third consecutive sweep to disclose a class the four-key schema has no room for." } } ```

jbr870 commented

2026-08-26 17:57:58 +00:00

Author

Owner

{
  "next_state": "qa",
  "produced": [
    {
      "kind": "qa-report",
      "ref": "2274",
      "summary": "code phase=fix — 6 findings fixed incl. the vacant verdict, all 4 gates green"
    },
    {
      "kind": "qa-report",
      "ref": "latest",
      "summary": "code phase=validate — sweep 4, 5 findings, 3 High blocking"
    },
    {
      "kind": "code-bundle",
      "ref": "911c9ea",
      "summary": "the swept HEAD: fix commit 911c9ea on test_commit 9926e11"
    }
  ],
  "findings": [
    {
      "category": "in-scope-blocking",
      "severity": "high",
      "summary": "[code CR-66] §4's decision rule has no affirmative branch for a `budget` entry, so the rule as written licenses neither dispatch nor remedy for every pair that claims workers.",
      "reasoning": "The bold rule reads 'empty output — or output made up only of vacant entries — means dispatch concurrently; any shared or unknown entry means apply a remedy.' A budget entry satisfies neither clause. Measured on the shipped filter: the T3-vs-T4 pair the reference journal actually DISPATCHED concurrently returns [{class:workers, verdict:budget}] — not empty, not vacant-only, no shared or unknown — so the rule licenses neither the dispatch that was performed nor a remedy. Disjoint non-empty identities plus workers on both sides give the same budget-only output, and the []+absent case gives [vacant, budget], also stranded because it is not vacant-ONLY. §3's own example claim always carries workers, so every realistic pair produces a budget entry: an implementer coding the stated shape rule serializes everything. This is the residual of the CR-46 Critical surviving its own fix. The budget paragraph lets a charitable reader compose the right answer, but the sentence claiming 'it is the shape that decides' never returns one.",
      "proposed_action": "One clause: output made up only of vacant and/or budget entries (each budget passing the sum test) means dispatch concurrently.",
      "fix_cost": "low",
      "feature_value": "core",
      "adjacent_to_blocking": true,
      "id": "F-PO-43-8-1"
    },
    {
      "category": "in-scope-blocking",
      "severity": "high",
      "summary": "[code CR-67] CR-57's fix holds only when the peer claims all-`[]` — this repo's own dogfood shape — so the sparse-versus-padded divergence persists for every realistic project.",
      "reasoning": "§7 step 4 now asserts that an overran_resources record omitting a class reads as did-not-overrun, never unknown. Measured against a realistic peer {database:[app_test], port:[4090], workers:4, external:[]}: the sparse record {port:[4080]} yields unknown(database) + unknown(workers) + vacant(external) and disposes to VOID, while the padded record {database:[], port:[4080], workers:0, external:[]} yields budget only and disposes to RECORDED. Same fact, opposite dispositions — CR-57's exact defect, on inputs any project with non-empty claims produces. `vacant` only rescues a class when the PEER side names [], and the CR-57 scenario uses precisely this repo's all-[] peer, which is the only shape the fix covers. `workers` can never be rescued at all: a record omitting workers against any peer naming it is always unknown, always void-pending. Secondary contradiction: journal-template.md prescribes the PADDED shape and the real journal's three corrected overruns are padded, while step 4's new sentence endorses SPARSE — two normative sources now disagree on the spelling that flips the disposition. ROOT CAUSE, now nameable rather than guessed: every round validated against the reference journal, and that journal is all-[]. It is an unrepresentative fixture and four rounds of scenarios inherited its blind spot.",
      "proposed_action": "Define absence semantics so they hold against any peer shape, and reconcile journal-template with step 4 on the canonical spelling.",
      "fix_cost": "medium",
      "feature_value": "core",
      "adjacent_to_blocking": true,
      "id": "F-PO-43-8-2"
    },
    {
      "category": "in-scope-blocking",
      "severity": "high",
      "summary": "[code CR-68] Nothing in the harness pins `vacant`'s permissive boundary — a mutation that turns the safety inversion on leaves all 47 scenarios green.",
      "reasoning": "Driver-reproduced. Mutating the vacant branch's guard so that ANY one-sided claim becomes vacant — including NON-EMPTY plus absent, which licenses concurrent dispatch onto a resource the silent peer may be holding — leaves the suite at 47 PASS, 0 FAIL, rc=0. Verified the mutation genuinely inverts the boundary first (a non-empty claim against an absent one reads vacant), so this is not a no-op probe. Cause: scenario_cr2_one_side_only_class asserts class PRESENCE via overlap_reports_class, and a vacant entry is present, so the scenario stays green while the entry has changed meaning from 'apply a remedy' to 'dispatch concurrently'. The control direction is pinned — disabling the vacant branch entirely does go red, via CR-57's scenario — so the round's widest change is guarded in exactly one direction, and the unguarded one is the direction §1 says costs hours.",
      "proposed_action": "Assert the verdict, not the presence: pin that NON-EMPTY plus absent stays unknown.",
      "fix_cost": "low",
      "feature_value": "core",
      "adjacent_to_blocking": true,
      "id": "F-PO-43-8-3"
    },
    {
      "category": "in-scope-deferrable",
      "severity": "low",
      "summary": "[code CR-69] A present-but-malformed one-sided value gets the right verdict with a false explanation.",
      "reasoning": "Measured: database:\"\", database:{} and database:[[]] on one side with the other absent all yield verdict unknown — the safe answer — but carry why 'absent from a claim, which §3 reads as unknown'. The key was present and the value malformed. Verdict right, message false. Adjacent to but not covered by #256, which is about §7's sed parser rather than the §4 filter's why text.",
      "proposed_action": "Give the malformed-value case its own why.",
      "fix_cost": "low",
      "feature_value": "core",
      "adjacent_to_blocking": true,
      "id": "F-PO-43-8-4"
    },
    {
      "category": "in-scope-deferrable",
      "severity": "low",
      "summary": "[code CR-70] CR-57's scenario comment states the reference journal uses the sparse spelling; it uses the padded one.",
      "reasoning": "The journal's three corrected overran_resources entries are all padded. Comment-only — the scenario's logic does not depend on it — but it is a false statement about the evidence sitting directly above the assertion that evidence is supposed to justify, and it is the same claim CR-67 shows the fix was built on.",
      "proposed_action": "Correct the comment.",
      "fix_cost": "low",
      "feature_value": "core",
      "adjacent_to_blocking": true,
      "id": "F-PO-43-8-5"
    }
  ],
  "pending_decisions": [
    {
      "id": "D-PO-43-8-1",
      "type": "scope-disposition",
      "blocking": false,
      "question": "[CR-69] A present-but-malformed one-sided value gets the right verdict with a false explanation. — fix now, spawn a follow-up issue, or accept?",
      "options": [
        "fix-now",
        "defer-to-issue",
        "accept"
      ],
      "recommended": "defer-to-issue",
      "finding_ref": "F-PO-43-8-4",
      "reasoning": "Computed by disposition-recommend.sh from the finding's axes. Full evidence in the sweep qa-report:v1 (domain=code, phase=validate)."
    },
    {
      "id": "D-PO-43-8-2",
      "type": "scope-disposition",
      "blocking": false,
      "question": "[CR-70] CR-57's scenario comment states the reference journal uses the sparse spelling; it uses the padded one. — fix now, spawn a follow-up issue, or accept?",
      "options": [
        "fix-now",
        "defer-to-issue",
        "accept"
      ],
      "recommended": "defer-to-issue",
      "finding_ref": "F-PO-43-8-5",
      "reasoning": "Computed by disposition-recommend.sh from the finding's axes. Full evidence in the sweep qa-report:v1 (domain=code, phase=validate)."
    }
  ],
  "suite": {
    "source": "git",
    "sha": "911c9eaadf48de68bf351fc0e6de4a7b498416e9",
    "dirty": false
  }
}

```json { "next_state": "qa", "produced": [ { "kind": "qa-report", "ref": "2274", "summary": "code phase=fix — 6 findings fixed incl. the vacant verdict, all 4 gates green" }, { "kind": "qa-report", "ref": "latest", "summary": "code phase=validate — sweep 4, 5 findings, 3 High blocking" }, { "kind": "code-bundle", "ref": "911c9ea", "summary": "the swept HEAD: fix commit 911c9ea on test_commit 9926e11" } ], "findings": [ { "category": "in-scope-blocking", "severity": "high", "summary": "[code CR-66] §4's decision rule has no affirmative branch for a `budget` entry, so the rule as written licenses neither dispatch nor remedy for every pair that claims workers.", "reasoning": "The bold rule reads 'empty output — or output made up only of vacant entries — means dispatch concurrently; any shared or unknown entry means apply a remedy.' A budget entry satisfies neither clause. Measured on the shipped filter: the T3-vs-T4 pair the reference journal actually DISPATCHED concurrently returns [{class:workers, verdict:budget}] — not empty, not vacant-only, no shared or unknown — so the rule licenses neither the dispatch that was performed nor a remedy. Disjoint non-empty identities plus workers on both sides give the same budget-only output, and the []+absent case gives [vacant, budget], also stranded because it is not vacant-ONLY. §3's own example claim always carries workers, so every realistic pair produces a budget entry: an implementer coding the stated shape rule serializes everything. This is the residual of the CR-46 Critical surviving its own fix. The budget paragraph lets a charitable reader compose the right answer, but the sentence claiming 'it is the shape that decides' never returns one.", "proposed_action": "One clause: output made up only of vacant and/or budget entries (each budget passing the sum test) means dispatch concurrently.", "fix_cost": "low", "feature_value": "core", "adjacent_to_blocking": true, "id": "F-PO-43-8-1" }, { "category": "in-scope-blocking", "severity": "high", "summary": "[code CR-67] CR-57's fix holds only when the peer claims all-`[]` — this repo's own dogfood shape — so the sparse-versus-padded divergence persists for every realistic project.", "reasoning": "§7 step 4 now asserts that an overran_resources record omitting a class reads as did-not-overrun, never unknown. Measured against a realistic peer {database:[app_test], port:[4090], workers:4, external:[]}: the sparse record {port:[4080]} yields unknown(database) + unknown(workers) + vacant(external) and disposes to VOID, while the padded record {database:[], port:[4080], workers:0, external:[]} yields budget only and disposes to RECORDED. Same fact, opposite dispositions — CR-57's exact defect, on inputs any project with non-empty claims produces. `vacant` only rescues a class when the PEER side names [], and the CR-57 scenario uses precisely this repo's all-[] peer, which is the only shape the fix covers. `workers` can never be rescued at all: a record omitting workers against any peer naming it is always unknown, always void-pending. Secondary contradiction: journal-template.md prescribes the PADDED shape and the real journal's three corrected overruns are padded, while step 4's new sentence endorses SPARSE — two normative sources now disagree on the spelling that flips the disposition. ROOT CAUSE, now nameable rather than guessed: every round validated against the reference journal, and that journal is all-[]. It is an unrepresentative fixture and four rounds of scenarios inherited its blind spot.", "proposed_action": "Define absence semantics so they hold against any peer shape, and reconcile journal-template with step 4 on the canonical spelling.", "fix_cost": "medium", "feature_value": "core", "adjacent_to_blocking": true, "id": "F-PO-43-8-2" }, { "category": "in-scope-blocking", "severity": "high", "summary": "[code CR-68] Nothing in the harness pins `vacant`'s permissive boundary — a mutation that turns the safety inversion on leaves all 47 scenarios green.", "reasoning": "Driver-reproduced. Mutating the vacant branch's guard so that ANY one-sided claim becomes vacant — including NON-EMPTY plus absent, which licenses concurrent dispatch onto a resource the silent peer may be holding — leaves the suite at 47 PASS, 0 FAIL, rc=0. Verified the mutation genuinely inverts the boundary first (a non-empty claim against an absent one reads vacant), so this is not a no-op probe. Cause: scenario_cr2_one_side_only_class asserts class PRESENCE via overlap_reports_class, and a vacant entry is present, so the scenario stays green while the entry has changed meaning from 'apply a remedy' to 'dispatch concurrently'. The control direction is pinned — disabling the vacant branch entirely does go red, via CR-57's scenario — so the round's widest change is guarded in exactly one direction, and the unguarded one is the direction §1 says costs hours.", "proposed_action": "Assert the verdict, not the presence: pin that NON-EMPTY plus absent stays unknown.", "fix_cost": "low", "feature_value": "core", "adjacent_to_blocking": true, "id": "F-PO-43-8-3" }, { "category": "in-scope-deferrable", "severity": "low", "summary": "[code CR-69] A present-but-malformed one-sided value gets the right verdict with a false explanation.", "reasoning": "Measured: database:\"\", database:{} and database:[[]] on one side with the other absent all yield verdict unknown — the safe answer — but carry why 'absent from a claim, which §3 reads as unknown'. The key was present and the value malformed. Verdict right, message false. Adjacent to but not covered by #256, which is about §7's sed parser rather than the §4 filter's why text.", "proposed_action": "Give the malformed-value case its own why.", "fix_cost": "low", "feature_value": "core", "adjacent_to_blocking": true, "id": "F-PO-43-8-4" }, { "category": "in-scope-deferrable", "severity": "low", "summary": "[code CR-70] CR-57's scenario comment states the reference journal uses the sparse spelling; it uses the padded one.", "reasoning": "The journal's three corrected overran_resources entries are all padded. Comment-only — the scenario's logic does not depend on it — but it is a false statement about the evidence sitting directly above the assertion that evidence is supposed to justify, and it is the same claim CR-67 shows the fix was built on.", "proposed_action": "Correct the comment.", "fix_cost": "low", "feature_value": "core", "adjacent_to_blocking": true, "id": "F-PO-43-8-5" } ], "pending_decisions": [ { "id": "D-PO-43-8-1", "type": "scope-disposition", "blocking": false, "question": "[CR-69] A present-but-malformed one-sided value gets the right verdict with a false explanation. — fix now, spawn a follow-up issue, or accept?", "options": [ "fix-now", "defer-to-issue", "accept" ], "recommended": "defer-to-issue", "finding_ref": "F-PO-43-8-4", "reasoning": "Computed by disposition-recommend.sh from the finding's axes. Full evidence in the sweep qa-report:v1 (domain=code, phase=validate)." }, { "id": "D-PO-43-8-2", "type": "scope-disposition", "blocking": false, "question": "[CR-70] CR-57's scenario comment states the reference journal uses the sparse spelling; it uses the padded one. — fix now, spawn a follow-up issue, or accept?", "options": [ "fix-now", "defer-to-issue", "accept" ], "recommended": "defer-to-issue", "finding_ref": "F-PO-43-8-5", "reasoning": "Computed by disposition-recommend.sh from the finding's axes. Full evidence in the sweep qa-report:v1 (domain=code, phase=validate)." } ], "suite": { "source": "git", "sha": "911c9eaadf48de68bf351fc0e6de4a7b498416e9", "dirty": false } } ```

jbr870 commented

2026-08-26 17:58:25 +00:00

Author

Owner

{
  "status": "resolved",
  "chosen_option": "fix-now",
  "rationale": "[CR-69] Same jq expression the three blocking findings must open, and the fix is one why string. The verdict is already correct — unknown, the safe answer — so nothing is at risk today; what is wrong is that the message tells a reader the key was absent when it was present and malformed, which is the wrong thing to go looking for when this fires in a real project. Round 5 is scoped at a root cause about misleading evidence, and shipping a filter that explains itself falsely sits badly inside that scope. Resolved by the driver under the operator's standing authority to run the QA phase to completion, stopping only on a blocking decision. Where this resolution differs from disposition-recommend.sh's answer it says so explicitly and gives the reason; the recommender scores each finding in isolation and cannot see that five of these are one recurring class.",
  "rejected_alternative": "defer-to-issue was arguable and matches the Low severity. Turned down on adjacency: the fixer is inside this branch for CR-66 and CR-67 regardless, and a one-string correction deferred to a separate issue costs more to re-open than to make."
}

```json { "status": "resolved", "chosen_option": "fix-now", "rationale": "[CR-69] Same jq expression the three blocking findings must open, and the fix is one why string. The verdict is already correct — unknown, the safe answer — so nothing is at risk today; what is wrong is that the message tells a reader the key was absent when it was present and malformed, which is the wrong thing to go looking for when this fires in a real project. Round 5 is scoped at a root cause about misleading evidence, and shipping a filter that explains itself falsely sits badly inside that scope. Resolved by the driver under the operator's standing authority to run the QA phase to completion, stopping only on a blocking decision. Where this resolution differs from disposition-recommend.sh's answer it says so explicitly and gives the reason; the recommender scores each finding in isolation and cannot see that five of these are one recurring class.", "rejected_alternative": "defer-to-issue was arguable and matches the Low severity. Turned down on adjacency: the fixer is inside this branch for CR-66 and CR-67 regardless, and a one-string correction deferred to a separate issue costs more to re-open than to make." } ```

jbr870 commented

2026-08-26 17:58:25 +00:00

Author

Owner

{
  "status": "resolved",
  "chosen_option": "fix-now",
  "rationale": "[CR-70] One comment, in the scenario the round is rewriting anyway — and the comment asserts exactly the thing CR-67 proves false. It says the reference journal uses the sparse spelling; the journal s three corrected entries are padded. That false statement sits directly above the assertion it is supposed to justify, and it is the same mistaken belief the round-4 fix was built on, so leaving it in place preserves the reasoning that produced the defect. Resolved by the driver under the operator's standing authority to run the QA phase to completion, stopping only on a blocking decision. Where this resolution differs from disposition-recommend.sh's answer it says so explicitly and gives the reason; the recommender scores each finding in isolation and cannot see that five of these are one recurring class.",
  "rejected_alternative": "accept was considered because the comment is inert — no logic depends on it. Turned down because this round s whole subject is a fix built on an unrepresentative reading of the evidence, and a comment restating that reading is the most likely way the next reader repeats it."
}

```json { "status": "resolved", "chosen_option": "fix-now", "rationale": "[CR-70] One comment, in the scenario the round is rewriting anyway — and the comment asserts exactly the thing CR-67 proves false. It says the reference journal uses the sparse spelling; the journal s three corrected entries are padded. That false statement sits directly above the assertion it is supposed to justify, and it is the same mistaken belief the round-4 fix was built on, so leaving it in place preserves the reasoning that produced the defect. Resolved by the driver under the operator's standing authority to run the QA phase to completion, stopping only on a blocking decision. Where this resolution differs from disposition-recommend.sh's answer it says so explicitly and gives the reason; the recommender scores each finding in isolation and cannot see that five of these are one recurring class.", "rejected_alternative": "accept was considered because the comment is inert — no logic depends on it. Turned down because this round s whole subject is a fix built on an unrepresentative reading of the evidence, and a comment restating that reading is the most likely way the next reader repeats it." } ```

jbr870 commented

2026-08-26 18:58:54 +00:00

Author

Owner

{
  "outcome": "clean",
  "summary": "Round 5 fix stage. All 5 in-scope findings fixed and promoted, including all three blockers. CR-67 was closed by putting the asymmetry in the CALLER — a padding wrapper in §7 step 4 — leaving the symmetric §4 filter that dispatch relies on untouched. All four gates green at this commit.",
  "findings": [],
  "artifacts": {
    "fix_commit": "9f88f148797ced5d4b0115c141f4fdec66e8c615",
    "test_commit": "404ff40",
    "fixed": [
      "CR-66 (blocking)",
      "CR-67 (blocking)",
      "CR-68 (blocking)",
      "CR-69",
      "CR-70"
    ],
    "files": [
      "plugin/skills/_shared/procedures/run-resource-claims.md",
      "plugin/skills/_shared/procedures/journal-template.md",
      "scripts/test-run-resource-claims.sh"
    ],
    "gates_at_fix_commit": {
      "lint-conventions.sh": "clean",
      "test-lint-conventions.sh": "29 PASS / 0 FAIL / 0 RED",
      "test-run-resource-claims.sh": "52 PASS / 0 FAIL / 0 RED / 0 XPASS",
      "test-plugin-gates.sh": "17 passed, 0 failed, 0 skipped — run AFTER the commit, since it measures HEAD"
    }
  },
  "notes": {
    "the_refusal_was_the_valuable_part": "On its first pass the fixer REFUSED to fix CR-67 and gave a mechanism: the §4 filter is argument-order symmetric and content-blind, so it cannot distinguish an overrun RECORD (absence means proven not-touched) from a CLAIM (absence means unknown). The only way to rescue a sparse record through that filter is to make absent-plus-non-empty read `vacant` — which is CR-68's forbidden inversion seen from the other side. The driver TESTED that reasoning rather than accepting it: the filter is symmetric on every probe, and CR-67's rescue condition and CR-68's prohibition are literally the same unordered pair {absent, non-empty}. Refusing was correct. It is the first time an actor on this feature hit a real architectural conflict and declined to paper over it, and it is exactly what the fix brief's escape hatch existed for. Round 4's blockers were created by the opposite choice — a fix to triage semantics that quietly widened dispatch.",
    "where_the_driver_disagreed": "The fixer named the sound path — an asymmetric step-4 procedure padding the record before invoking the symmetric filter — and then set it aside as out of a fix stage's scope. The driver disagreed and sent it back: it is a normalization wrapper of about eight lines, it leaves the filter dispatch uses untouched, and the round was authorised at the cause rather than at instances. $REC and $PEER arrive in FIXED ORDER by calling convention, never inferred from content, because nothing in the JSON could tell them apart. The asymmetry now lives where the side-labelling is actually known.",
    "an_enforcement_path_at_last": "Step 3b enforces the padded write-shape in the same executable style step 3a uses for CR-36. 'A rule with no enforcement path is a rule that will be missed' is the most repeated finding on this feature — CR-26, CR-36, CR-59 — and this is the first round to close one by BUILDING the path rather than restating the rule.",
    "the_rewritten_scenario_was_checked_hardest": "CR-67's scenario was rewritten this round to follow the contract's new procedure. That is the 'weaken the test' move if done carelessly, and a rewritten scenario that cannot fail is how this feature produced SEVEN dead assertions. So the driver required it to fail with the fix removed and verified that independently: deleting only the padding fence makes it fail, with exactly one collateral failure — itself. The fixer also built in its own sensitivity check, running a neutered no-op stand-in for the padding step and requiring a different disposition.",
    "safety_boundary_unmoved": "Verified rather than assumed. The CR-69 change touches explanation text only; every altered branch still yields `unknown`. All six `vacant` boundary cases and the CR-62 validity cases read exactly as before — including NON-EMPTY plus absent staying `unknown`, which is the case that would be an inversion.",
    "every_promotion_earned": "Reverting the two plugin documents to test_commit 404ff40 while KEEPING the promoted markers puts CR-66, CR-67 and CR-69 back to red. CR-68 and CR-70 live in the harness file that holds the markers and were checked by targeted mutation instead.",
    "disclosure_note": "The fixer disclosed, unprompted, that editing CR-67's scenario body fell outside its original brief boundary and was done on the driver's direct in-thread authorisation rather than unilaterally."
  }
}

```json { "outcome": "clean", "summary": "Round 5 fix stage. All 5 in-scope findings fixed and promoted, including all three blockers. CR-67 was closed by putting the asymmetry in the CALLER — a padding wrapper in §7 step 4 — leaving the symmetric §4 filter that dispatch relies on untouched. All four gates green at this commit.", "findings": [], "artifacts": { "fix_commit": "9f88f148797ced5d4b0115c141f4fdec66e8c615", "test_commit": "404ff40", "fixed": [ "CR-66 (blocking)", "CR-67 (blocking)", "CR-68 (blocking)", "CR-69", "CR-70" ], "files": [ "plugin/skills/_shared/procedures/run-resource-claims.md", "plugin/skills/_shared/procedures/journal-template.md", "scripts/test-run-resource-claims.sh" ], "gates_at_fix_commit": { "lint-conventions.sh": "clean", "test-lint-conventions.sh": "29 PASS / 0 FAIL / 0 RED", "test-run-resource-claims.sh": "52 PASS / 0 FAIL / 0 RED / 0 XPASS", "test-plugin-gates.sh": "17 passed, 0 failed, 0 skipped — run AFTER the commit, since it measures HEAD" } }, "notes": { "the_refusal_was_the_valuable_part": "On its first pass the fixer REFUSED to fix CR-67 and gave a mechanism: the §4 filter is argument-order symmetric and content-blind, so it cannot distinguish an overrun RECORD (absence means proven not-touched) from a CLAIM (absence means unknown). The only way to rescue a sparse record through that filter is to make absent-plus-non-empty read `vacant` — which is CR-68's forbidden inversion seen from the other side. The driver TESTED that reasoning rather than accepting it: the filter is symmetric on every probe, and CR-67's rescue condition and CR-68's prohibition are literally the same unordered pair {absent, non-empty}. Refusing was correct. It is the first time an actor on this feature hit a real architectural conflict and declined to paper over it, and it is exactly what the fix brief's escape hatch existed for. Round 4's blockers were created by the opposite choice — a fix to triage semantics that quietly widened dispatch.", "where_the_driver_disagreed": "The fixer named the sound path — an asymmetric step-4 procedure padding the record before invoking the symmetric filter — and then set it aside as out of a fix stage's scope. The driver disagreed and sent it back: it is a normalization wrapper of about eight lines, it leaves the filter dispatch uses untouched, and the round was authorised at the cause rather than at instances. $REC and $PEER arrive in FIXED ORDER by calling convention, never inferred from content, because nothing in the JSON could tell them apart. The asymmetry now lives where the side-labelling is actually known.", "an_enforcement_path_at_last": "Step 3b enforces the padded write-shape in the same executable style step 3a uses for CR-36. 'A rule with no enforcement path is a rule that will be missed' is the most repeated finding on this feature — CR-26, CR-36, CR-59 — and this is the first round to close one by BUILDING the path rather than restating the rule.", "the_rewritten_scenario_was_checked_hardest": "CR-67's scenario was rewritten this round to follow the contract's new procedure. That is the 'weaken the test' move if done carelessly, and a rewritten scenario that cannot fail is how this feature produced SEVEN dead assertions. So the driver required it to fail with the fix removed and verified that independently: deleting only the padding fence makes it fail, with exactly one collateral failure — itself. The fixer also built in its own sensitivity check, running a neutered no-op stand-in for the padding step and requiring a different disposition.", "safety_boundary_unmoved": "Verified rather than assumed. The CR-69 change touches explanation text only; every altered branch still yields `unknown`. All six `vacant` boundary cases and the CR-62 validity cases read exactly as before — including NON-EMPTY plus absent staying `unknown`, which is the case that would be an inversion.", "every_promotion_earned": "Reverting the two plugin documents to test_commit 404ff40 while KEEPING the promoted markers puts CR-66, CR-67 and CR-69 back to red. CR-68 and CR-70 live in the harness file that holds the markers and were checked by targeted mutation instead.", "disclosure_note": "The fixer disclosed, unprompted, that editing CR-67's scenario body fell outside its original brief boundary and was done on the driver's direct in-thread authorisation rather than unilaterally." } } ```

jbr870 commented

2026-08-26 19:17:53 +00:00

Author

Owner

{
  "outcome": "issues-found",
  "summary": "SWEEP 5 (round 5 exit gate) — 6 findings against the post-fix tree at 9f88f14. No Critical; one High (CR-71) blocks. Materially different from the four sweeps before it: NO false green and NO safety inversion anywhere in shipped behaviour.",
  "findings": [
    {
      "id": "CR-71",
      "category": "in-scope-blocking",
      "severity": "High",
      "summary": "Step 3b — the enforcement check round 5 added — cannot parse the quoted-key spelling the reference journal actually uses, and has zero harness coverage.",
      "reasoning": "Driver-reproduced against the shipped recipe. Its four regexes match only the bare-key spelling, while the reference journal writes every real overran_resources with quoted keys, a spelling step 3's own sed explicitly tolerates. Measured on three inputs journal-template permits: a fully PADDED record with QUOTED keys is falsely reported 'SPARSE overran_resources: missing database port workers external'; the same record with bare keys is correctly not reported; a genuinely sparse record is reported, but with the same wrong missing-all-four text. So on the real journal today the three known sparse records are flagged for the wrong reason, and the day someone writes a padded quoted-key record — which the template permits — the check reports a false positive. Compounding: grep finds ZERO mentions of step 3b or SPARSE in either harness, so the round's proudest addition shipped untested. This is the class the check was built to close — a rule whose enforcement path does not work is a rule with no enforcement path — occurring inside the fix for that class.",
      "proposed_action": "Tolerate an optional quote on each key, and add a scenario in each direction.",
      "fix_cost": "low",
      "feature_value": "core",
      "adjacent_to_blocking": true
    },
    {
      "id": "CR-72",
      "category": "in-scope-deferrable",
      "severity": "Medium",
      "summary": "A REC/PEER swap at step 4's padding wrapper is undetectable from data and fails permissive when the peer claim is sparse.",
      "reasoning": "Measured. Record {database:[app_test], port:[], workers:0, external:[]} against a sparse peer claim {workers:2}: correct order disposes to void_pending_remedy, because the peer's silence on database is genuinely unknown; swapped order disposes to RECORDED, because padding the PEER converts its absent keys into [], turning 'unknown' into 'proven empty' and rescuing the overrun. The reverse fixture fails conservative. Undetectability is inherent and deliberate — the wrapper exists precisely because nothing in the JSON distinguishes a record from a claim — so this is design residue rather than a defect in the mechanism. But the recipe's only defence is a comment inside one fence, and step 4's prose never shows the invocation.",
      "proposed_action": "Show the exact call with role-locked variable names, so a swap must be typed twice to happen.",
      "fix_cost": "low",
      "feature_value": "core",
      "adjacent_to_blocking": true
    },
    {
      "id": "CR-73",
      "category": "in-scope-deferrable",
      "severity": "Medium",
      "summary": "Two behaviour-changing mutants of the padding wrapper survive the entire suite.",
      "reasoning": "Measured, full-suite green (52 PASS, rc 0) under each. (a) Dropping '+ ($peer | keys)' makes a sparse record against a peer carrying a project-named class flip recorded to void_pending_remedy. (b) Padding workers with [] instead of 0 makes a record omitting workers against a realistic peer flip the same way. scenario_cr67 pins exactly one cell — a workers-only sparse record against a four-class peer. Both mutants fail CONSERVATIVE, so there is no safety inversion, but this is the assertion-cannot-fail class that has produced seven dead assertions on this feature. The sweep also checked a third mutant, dropping the literal workers from the pad list, and reported it semantically neutral rather than counting it — the distrust-your-probes rule applied to its own findings.",
      "proposed_action": "Extend scenario_cr67 to cover the peer-keys union and the workers-zero pad.",
      "fix_cost": "low",
      "feature_value": "core",
      "adjacent_to_blocking": true
    },
    {
      "id": "CR-74",
      "category": "in-scope-deferrable",
      "severity": "Medium",
      "summary": "Step 4's restatement of the sum test garbles the arithmetic — read literally it always oversubscribes — and the sum test itself is still prose-only.",
      "reasoning": "Two halves. The wording half is a defect: step 4 says 'total the overrun against every actor's claimed workers still open, plus the pool — and void only on oversubscription', which includes the pool in the total and therefore always oversubscribes; §4's fence comment has it right as 'collision when total > pool'. CR-58's pairwise-tell regex does not catch this because the restatement is no longer pairwise, it is arithmetically wrong instead. The capability half is the recurring class: §4's rule and step 4's budget branch both route the COMMON realistic outcome — every §3-conformant pair claims workers, so output is budget-only — to a sum test that exists nowhere in executable form; grep confirms no add, reduce or tonumber in the document beyond port expansion and the pad wrapper, and the only implementation is the harness's repo-local helper, which is pairwise rather than global.",
      "proposed_action": "Fix the arithmetic wording now; defer the executable global sum test to #354 as a capability the contract never had.",
      "fix_cost": "low",
      "feature_value": "core",
      "adjacent_to_blocking": true
    },
    {
      "id": "CR-75",
      "category": "in-scope-deferrable",
      "severity": "Low",
      "summary": "Step 4's vacant bullet misexplains the realistic case.",
      "reasoning": "It says a padded not-overrun class 'reads vacant'. Measured: against a peer naming that class non-empty, the padded [] produces NO entry at all — the intersection is empty and the final select drops it. Vacant appears only when the peer also omits the class. Disposition is unaffected either way, so this is right verdict, wrong reason — CR-69's class, in text round 5 itself added.",
      "proposed_action": "Correct the explanation.",
      "fix_cost": "low",
      "feature_value": "core",
      "adjacent_to_blocking": true
    },
    {
      "id": "CR-76",
      "category": "in-scope-deferrable",
      "severity": "Low",
      "summary": "A step 3b SPARSE hit has no stated consequence.",
      "reasoning": "Step 3a's case has one — the step 4 unknown branch voids pending a re-run. After a 3b hit, step 4's wrapper proceeds to rescue the same sparse record to 'recorded', and nothing says whether SPARSE demands a DISCOVERY correction, downgrades confidence, or is purely informational. A check that fires and then changes nothing is the shape of a rule that gets ignored.",
      "proposed_action": "State the consequence of a SPARSE hit.",
      "fix_cost": "low",
      "feature_value": "core",
      "adjacent_to_blocking": true
    }
  ],
  "artifacts": {
    "report_path": ".devwork/feature-qa-intra-run-lane-ownership/code-report.md",
    "journal_path": ".devwork/feature-qa-intra-run-lane-ownership/code-journal.md",
    "dispatch_journal": ".devwork/feature-qa-intra-run-lane-ownership/dispatch-journal.md",
    "swept_head": "9f88f14"
  },
  "notes": {
    "the_negative_result_is_the_headline": "For the first time on this feature, an executing adversarial sweep found NO false green and NO safety inversion in shipped behaviour — the two classes that ended rounds 1 through 4. It verified the driver's own claims independently rather than restating them: scenario_cr67 is genuinely live (deleting the pad fence gives rc=1 with exactly one FAIL), every §4 boundary holds in BOTH argument orders, the wrapper is idempotent and never overwrites a record-named class, step 3's sed converts all 19 real claims lines to valid JSON, and defer-to-source held through round 5 with zero consumers restating the padded-versus-sparse rule.",
    "cr71_is_the_irony_and_the_blocker": "Driver-reproduced on three inputs journal-template permits. Step 3b — the enforcement check round 5 added, which the fix report called 'an enforcement path at last' — matches only BARE-key spelling. A fully PADDED record with QUOTED keys, the spelling the reference journal actually uses and which step 3's own sed explicitly tolerates, is falsely reported 'SPARSE ... missing database port workers external'. Bare-key padded is correctly silent; genuinely sparse is reported but with the same wrong missing-all-four text. And grep finds ZERO mentions of step 3b or SPARSE in either harness. So the round that finally built an enforcement path shipped it broken against its own repo's records and untested — the same class it was built to close, occurring inside the fix for that class.",
    "cr72_is_design_residue_not_a_defect": "The REC/PEER swap is undetectable from data BY DESIGN — that is precisely why the wrapper exists — and the sweep measured that a swap fails PERMISSIVE when the peer claim is sparse, conservative otherwise. Recorded as residue with a cheap hardening (show the call with role-locked names) rather than treated as a flaw in the mechanism.",
    "cr73_is_test_debt_in_the_safe_direction": "Two behaviour-changing mutants of the pad wrapper survive the whole suite; both fail CONSERVATIVE, so no inversion. Notably the sweep checked a THIRD mutant, found it semantically neutral, and reported it as such rather than counting it — the distrust-your-probes discipline applied to its own findings, which is the first time an actor has done that unprompted.",
    "round_6_scope": "Narrow and non-architectural, per the sweep's own judgement that it would not open a full round for the rest. CR-71 blocks; CR-72, CR-73, CR-74 (the garbled arithmetic half), CR-75 and CR-76 are all one-liners or one-scenario extensions in the same fence or the same file. The EXECUTABLE global sum test half of CR-74 defers to #354 as a capability the contract never had."
  }
}

```json { "outcome": "issues-found", "summary": "SWEEP 5 (round 5 exit gate) — 6 findings against the post-fix tree at 9f88f14. No Critical; one High (CR-71) blocks. Materially different from the four sweeps before it: NO false green and NO safety inversion anywhere in shipped behaviour.", "findings": [ { "id": "CR-71", "category": "in-scope-blocking", "severity": "High", "summary": "Step 3b — the enforcement check round 5 added — cannot parse the quoted-key spelling the reference journal actually uses, and has zero harness coverage.", "reasoning": "Driver-reproduced against the shipped recipe. Its four regexes match only the bare-key spelling, while the reference journal writes every real overran_resources with quoted keys, a spelling step 3's own sed explicitly tolerates. Measured on three inputs journal-template permits: a fully PADDED record with QUOTED keys is falsely reported 'SPARSE overran_resources: missing database port workers external'; the same record with bare keys is correctly not reported; a genuinely sparse record is reported, but with the same wrong missing-all-four text. So on the real journal today the three known sparse records are flagged for the wrong reason, and the day someone writes a padded quoted-key record — which the template permits — the check reports a false positive. Compounding: grep finds ZERO mentions of step 3b or SPARSE in either harness, so the round's proudest addition shipped untested. This is the class the check was built to close — a rule whose enforcement path does not work is a rule with no enforcement path — occurring inside the fix for that class.", "proposed_action": "Tolerate an optional quote on each key, and add a scenario in each direction.", "fix_cost": "low", "feature_value": "core", "adjacent_to_blocking": true }, { "id": "CR-72", "category": "in-scope-deferrable", "severity": "Medium", "summary": "A REC/PEER swap at step 4's padding wrapper is undetectable from data and fails permissive when the peer claim is sparse.", "reasoning": "Measured. Record {database:[app_test], port:[], workers:0, external:[]} against a sparse peer claim {workers:2}: correct order disposes to void_pending_remedy, because the peer's silence on database is genuinely unknown; swapped order disposes to RECORDED, because padding the PEER converts its absent keys into [], turning 'unknown' into 'proven empty' and rescuing the overrun. The reverse fixture fails conservative. Undetectability is inherent and deliberate — the wrapper exists precisely because nothing in the JSON distinguishes a record from a claim — so this is design residue rather than a defect in the mechanism. But the recipe's only defence is a comment inside one fence, and step 4's prose never shows the invocation.", "proposed_action": "Show the exact call with role-locked variable names, so a swap must be typed twice to happen.", "fix_cost": "low", "feature_value": "core", "adjacent_to_blocking": true }, { "id": "CR-73", "category": "in-scope-deferrable", "severity": "Medium", "summary": "Two behaviour-changing mutants of the padding wrapper survive the entire suite.", "reasoning": "Measured, full-suite green (52 PASS, rc 0) under each. (a) Dropping '+ ($peer | keys)' makes a sparse record against a peer carrying a project-named class flip recorded to void_pending_remedy. (b) Padding workers with [] instead of 0 makes a record omitting workers against a realistic peer flip the same way. scenario_cr67 pins exactly one cell — a workers-only sparse record against a four-class peer. Both mutants fail CONSERVATIVE, so there is no safety inversion, but this is the assertion-cannot-fail class that has produced seven dead assertions on this feature. The sweep also checked a third mutant, dropping the literal workers from the pad list, and reported it semantically neutral rather than counting it — the distrust-your-probes rule applied to its own findings.", "proposed_action": "Extend scenario_cr67 to cover the peer-keys union and the workers-zero pad.", "fix_cost": "low", "feature_value": "core", "adjacent_to_blocking": true }, { "id": "CR-74", "category": "in-scope-deferrable", "severity": "Medium", "summary": "Step 4's restatement of the sum test garbles the arithmetic — read literally it always oversubscribes — and the sum test itself is still prose-only.", "reasoning": "Two halves. The wording half is a defect: step 4 says 'total the overrun against every actor's claimed workers still open, plus the pool — and void only on oversubscription', which includes the pool in the total and therefore always oversubscribes; §4's fence comment has it right as 'collision when total > pool'. CR-58's pairwise-tell regex does not catch this because the restatement is no longer pairwise, it is arithmetically wrong instead. The capability half is the recurring class: §4's rule and step 4's budget branch both route the COMMON realistic outcome — every §3-conformant pair claims workers, so output is budget-only — to a sum test that exists nowhere in executable form; grep confirms no add, reduce or tonumber in the document beyond port expansion and the pad wrapper, and the only implementation is the harness's repo-local helper, which is pairwise rather than global.", "proposed_action": "Fix the arithmetic wording now; defer the executable global sum test to #354 as a capability the contract never had.", "fix_cost": "low", "feature_value": "core", "adjacent_to_blocking": true }, { "id": "CR-75", "category": "in-scope-deferrable", "severity": "Low", "summary": "Step 4's vacant bullet misexplains the realistic case.", "reasoning": "It says a padded not-overrun class 'reads vacant'. Measured: against a peer naming that class non-empty, the padded [] produces NO entry at all — the intersection is empty and the final select drops it. Vacant appears only when the peer also omits the class. Disposition is unaffected either way, so this is right verdict, wrong reason — CR-69's class, in text round 5 itself added.", "proposed_action": "Correct the explanation.", "fix_cost": "low", "feature_value": "core", "adjacent_to_blocking": true }, { "id": "CR-76", "category": "in-scope-deferrable", "severity": "Low", "summary": "A step 3b SPARSE hit has no stated consequence.", "reasoning": "Step 3a's case has one — the step 4 unknown branch voids pending a re-run. After a 3b hit, step 4's wrapper proceeds to rescue the same sparse record to 'recorded', and nothing says whether SPARSE demands a DISCOVERY correction, downgrades confidence, or is purely informational. A check that fires and then changes nothing is the shape of a rule that gets ignored.", "proposed_action": "State the consequence of a SPARSE hit.", "fix_cost": "low", "feature_value": "core", "adjacent_to_blocking": true } ], "artifacts": { "report_path": ".devwork/feature-qa-intra-run-lane-ownership/code-report.md", "journal_path": ".devwork/feature-qa-intra-run-lane-ownership/code-journal.md", "dispatch_journal": ".devwork/feature-qa-intra-run-lane-ownership/dispatch-journal.md", "swept_head": "9f88f14" }, "notes": { "the_negative_result_is_the_headline": "For the first time on this feature, an executing adversarial sweep found NO false green and NO safety inversion in shipped behaviour — the two classes that ended rounds 1 through 4. It verified the driver's own claims independently rather than restating them: scenario_cr67 is genuinely live (deleting the pad fence gives rc=1 with exactly one FAIL), every §4 boundary holds in BOTH argument orders, the wrapper is idempotent and never overwrites a record-named class, step 3's sed converts all 19 real claims lines to valid JSON, and defer-to-source held through round 5 with zero consumers restating the padded-versus-sparse rule.", "cr71_is_the_irony_and_the_blocker": "Driver-reproduced on three inputs journal-template permits. Step 3b — the enforcement check round 5 added, which the fix report called 'an enforcement path at last' — matches only BARE-key spelling. A fully PADDED record with QUOTED keys, the spelling the reference journal actually uses and which step 3's own sed explicitly tolerates, is falsely reported 'SPARSE ... missing database port workers external'. Bare-key padded is correctly silent; genuinely sparse is reported but with the same wrong missing-all-four text. And grep finds ZERO mentions of step 3b or SPARSE in either harness. So the round that finally built an enforcement path shipped it broken against its own repo's records and untested — the same class it was built to close, occurring inside the fix for that class.", "cr72_is_design_residue_not_a_defect": "The REC/PEER swap is undetectable from data BY DESIGN — that is precisely why the wrapper exists — and the sweep measured that a swap fails PERMISSIVE when the peer claim is sparse, conservative otherwise. Recorded as residue with a cheap hardening (show the call with role-locked names) rather than treated as a flaw in the mechanism.", "cr73_is_test_debt_in_the_safe_direction": "Two behaviour-changing mutants of the pad wrapper survive the whole suite; both fail CONSERVATIVE, so no inversion. Notably the sweep checked a THIRD mutant, found it semantically neutral, and reported it as such rather than counting it — the distrust-your-probes discipline applied to its own findings, which is the first time an actor has done that unprompted.", "round_6_scope": "Narrow and non-architectural, per the sweep's own judgement that it would not open a full round for the rest. CR-71 blocks; CR-72, CR-73, CR-74 (the garbled arithmetic half), CR-75 and CR-76 are all one-liners or one-scenario extensions in the same fence or the same file. The EXECUTABLE global sum test half of CR-74 defers to #354 as a capability the contract never had." } } ```

jbr870 commented

2026-08-26 19:17:57 +00:00

Author

Owner

{
  "next_state": "qa",
  "produced": [
    {
      "kind": "qa-report",
      "ref": "2322",
      "summary": "code phase=fix — 5 findings fixed incl. the asymmetric padding wrapper, all 4 gates green"
    },
    {
      "kind": "qa-report",
      "ref": "latest",
      "summary": "code phase=validate — sweep 5, 6 findings, 1 High blocking, no false green"
    },
    {
      "kind": "code-bundle",
      "ref": "9f88f14",
      "summary": "the swept HEAD: fix commit 9f88f14 on test_commit 404ff40"
    }
  ],
  "findings": [
    {
      "category": "in-scope-blocking",
      "severity": "high",
      "summary": "[code CR-71] Step 3b — the enforcement check round 5 added — cannot parse the quoted-key spelling the reference journal actually uses, and has zero harness coverage.",
      "reasoning": "Driver-reproduced against the shipped recipe. Its four regexes match only the bare-key spelling, while the reference journal writes every real overran_resources with quoted keys, a spelling step 3's own sed explicitly tolerates. Measured on three inputs journal-template permits: a fully PADDED record with QUOTED keys is falsely reported 'SPARSE overran_resources: missing database port workers external'; the same record with bare keys is correctly not reported; a genuinely sparse record is reported, but with the same wrong missing-all-four text. So on the real journal today the three known sparse records are flagged for the wrong reason, and the day someone writes a padded quoted-key record — which the template permits — the check reports a false positive. Compounding: grep finds ZERO mentions of step 3b or SPARSE in either harness, so the round's proudest addition shipped untested. This is the class the check was built to close — a rule whose enforcement path does not work is a rule with no enforcement path — occurring inside the fix for that class.",
      "proposed_action": "Tolerate an optional quote on each key, and add a scenario in each direction.",
      "fix_cost": "low",
      "feature_value": "core",
      "adjacent_to_blocking": true,
      "id": "F-PO-43-9-1"
    },
    {
      "category": "in-scope-deferrable",
      "severity": "medium",
      "summary": "[code CR-72] A REC/PEER swap at step 4's padding wrapper is undetectable from data and fails permissive when the peer claim is sparse.",
      "reasoning": "Measured. Record {database:[app_test], port:[], workers:0, external:[]} against a sparse peer claim {workers:2}: correct order disposes to void_pending_remedy, because the peer's silence on database is genuinely unknown; swapped order disposes to RECORDED, because padding the PEER converts its absent keys into [], turning 'unknown' into 'proven empty' and rescuing the overrun. The reverse fixture fails conservative. Undetectability is inherent and deliberate — the wrapper exists precisely because nothing in the JSON distinguishes a record from a claim — so this is design residue rather than a defect in the mechanism. But the recipe's only defence is a comment inside one fence, and step 4's prose never shows the invocation.",
      "proposed_action": "Show the exact call with role-locked variable names, so a swap must be typed twice to happen.",
      "fix_cost": "low",
      "feature_value": "core",
      "adjacent_to_blocking": true,
      "id": "F-PO-43-9-2"
    },
    {
      "category": "in-scope-deferrable",
      "severity": "medium",
      "summary": "[code CR-73] Two behaviour-changing mutants of the padding wrapper survive the entire suite.",
      "reasoning": "Measured, full-suite green (52 PASS, rc 0) under each. (a) Dropping '+ ($peer | keys)' makes a sparse record against a peer carrying a project-named class flip recorded to void_pending_remedy. (b) Padding workers with [] instead of 0 makes a record omitting workers against a realistic peer flip the same way. scenario_cr67 pins exactly one cell — a workers-only sparse record against a four-class peer. Both mutants fail CONSERVATIVE, so there is no safety inversion, but this is the assertion-cannot-fail class that has produced seven dead assertions on this feature. The sweep also checked a third mutant, dropping the literal workers from the pad list, and reported it semantically neutral rather than counting it — the distrust-your-probes rule applied to its own findings.",
      "proposed_action": "Extend scenario_cr67 to cover the peer-keys union and the workers-zero pad.",
      "fix_cost": "low",
      "feature_value": "core",
      "adjacent_to_blocking": true,
      "id": "F-PO-43-9-3"
    },
    {
      "category": "in-scope-deferrable",
      "severity": "medium",
      "summary": "[code CR-74] Step 4's restatement of the sum test garbles the arithmetic — read literally it always oversubscribes — and the sum test itself is still prose-only.",
      "reasoning": "Two halves. The wording half is a defect: step 4 says 'total the overrun against every actor's claimed workers still open, plus the pool — and void only on oversubscription', which includes the pool in the total and therefore always oversubscribes; §4's fence comment has it right as 'collision when total > pool'. CR-58's pairwise-tell regex does not catch this because the restatement is no longer pairwise, it is arithmetically wrong instead. The capability half is the recurring class: §4's rule and step 4's budget branch both route the COMMON realistic outcome — every §3-conformant pair claims workers, so output is budget-only — to a sum test that exists nowhere in executable form; grep confirms no add, reduce or tonumber in the document beyond port expansion and the pad wrapper, and the only implementation is the harness's repo-local helper, which is pairwise rather than global.",
      "proposed_action": "Fix the arithmetic wording now; defer the executable global sum test to #354 as a capability the contract never had.",
      "fix_cost": "low",
      "feature_value": "core",
      "adjacent_to_blocking": true,
      "id": "F-PO-43-9-4"
    },
    {
      "category": "in-scope-deferrable",
      "severity": "low",
      "summary": "[code CR-75] Step 4's vacant bullet misexplains the realistic case.",
      "reasoning": "It says a padded not-overrun class 'reads vacant'. Measured: against a peer naming that class non-empty, the padded [] produces NO entry at all — the intersection is empty and the final select drops it. Vacant appears only when the peer also omits the class. Disposition is unaffected either way, so this is right verdict, wrong reason — CR-69's class, in text round 5 itself added.",
      "proposed_action": "Correct the explanation.",
      "fix_cost": "low",
      "feature_value": "core",
      "adjacent_to_blocking": true,
      "id": "F-PO-43-9-5"
    },
    {
      "category": "in-scope-deferrable",
      "severity": "low",
      "summary": "[code CR-76] A step 3b SPARSE hit has no stated consequence.",
      "reasoning": "Step 3a's case has one — the step 4 unknown branch voids pending a re-run. After a 3b hit, step 4's wrapper proceeds to rescue the same sparse record to 'recorded', and nothing says whether SPARSE demands a DISCOVERY correction, downgrades confidence, or is purely informational. A check that fires and then changes nothing is the shape of a rule that gets ignored.",
      "proposed_action": "State the consequence of a SPARSE hit.",
      "fix_cost": "low",
      "feature_value": "core",
      "adjacent_to_blocking": true,
      "id": "F-PO-43-9-6"
    }
  ],
  "pending_decisions": [
    {
      "id": "D-PO-43-9-1",
      "type": "scope-disposition",
      "blocking": false,
      "question": "[CR-72] A REC/PEER swap at step 4's padding wrapper is undetectable from data and fails permissive when the peer claim is sparse. — fix now, spawn a follow-up issue, or accept?",
      "options": [
        "fix-now",
        "defer-to-issue",
        "accept"
      ],
      "recommended": "defer-to-issue",
      "finding_ref": "F-PO-43-9-2",
      "reasoning": "Computed by disposition-recommend.sh from the finding's axes. Full evidence in the sweep qa-report:v1 (domain=code, phase=validate)."
    },
    {
      "id": "D-PO-43-9-2",
      "type": "scope-disposition",
      "blocking": false,
      "question": "[CR-73] Two behaviour-changing mutants of the padding wrapper survive the entire suite. — fix now, spawn a follow-up issue, or accept?",
      "options": [
        "fix-now",
        "defer-to-issue",
        "accept"
      ],
      "recommended": "defer-to-issue",
      "finding_ref": "F-PO-43-9-3",
      "reasoning": "Computed by disposition-recommend.sh from the finding's axes. Full evidence in the sweep qa-report:v1 (domain=code, phase=validate)."
    },
    {
      "id": "D-PO-43-9-3",
      "type": "scope-disposition",
      "blocking": false,
      "question": "[CR-74] Step 4's restatement of the sum test garbles the arithmetic — read literally it always oversubscribes — and the sum test itself is still prose-only. — fix now, spawn a follow-up issue, or accept?",
      "options": [
        "fix-now",
        "defer-to-issue",
        "accept"
      ],
      "recommended": "defer-to-issue",
      "finding_ref": "F-PO-43-9-4",
      "reasoning": "Computed by disposition-recommend.sh from the finding's axes. Full evidence in the sweep qa-report:v1 (domain=code, phase=validate)."
    },
    {
      "id": "D-PO-43-9-4",
      "type": "scope-disposition",
      "blocking": false,
      "question": "[CR-75] Step 4's vacant bullet misexplains the realistic case. — fix now, spawn a follow-up issue, or accept?",
      "options": [
        "fix-now",
        "defer-to-issue",
        "accept"
      ],
      "recommended": "defer-to-issue",
      "finding_ref": "F-PO-43-9-5",
      "reasoning": "Computed by disposition-recommend.sh from the finding's axes. Full evidence in the sweep qa-report:v1 (domain=code, phase=validate)."
    },
    {
      "id": "D-PO-43-9-5",
      "type": "scope-disposition",
      "blocking": false,
      "question": "[CR-76] A step 3b SPARSE hit has no stated consequence. — fix now, spawn a follow-up issue, or accept?",
      "options": [
        "fix-now",
        "defer-to-issue",
        "accept"
      ],
      "recommended": "defer-to-issue",
      "finding_ref": "F-PO-43-9-6",
      "reasoning": "Computed by disposition-recommend.sh from the finding's axes. Full evidence in the sweep qa-report:v1 (domain=code, phase=validate)."
    }
  ],
  "suite": {
    "source": "git",
    "sha": "9f88f148797ced5d4b0115c141f4fdec66e8c615",
    "dirty": false
  }
}

```json { "next_state": "qa", "produced": [ { "kind": "qa-report", "ref": "2322", "summary": "code phase=fix — 5 findings fixed incl. the asymmetric padding wrapper, all 4 gates green" }, { "kind": "qa-report", "ref": "latest", "summary": "code phase=validate — sweep 5, 6 findings, 1 High blocking, no false green" }, { "kind": "code-bundle", "ref": "9f88f14", "summary": "the swept HEAD: fix commit 9f88f14 on test_commit 404ff40" } ], "findings": [ { "category": "in-scope-blocking", "severity": "high", "summary": "[code CR-71] Step 3b — the enforcement check round 5 added — cannot parse the quoted-key spelling the reference journal actually uses, and has zero harness coverage.", "reasoning": "Driver-reproduced against the shipped recipe. Its four regexes match only the bare-key spelling, while the reference journal writes every real overran_resources with quoted keys, a spelling step 3's own sed explicitly tolerates. Measured on three inputs journal-template permits: a fully PADDED record with QUOTED keys is falsely reported 'SPARSE overran_resources: missing database port workers external'; the same record with bare keys is correctly not reported; a genuinely sparse record is reported, but with the same wrong missing-all-four text. So on the real journal today the three known sparse records are flagged for the wrong reason, and the day someone writes a padded quoted-key record — which the template permits — the check reports a false positive. Compounding: grep finds ZERO mentions of step 3b or SPARSE in either harness, so the round's proudest addition shipped untested. This is the class the check was built to close — a rule whose enforcement path does not work is a rule with no enforcement path — occurring inside the fix for that class.", "proposed_action": "Tolerate an optional quote on each key, and add a scenario in each direction.", "fix_cost": "low", "feature_value": "core", "adjacent_to_blocking": true, "id": "F-PO-43-9-1" }, { "category": "in-scope-deferrable", "severity": "medium", "summary": "[code CR-72] A REC/PEER swap at step 4's padding wrapper is undetectable from data and fails permissive when the peer claim is sparse.", "reasoning": "Measured. Record {database:[app_test], port:[], workers:0, external:[]} against a sparse peer claim {workers:2}: correct order disposes to void_pending_remedy, because the peer's silence on database is genuinely unknown; swapped order disposes to RECORDED, because padding the PEER converts its absent keys into [], turning 'unknown' into 'proven empty' and rescuing the overrun. The reverse fixture fails conservative. Undetectability is inherent and deliberate — the wrapper exists precisely because nothing in the JSON distinguishes a record from a claim — so this is design residue rather than a defect in the mechanism. But the recipe's only defence is a comment inside one fence, and step 4's prose never shows the invocation.", "proposed_action": "Show the exact call with role-locked variable names, so a swap must be typed twice to happen.", "fix_cost": "low", "feature_value": "core", "adjacent_to_blocking": true, "id": "F-PO-43-9-2" }, { "category": "in-scope-deferrable", "severity": "medium", "summary": "[code CR-73] Two behaviour-changing mutants of the padding wrapper survive the entire suite.", "reasoning": "Measured, full-suite green (52 PASS, rc 0) under each. (a) Dropping '+ ($peer | keys)' makes a sparse record against a peer carrying a project-named class flip recorded to void_pending_remedy. (b) Padding workers with [] instead of 0 makes a record omitting workers against a realistic peer flip the same way. scenario_cr67 pins exactly one cell — a workers-only sparse record against a four-class peer. Both mutants fail CONSERVATIVE, so there is no safety inversion, but this is the assertion-cannot-fail class that has produced seven dead assertions on this feature. The sweep also checked a third mutant, dropping the literal workers from the pad list, and reported it semantically neutral rather than counting it — the distrust-your-probes rule applied to its own findings.", "proposed_action": "Extend scenario_cr67 to cover the peer-keys union and the workers-zero pad.", "fix_cost": "low", "feature_value": "core", "adjacent_to_blocking": true, "id": "F-PO-43-9-3" }, { "category": "in-scope-deferrable", "severity": "medium", "summary": "[code CR-74] Step 4's restatement of the sum test garbles the arithmetic — read literally it always oversubscribes — and the sum test itself is still prose-only.", "reasoning": "Two halves. The wording half is a defect: step 4 says 'total the overrun against every actor's claimed workers still open, plus the pool — and void only on oversubscription', which includes the pool in the total and therefore always oversubscribes; §4's fence comment has it right as 'collision when total > pool'. CR-58's pairwise-tell regex does not catch this because the restatement is no longer pairwise, it is arithmetically wrong instead. The capability half is the recurring class: §4's rule and step 4's budget branch both route the COMMON realistic outcome — every §3-conformant pair claims workers, so output is budget-only — to a sum test that exists nowhere in executable form; grep confirms no add, reduce or tonumber in the document beyond port expansion and the pad wrapper, and the only implementation is the harness's repo-local helper, which is pairwise rather than global.", "proposed_action": "Fix the arithmetic wording now; defer the executable global sum test to #354 as a capability the contract never had.", "fix_cost": "low", "feature_value": "core", "adjacent_to_blocking": true, "id": "F-PO-43-9-4" }, { "category": "in-scope-deferrable", "severity": "low", "summary": "[code CR-75] Step 4's vacant bullet misexplains the realistic case.", "reasoning": "It says a padded not-overrun class 'reads vacant'. Measured: against a peer naming that class non-empty, the padded [] produces NO entry at all — the intersection is empty and the final select drops it. Vacant appears only when the peer also omits the class. Disposition is unaffected either way, so this is right verdict, wrong reason — CR-69's class, in text round 5 itself added.", "proposed_action": "Correct the explanation.", "fix_cost": "low", "feature_value": "core", "adjacent_to_blocking": true, "id": "F-PO-43-9-5" }, { "category": "in-scope-deferrable", "severity": "low", "summary": "[code CR-76] A step 3b SPARSE hit has no stated consequence.", "reasoning": "Step 3a's case has one — the step 4 unknown branch voids pending a re-run. After a 3b hit, step 4's wrapper proceeds to rescue the same sparse record to 'recorded', and nothing says whether SPARSE demands a DISCOVERY correction, downgrades confidence, or is purely informational. A check that fires and then changes nothing is the shape of a rule that gets ignored.", "proposed_action": "State the consequence of a SPARSE hit.", "fix_cost": "low", "feature_value": "core", "adjacent_to_blocking": true, "id": "F-PO-43-9-6" } ], "pending_decisions": [ { "id": "D-PO-43-9-1", "type": "scope-disposition", "blocking": false, "question": "[CR-72] A REC/PEER swap at step 4's padding wrapper is undetectable from data and fails permissive when the peer claim is sparse. — fix now, spawn a follow-up issue, or accept?", "options": [ "fix-now", "defer-to-issue", "accept" ], "recommended": "defer-to-issue", "finding_ref": "F-PO-43-9-2", "reasoning": "Computed by disposition-recommend.sh from the finding's axes. Full evidence in the sweep qa-report:v1 (domain=code, phase=validate)." }, { "id": "D-PO-43-9-2", "type": "scope-disposition", "blocking": false, "question": "[CR-73] Two behaviour-changing mutants of the padding wrapper survive the entire suite. — fix now, spawn a follow-up issue, or accept?", "options": [ "fix-now", "defer-to-issue", "accept" ], "recommended": "defer-to-issue", "finding_ref": "F-PO-43-9-3", "reasoning": "Computed by disposition-recommend.sh from the finding's axes. Full evidence in the sweep qa-report:v1 (domain=code, phase=validate)." }, { "id": "D-PO-43-9-3", "type": "scope-disposition", "blocking": false, "question": "[CR-74] Step 4's restatement of the sum test garbles the arithmetic — read literally it always oversubscribes — and the sum test itself is still prose-only. — fix now, spawn a follow-up issue, or accept?", "options": [ "fix-now", "defer-to-issue", "accept" ], "recommended": "defer-to-issue", "finding_ref": "F-PO-43-9-4", "reasoning": "Computed by disposition-recommend.sh from the finding's axes. Full evidence in the sweep qa-report:v1 (domain=code, phase=validate)." }, { "id": "D-PO-43-9-4", "type": "scope-disposition", "blocking": false, "question": "[CR-75] Step 4's vacant bullet misexplains the realistic case. — fix now, spawn a follow-up issue, or accept?", "options": [ "fix-now", "defer-to-issue", "accept" ], "recommended": "defer-to-issue", "finding_ref": "F-PO-43-9-5", "reasoning": "Computed by disposition-recommend.sh from the finding's axes. Full evidence in the sweep qa-report:v1 (domain=code, phase=validate)." }, { "id": "D-PO-43-9-5", "type": "scope-disposition", "blocking": false, "question": "[CR-76] A step 3b SPARSE hit has no stated consequence. — fix now, spawn a follow-up issue, or accept?", "options": [ "fix-now", "defer-to-issue", "accept" ], "recommended": "defer-to-issue", "finding_ref": "F-PO-43-9-6", "reasoning": "Computed by disposition-recommend.sh from the finding's axes. Full evidence in the sweep qa-report:v1 (domain=code, phase=validate)." } ], "suite": { "source": "git", "sha": "9f88f148797ced5d4b0115c141f4fdec66e8c615", "dirty": false } } ```

jbr870 commented

Author

Owner

{
  "status": "resolved",
  "chosen_option": "fix-now",
  "rationale": "[CR-72] Cheap and it lands in the fence the blocking CR-71 already opens. The swap is undetectable from data by design — that is the whole reason the wrapper exists — so this is not a flaw to be engineered away but a caller obligation to be made unmistakable. The sweep measured that a swap fails PERMISSIVE when the peer claim is sparse, which is the direction that costs hours, and the mechanism s only current defence is a comment inside one fence while step 4 s prose never shows the invocation at all. Showing the exact call with role-locked names means a swap has to be typed twice to happen. Resolved by the driver under the operator's standing authority to run the QA phase to completion, stopping only on a blocking decision. Where this resolution differs from disposition-recommend.sh's answer it says so explicitly and gives the reason; the recommender scores each finding in isolation and cannot see that five of these are one recurring class.",
  "rejected_alternative": "defer-to-issue matches the Medium severity and there is a real argument that by-convention correctness belongs in a design discussion. Turned down because the hardening is a two-line prose change in a fence already being edited, and because deferring the one cheap mitigation of a known permissive failure is the trade this round exists to stop making."
}

```json { "status": "resolved", "chosen_option": "fix-now", "rationale": "[CR-72] Cheap and it lands in the fence the blocking CR-71 already opens. The swap is undetectable from data by design — that is the whole reason the wrapper exists — so this is not a flaw to be engineered away but a caller obligation to be made unmistakable. The sweep measured that a swap fails PERMISSIVE when the peer claim is sparse, which is the direction that costs hours, and the mechanism s only current defence is a comment inside one fence while step 4 s prose never shows the invocation at all. Showing the exact call with role-locked names means a swap has to be typed twice to happen. Resolved by the driver under the operator's standing authority to run the QA phase to completion, stopping only on a blocking decision. Where this resolution differs from disposition-recommend.sh's answer it says so explicitly and gives the reason; the recommender scores each finding in isolation and cannot see that five of these are one recurring class.", "rejected_alternative": "defer-to-issue matches the Medium severity and there is a real argument that by-convention correctness belongs in a design discussion. Turned down because the hardening is a two-line prose change in a fence already being edited, and because deferring the one cheap mitigation of a known permissive failure is the trade this round exists to stop making." } ```

jbr870 commented

Author

Owner

{
  "status": "resolved",
  "chosen_option": "fix-now",
  "rationale": "[CR-73] Two behaviour-changing mutants surviving the whole suite is the assertion-cannot-fail class that has produced seven dead assertions on this feature, and scenario_cr67 was REWRITTEN last round precisely so it would be honest. It pins one cell; the sweep showed the wrapper has at least three behaviours worth pinning. Both mutants fail conservative so nothing is unsafe today, but the point of a regression test is the day someone edits the wrapper, and on that day this suite would stay green through two of the three changes it could make. Resolved by the driver under the operator's standing authority to run the QA phase to completion, stopping only on a blocking decision. Where this resolution differs from disposition-recommend.sh's answer it says so explicitly and gives the reason; the recommender scores each finding in isolation and cannot see that five of these are one recurring class.",
  "rejected_alternative": "defer-to-issue is defensible because there is no live defect. Turned down because this is test debt in the exact mechanism the round just added, and deferring coverage of new machinery is how the seven dead assertions accumulated in the first place."
}

```json { "status": "resolved", "chosen_option": "fix-now", "rationale": "[CR-73] Two behaviour-changing mutants surviving the whole suite is the assertion-cannot-fail class that has produced seven dead assertions on this feature, and scenario_cr67 was REWRITTEN last round precisely so it would be honest. It pins one cell; the sweep showed the wrapper has at least three behaviours worth pinning. Both mutants fail conservative so nothing is unsafe today, but the point of a regression test is the day someone edits the wrapper, and on that day this suite would stay green through two of the three changes it could make. Resolved by the driver under the operator's standing authority to run the QA phase to completion, stopping only on a blocking decision. Where this resolution differs from disposition-recommend.sh's answer it says so explicitly and gives the reason; the recommender scores each finding in isolation and cannot see that five of these are one recurring class.", "rejected_alternative": "defer-to-issue is defensible because there is no live defect. Turned down because this is test debt in the exact mechanism the round just added, and deferring coverage of new machinery is how the seven dead assertions accumulated in the first place." } ```

jbr870 commented

Author

Owner

{
  "status": "resolved",
  "chosen_option": "fix-now",
  "rationale": "[CR-74] SPLIT deliberately, and only the wording half is taken now. Step 4 currently reads total the overrun against every actor s claimed workers still open, PLUS THE POOL, and void only on oversubscription — which includes the pool in the total and therefore always oversubscribes. That is a live arithmetic defect in a sentence a driver is meant to copy and run, and §4 s own fence comment already has it right, so the fix is to make the restatement agree with the source. The EXECUTABLE global sum test is the other half and is deferred: it is a capability the contract has never had rather than a rule that drifted, which puts it with #354 s set, and building it inside a round scoped at one parsing bug would be the widening this round is explicitly avoiding. Resolved by the driver under the operator's standing authority to run the QA phase to completion, stopping only on a blocking decision. Where this resolution differs from disposition-recommend.sh's answer it says so explicitly and gives the reason; the recommender scores each finding in isolation and cannot see that five of these are one recurring class.",
  "rejected_alternative": "fix-now on BOTH halves was weighed, because the sum test is the last unenforced rule in the contract and the round has been strict about enforcement paths. Turned down on scope: a global sum over all open actors needs a source of truth for who is open, which the recipe does not have, so it is genuinely new mechanism rather than a missing line."
}

```json { "status": "resolved", "chosen_option": "fix-now", "rationale": "[CR-74] SPLIT deliberately, and only the wording half is taken now. Step 4 currently reads total the overrun against every actor s claimed workers still open, PLUS THE POOL, and void only on oversubscription — which includes the pool in the total and therefore always oversubscribes. That is a live arithmetic defect in a sentence a driver is meant to copy and run, and §4 s own fence comment already has it right, so the fix is to make the restatement agree with the source. The EXECUTABLE global sum test is the other half and is deferred: it is a capability the contract has never had rather than a rule that drifted, which puts it with #354 s set, and building it inside a round scoped at one parsing bug would be the widening this round is explicitly avoiding. Resolved by the driver under the operator's standing authority to run the QA phase to completion, stopping only on a blocking decision. Where this resolution differs from disposition-recommend.sh's answer it says so explicitly and gives the reason; the recommender scores each finding in isolation and cannot see that five of these are one recurring class.", "rejected_alternative": "fix-now on BOTH halves was weighed, because the sum test is the last unenforced rule in the contract and the round has been strict about enforcement paths. Turned down on scope: a global sum over all open actors needs a source of truth for who is open, which the recipe does not have, so it is genuinely new mechanism rather than a missing line." } ```

jbr870 commented

2026-08-26 19:18:38 +00:00

Author

Owner

{
  "status": "resolved",
  "chosen_option": "fix-now",
  "rationale": "[CR-75] One sentence, in the bullet CR-74 s wording fix already rewrites, and it is wrong in the same way CR-69 was: right verdict, wrong reason. The bullet says a padded not-overrun class reads vacant; measured, against a peer naming that class non-empty it produces no entry at all. A reader debugging a real triage would go looking for a vacant entry that is not there. Resolved by the driver under the operator's standing authority to run the QA phase to completion, stopping only on a blocking decision. Where this resolution differs from disposition-recommend.sh's answer it says so explicitly and gives the reason; the recommender scores each finding in isolation and cannot see that five of these are one recurring class.",
  "rejected_alternative": "accept was reasonable since the disposition is unaffected either way. Turned down because the text was added by round 5 itself and describes the mechanism round 5 built, so leaving it wrong means shipping a fresh false explanation of new machinery."
}

```json { "status": "resolved", "chosen_option": "fix-now", "rationale": "[CR-75] One sentence, in the bullet CR-74 s wording fix already rewrites, and it is wrong in the same way CR-69 was: right verdict, wrong reason. The bullet says a padded not-overrun class reads vacant; measured, against a peer naming that class non-empty it produces no entry at all. A reader debugging a real triage would go looking for a vacant entry that is not there. Resolved by the driver under the operator's standing authority to run the QA phase to completion, stopping only on a blocking decision. Where this resolution differs from disposition-recommend.sh's answer it says so explicitly and gives the reason; the recommender scores each finding in isolation and cannot see that five of these are one recurring class.", "rejected_alternative": "accept was reasonable since the disposition is unaffected either way. Turned down because the text was added by round 5 itself and describes the mechanism round 5 built, so leaving it wrong means shipping a fresh false explanation of new machinery." } ```

jbr870 commented

Author

Owner

{
  "status": "resolved",
  "chosen_option": "fix-now",
  "rationale": "[CR-76] One clause, adjacent to the blocking CR-71 in the same step. A check that fires and then changes nothing is the shape of a rule that gets ignored, and step 3a — the check 3b was modelled on — does state its consequence. Worse, after a 3b hit the step 4 wrapper proceeds to rescue the very record 3b just flagged, so the two steps currently disagree about whether a sparse record is a problem. Resolved by the driver under the operator's standing authority to run the QA phase to completion, stopping only on a blocking decision. Where this resolution differs from disposition-recommend.sh's answer it says so explicitly and gives the reason; the recommender scores each finding in isolation and cannot see that five of these are one recurring class.",
  "rejected_alternative": "defer-to-issue matches the Low severity. Turned down because the contradiction between 3b firing and step 4 rescuing is the kind of thing that reads as deliberate to the next author, and because CR-71 is already rewriting this step."
}

```json { "status": "resolved", "chosen_option": "fix-now", "rationale": "[CR-76] One clause, adjacent to the blocking CR-71 in the same step. A check that fires and then changes nothing is the shape of a rule that gets ignored, and step 3a — the check 3b was modelled on — does state its consequence. Worse, after a 3b hit the step 4 wrapper proceeds to rescue the very record 3b just flagged, so the two steps currently disagree about whether a sparse record is a problem. Resolved by the driver under the operator's standing authority to run the QA phase to completion, stopping only on a blocking decision. Where this resolution differs from disposition-recommend.sh's answer it says so explicitly and gives the reason; the recommender scores each finding in isolation and cannot see that five of these are one recurring class.", "rejected_alternative": "defer-to-issue matches the Low severity. Turned down because the contradiction between 3b firing and step 4 rescuing is the kind of thing that reads as deliberate to the next author, and because CR-71 is already rewriting this step." } ```

jbr870 referenced this issue

2026-08-26 19:19:02 +00:00

run-resource-claims: three capability gaps the contract never had — §7 attribution, recursion-guard nonce, malformed-journal fallback #354

jbr870 commented

2026-08-27 08:09:16 +00:00

Author

Owner

{
  "outcome": "clean",
  "summary": "Round 6 fix stage. All 6 in-scope findings fixed and promoted, including the blocker. Narrow and non-architectural by design, per the sweep's own recommendation. All four gates green at this commit.",
  "findings": [],
  "artifacts": {
    "fix_commit": "a0536e23affb2053a407942ce2e7d7c7498ed8f7",
    "test_commit": "5053a40",
    "fixed": [
      "CR-71 (blocking)",
      "CR-72",
      "CR-73",
      "CR-74",
      "CR-75",
      "CR-76"
    ],
    "files": [
      "plugin/skills/_shared/procedures/run-resource-claims.md",
      "scripts/test-run-resource-claims.sh"
    ],
    "gates_at_fix_commit": {
      "lint-conventions.sh": "clean",
      "test-lint-conventions.sh": "29 PASS / 0 FAIL / 0 RED",
      "test-run-resource-claims.sh": "58 PASS / 0 FAIL / 0 RED / 0 XPASS",
      "test-plugin-gates.sh": "17 passed, 0 failed, 0 skipped — run AFTER the commit, since it measures HEAD"
    }
  },
  "notes": {
    "cr71_corrected_not_silenced": "Step 3b was round 5's enforcement path — the thing that finally gave a rule a mechanism — and it matched only bare-key spelling, so it fired falsely on the repo's own records and had zero coverage in either harness. The fix was verified in BOTH directions, which is what the finding demanded and what the scenario was deliberately written to require: a padded quoted-key record now produces 0 SPARSE lines, padded bare-key is unaffected, and a genuinely sparse record still produces 1, naming only the classes actually missing. A fix that loosened the regexes until nothing ever fired would not have satisfied the scenario, and should not have.",
    "cr73_is_the_one_checked_directly": "A scenario-strengthening fix cannot be verified by reverting the document, so it was measured against the mutants instead. Applying each wrapper mutant to the SHIPPED tree now makes scenario_cr67 FAIL — dropping the peer-keys union from the pad list, and padding absent workers with [] rather than 0. Both previously passed. That closes the EIGHTH would-be dead assertion on this feature BEFORE it shipped rather than after, which is the first time that has happened here.",
    "every_other_promotion_earned": "Reverting run-resource-claims.md to test_commit 5053a40 while KEEPING the promoted markers puts CR-71, CR-72, CR-74, CR-75 and CR-76 back to red.",
    "cr74_stayed_half_scoped": "Only the arithmetic wording was fixed — step 4 now compares the total against the pool rather than adding the pool into it, matching §4's own formula. The executable global sum test remains deferred to #354, because it needs a source of truth for which actors are currently open and the §7 recipe has no such view. That is new mechanism, not a missing line.",
    "the_wrapped_anchor_hazard_recurred_again": "The fixer hit it twice on CR-75 and once on CR-76, and reported it rather than working around it silently: a normative phrase split across two hash-prefixed comment lines gets a literal hash folded into the middle, breaking the substring match a gate greps for. That hazard has now bitten authoring units in FOUR separate rounds on this issue and one driver probe. It is a repo-wide authoring trap rather than a per-round mistake, and worth carrying into the retrospective."
  }
}

```json { "outcome": "clean", "summary": "Round 6 fix stage. All 6 in-scope findings fixed and promoted, including the blocker. Narrow and non-architectural by design, per the sweep's own recommendation. All four gates green at this commit.", "findings": [], "artifacts": { "fix_commit": "a0536e23affb2053a407942ce2e7d7c7498ed8f7", "test_commit": "5053a40", "fixed": [ "CR-71 (blocking)", "CR-72", "CR-73", "CR-74", "CR-75", "CR-76" ], "files": [ "plugin/skills/_shared/procedures/run-resource-claims.md", "scripts/test-run-resource-claims.sh" ], "gates_at_fix_commit": { "lint-conventions.sh": "clean", "test-lint-conventions.sh": "29 PASS / 0 FAIL / 0 RED", "test-run-resource-claims.sh": "58 PASS / 0 FAIL / 0 RED / 0 XPASS", "test-plugin-gates.sh": "17 passed, 0 failed, 0 skipped — run AFTER the commit, since it measures HEAD" } }, "notes": { "cr71_corrected_not_silenced": "Step 3b was round 5's enforcement path — the thing that finally gave a rule a mechanism — and it matched only bare-key spelling, so it fired falsely on the repo's own records and had zero coverage in either harness. The fix was verified in BOTH directions, which is what the finding demanded and what the scenario was deliberately written to require: a padded quoted-key record now produces 0 SPARSE lines, padded bare-key is unaffected, and a genuinely sparse record still produces 1, naming only the classes actually missing. A fix that loosened the regexes until nothing ever fired would not have satisfied the scenario, and should not have.", "cr73_is_the_one_checked_directly": "A scenario-strengthening fix cannot be verified by reverting the document, so it was measured against the mutants instead. Applying each wrapper mutant to the SHIPPED tree now makes scenario_cr67 FAIL — dropping the peer-keys union from the pad list, and padding absent workers with [] rather than 0. Both previously passed. That closes the EIGHTH would-be dead assertion on this feature BEFORE it shipped rather than after, which is the first time that has happened here.", "every_other_promotion_earned": "Reverting run-resource-claims.md to test_commit 5053a40 while KEEPING the promoted markers puts CR-71, CR-72, CR-74, CR-75 and CR-76 back to red.", "cr74_stayed_half_scoped": "Only the arithmetic wording was fixed — step 4 now compares the total against the pool rather than adding the pool into it, matching §4's own formula. The executable global sum test remains deferred to #354, because it needs a source of truth for which actors are currently open and the §7 recipe has no such view. That is new mechanism, not a missing line.", "the_wrapped_anchor_hazard_recurred_again": "The fixer hit it twice on CR-75 and once on CR-76, and reported it rather than working around it silently: a normative phrase split across two hash-prefixed comment lines gets a literal hash folded into the middle, breaking the substring match a gate greps for. That hazard has now bitten authoring units in FOUR separate rounds on this issue and one driver probe. It is a repo-wide authoring trap rather than a per-round mistake, and worth carrying into the retrospective." } } ```

jbr870 commented

2026-08-27 08:32:19 +00:00

Author

Owner

{
  "outcome": "issues-found",
  "summary": "SWEEP 6 (round 6 exit gate) — 6 findings against the post-fix tree at a0536e2. Two High, and the first PERMISSIVE dead assertion found on this feature. Every round-6 fix held under attack; what failed is adjacent text the round did not touch or only half-fixed.",
  "findings": [
    {
      "id": "CR-77",
      "category": "in-scope-blocking",
      "severity": "High",
      "summary": "Step 4's budget total omits the triaged actor's own claimed workers, and `workers: N` in an overrun record has no defined meaning — so the rule is permissive and, as written, unanswerable.",
      "reasoning": "Driver-confirmed. Step 4 reads 'total the overrun together with every OTHER actor's claimed workers still open, and compare against the pool', while §4's own fence says 'total = the workers claimed by every actor dispatched and not yet released'. The triaged actor's own claim drops out. On §4's OWN worked example — pool 8, two actors each claiming 4, which §4 states do not collide — actor A overrunning by 1 gives step 4 a total of 1+4=5, under the pool, so 'recorded', while true peak load is 4+1+4=9, over it. Any wave dispatched at capacity therefore reads every overrun of excess up to the actor's own claim as recorded. The deeper half: journal-template gives `workers: N` in an overran_resources record no semantics, and its padding rule ('0 if workers was not overrun') is coherent only if N is the EXCESS beyond claim — under which reading step 4's formula is wrong; under the alternative reading (N is total used) the formula works but the padding rule and §5's 'beyond its claim' language do not. This is the same sentence CR-74 rewrote and declared in scope, and it is distinct from the executable sum test deferred to #354: this is the formula's terms, not its mechanisation.",
      "proposed_action": "Define N as the excess beyond claim, and make the total = every open actor's claimed workers (the triaged actor included) plus that excess.",
      "fix_cost": "low",
      "feature_value": "core",
      "adjacent_to_blocking": true
    },
    {
      "id": "CR-78",
      "category": "in-scope-blocking",
      "severity": "High",
      "summary": "journal-template contradicts §7 on what a sparse record means at triage: the template says void pending remedy, the contract says never grounds to void.",
      "reasoning": "journal-template states that a sparse record compared against a peer naming anything real on the omitted classes 'falls through to §3's ordinary absent-key-means-unknown rule and reads as unknown (void pending remedy)', and attributes that to §7 step 4. But since round 5 step 4 pads first — 'Pad first; never hand a raw overran_resources record to this filter directly' — and round 6 added 'a SPARSE record is never grounds to void this triage on its own'. Two canonical documents give opposite verdicts for the same record, and the reference journal contains three genuinely sparse records today. The template's over-voiding reading is precisely the disclosure-punishing inversion §8.4 spends three paragraphs refusing. Nothing in either harness pins that paragraph. On this repo's all-[] journal the two readings converge, which is why five sweeps missed it; against a realistic peer they diverge.",
      "proposed_action": "Update the template sentence to match §7 as it now stands.",
      "fix_cost": "low",
      "feature_value": "core",
      "adjacent_to_blocking": true
    },
    {
      "id": "CR-79",
      "category": "in-scope-blocking",
      "severity": "Medium",
      "summary": "A PERMISSIVE mutant of the padding wrapper survives all 58 scenarios — padding that overwrites real record values instead of only filling silence.",
      "reasoning": "Driver-reproduced with the mutation asserted before the suite ran. Neutralising the wrapper's has($k) guard makes padding overwrite every record value: a record naming database ['app_test'] against a peer co-claiming it becomes [], the shared entry is dropped, and the disposition flips from VOID to RECORDED. The full suite on the mutated tree: rc=0, 58 PASS, 0 FAIL. The document's own prose forbids this ('padding only fills silence, it never overwrites a real value') and the round-5 sweep claimed to have measured never-overwrites, but nothing tests it. This is the ninth would-be dead assertion on this feature and the FIRST in the permissive direction — the eight before it either failed conservative or were caught before shipping. Categorised blocking despite Medium severity for that reason.",
      "proposed_action": "One scenario_cr67 fixture whose record names a non-empty class the peer co-claims, expecting void.",
      "fix_cost": "low",
      "feature_value": "core",
      "adjacent_to_blocking": true
    },
    {
      "id": "CR-80",
      "category": "in-scope-deferrable",
      "severity": "Medium",
      "summary": "A second pad-wrapper mutant survives the suite, conservative direction: dropping `external` from the base class list.",
      "reasoning": "Measured, mutation asserted landed, full suite green on the mutated tree. It survives because every scenario_cr67 and scenario_cr73 fixture uses a peer that names all four classes, so the peer-keys union always rescues the base list and the base list is never exercised on its own. Same class as CR-73, remaining cells. Conservative direction, so nothing is unsafe today.",
      "proposed_action": "A fixture whose peer omits a base class the record also omits.",
      "fix_cost": "low",
      "feature_value": "core",
      "adjacent_to_blocking": true
    },
    {
      "id": "CR-81",
      "category": "in-scope-deferrable",
      "severity": "Medium",
      "summary": "§7's awk checks pin one exact spelling while YAML, the template and step 3's own sed accept more — two false negatives on record-integrity checks, one false positive.",
      "reasoning": "Three executed instances. (a) 'overran_claim:  true' with two spaces — valid YAML — silently disarms step 3a: a journal with that spelling and no overran_resources prints nothing, while the single-space control correctly reports MISSING. A false negative on the record-integrity check. (b) Step 3b false negative: a sparse record whose external value contains the text 'database:' satisfies the /\"?database\"?:/ regex from inside a VALUE, so the missing database key is not reported — and real externals here are free text with colons. (c) Step 3b false positive: a fully padded record with a space before each colon, which step 3's own key-quoting sed explicitly tolerates, is reported SPARSE — so step 3 and step 3b now disagree about the same spelling. These are new instances on the round-5 and round-6 checks rather than the step-3 sed gaps filed as #256, and two of the three weaken a safety check rather than a cosmetic one.",
      "proposed_action": "Tolerate YAML's permitted whitespace, and anchor the key match so a value cannot satisfy it.",
      "fix_cost": "low",
      "feature_value": "core",
      "adjacent_to_blocking": true
    },
    {
      "id": "CR-82",
      "category": "in-scope-deferrable",
      "severity": "Medium",
      "summary": "§4 reads a whitespace-malformed port range as an ordinary identity and silently judges it disjoint.",
      "reasoning": "Measured: port ['4080 - 4089'] against ['4085'] produces no entry at all, i.e. dispatch concurrently, while the reversed range '4089-4080' correctly reads unknown. The compare-it-as-the-name-it-is rationale is right for database and external, but for port a value that is neither an integer string nor a well-formed range is near-certainly a typo, and the filter already special-cases malformed ranges — just not this shape. Permissive direction, one typo away from the documented spelling. Fits #256's parser set.",
      "proposed_action": "Fold into #256.",
      "fix_cost": "low",
      "feature_value": "incidental",
      "adjacent_to_blocking": false
    }
  ],
  "artifacts": {
    "report_path": ".devwork/feature-qa-intra-run-lane-ownership/code-report.md",
    "journal_path": ".devwork/feature-qa-intra-run-lane-ownership/code-journal.md",
    "dispatch_journal": ".devwork/feature-qa-intra-run-lane-ownership/dispatch-journal.md",
    "swept_head": "a0536e2"
  },
  "notes": {
    "cr79_is_a_first": "Driver-reproduced with the mutation asserted before the suite ran. Neutralising the pad wrapper's has($k) guard makes padding OVERWRITE real record values — a record naming database [app_test] against a peer co-claiming it becomes [], the shared entry is dropped, and the disposition flips from VOID to RECORDED. Full suite on the mutated tree: rc=0, 58 PASS, 0 FAIL. The document's own prose forbids this, and the round-5 sweep claimed to have measured never-overwrites — but nothing tests it. This is the NINTH would-be dead assertion here and the FIRST in the permissive direction; the eight before it either failed conservative or were caught before shipping. Categorised blocking despite Medium severity for exactly that reason.",
    "cr77_is_the_same_sentence_twice": "Step 4 totals 'every OTHER actor's claimed workers' while §4's own fence says 'every actor dispatched and not yet released' — the triaged actor's own claim drops out. On §4's OWN worked example (pool 8, two actors claiming 4, which §4 says do not collide) an overrun of 1 reads 'recorded' at a true peak load of 9. This is the sentence CR-74 rewrote last round. The deeper half is a DEFINITION gap: journal-template gives `workers: N` in an overrun record no semantics, and its padding rule (0 if not overrun) is coherent only if N is the excess beyond claim — under which reading the formula is wrong. That is a one-line definition, not new mechanism, and distinct from the executable sum test deferred to #354.",
    "the_sweep_did_not_manufacture_findings": "It said so explicitly and the claim checks out. Every round-6 fix held: CR-71 verified in BOTH directions against the real journal with 22 of 22 claims lines parsing and the three genuinely sparse records each reported naming exactly the classes missing; all six round-6 scenarios shown able to fail; CR-74's pool-as-addend defect confirmed gone; CR-75's corrected explanation matching measured filter behaviour in both cases; no consumer restating the padded/sparse rule. What failed is adjacent text — CR-78 is a contradiction in a document round 6 never opened, CR-77 a half-fix. That distinction is the most useful thing in the report.",
    "round_7_scope": "CR-77, CR-78 and CR-79 block. CR-80 and CR-81 are fix-now: CR-80 is one more fixture in the same scenario CR-79 extends, and CR-81 weakens a SAFETY check in two of its three instances (a two-space `overran_claim:  true` silently disarms step 3a) rather than being cosmetic. CR-82 folds to #256 — it is the parser/spelling set that issue exists to hold."
  }
}

```json { "outcome": "issues-found", "summary": "SWEEP 6 (round 6 exit gate) — 6 findings against the post-fix tree at a0536e2. Two High, and the first PERMISSIVE dead assertion found on this feature. Every round-6 fix held under attack; what failed is adjacent text the round did not touch or only half-fixed.", "findings": [ { "id": "CR-77", "category": "in-scope-blocking", "severity": "High", "summary": "Step 4's budget total omits the triaged actor's own claimed workers, and `workers: N` in an overrun record has no defined meaning — so the rule is permissive and, as written, unanswerable.", "reasoning": "Driver-confirmed. Step 4 reads 'total the overrun together with every OTHER actor's claimed workers still open, and compare against the pool', while §4's own fence says 'total = the workers claimed by every actor dispatched and not yet released'. The triaged actor's own claim drops out. On §4's OWN worked example — pool 8, two actors each claiming 4, which §4 states do not collide — actor A overrunning by 1 gives step 4 a total of 1+4=5, under the pool, so 'recorded', while true peak load is 4+1+4=9, over it. Any wave dispatched at capacity therefore reads every overrun of excess up to the actor's own claim as recorded. The deeper half: journal-template gives `workers: N` in an overran_resources record no semantics, and its padding rule ('0 if workers was not overrun') is coherent only if N is the EXCESS beyond claim — under which reading step 4's formula is wrong; under the alternative reading (N is total used) the formula works but the padding rule and §5's 'beyond its claim' language do not. This is the same sentence CR-74 rewrote and declared in scope, and it is distinct from the executable sum test deferred to #354: this is the formula's terms, not its mechanisation.", "proposed_action": "Define N as the excess beyond claim, and make the total = every open actor's claimed workers (the triaged actor included) plus that excess.", "fix_cost": "low", "feature_value": "core", "adjacent_to_blocking": true }, { "id": "CR-78", "category": "in-scope-blocking", "severity": "High", "summary": "journal-template contradicts §7 on what a sparse record means at triage: the template says void pending remedy, the contract says never grounds to void.", "reasoning": "journal-template states that a sparse record compared against a peer naming anything real on the omitted classes 'falls through to §3's ordinary absent-key-means-unknown rule and reads as unknown (void pending remedy)', and attributes that to §7 step 4. But since round 5 step 4 pads first — 'Pad first; never hand a raw overran_resources record to this filter directly' — and round 6 added 'a SPARSE record is never grounds to void this triage on its own'. Two canonical documents give opposite verdicts for the same record, and the reference journal contains three genuinely sparse records today. The template's over-voiding reading is precisely the disclosure-punishing inversion §8.4 spends three paragraphs refusing. Nothing in either harness pins that paragraph. On this repo's all-[] journal the two readings converge, which is why five sweeps missed it; against a realistic peer they diverge.", "proposed_action": "Update the template sentence to match §7 as it now stands.", "fix_cost": "low", "feature_value": "core", "adjacent_to_blocking": true }, { "id": "CR-79", "category": "in-scope-blocking", "severity": "Medium", "summary": "A PERMISSIVE mutant of the padding wrapper survives all 58 scenarios — padding that overwrites real record values instead of only filling silence.", "reasoning": "Driver-reproduced with the mutation asserted before the suite ran. Neutralising the wrapper's has($k) guard makes padding overwrite every record value: a record naming database ['app_test'] against a peer co-claiming it becomes [], the shared entry is dropped, and the disposition flips from VOID to RECORDED. The full suite on the mutated tree: rc=0, 58 PASS, 0 FAIL. The document's own prose forbids this ('padding only fills silence, it never overwrites a real value') and the round-5 sweep claimed to have measured never-overwrites, but nothing tests it. This is the ninth would-be dead assertion on this feature and the FIRST in the permissive direction — the eight before it either failed conservative or were caught before shipping. Categorised blocking despite Medium severity for that reason.", "proposed_action": "One scenario_cr67 fixture whose record names a non-empty class the peer co-claims, expecting void.", "fix_cost": "low", "feature_value": "core", "adjacent_to_blocking": true }, { "id": "CR-80", "category": "in-scope-deferrable", "severity": "Medium", "summary": "A second pad-wrapper mutant survives the suite, conservative direction: dropping `external` from the base class list.", "reasoning": "Measured, mutation asserted landed, full suite green on the mutated tree. It survives because every scenario_cr67 and scenario_cr73 fixture uses a peer that names all four classes, so the peer-keys union always rescues the base list and the base list is never exercised on its own. Same class as CR-73, remaining cells. Conservative direction, so nothing is unsafe today.", "proposed_action": "A fixture whose peer omits a base class the record also omits.", "fix_cost": "low", "feature_value": "core", "adjacent_to_blocking": true }, { "id": "CR-81", "category": "in-scope-deferrable", "severity": "Medium", "summary": "§7's awk checks pin one exact spelling while YAML, the template and step 3's own sed accept more — two false negatives on record-integrity checks, one false positive.", "reasoning": "Three executed instances. (a) 'overran_claim: true' with two spaces — valid YAML — silently disarms step 3a: a journal with that spelling and no overran_resources prints nothing, while the single-space control correctly reports MISSING. A false negative on the record-integrity check. (b) Step 3b false negative: a sparse record whose external value contains the text 'database:' satisfies the /\"?database\"?:/ regex from inside a VALUE, so the missing database key is not reported — and real externals here are free text with colons. (c) Step 3b false positive: a fully padded record with a space before each colon, which step 3's own key-quoting sed explicitly tolerates, is reported SPARSE — so step 3 and step 3b now disagree about the same spelling. These are new instances on the round-5 and round-6 checks rather than the step-3 sed gaps filed as #256, and two of the three weaken a safety check rather than a cosmetic one.", "proposed_action": "Tolerate YAML's permitted whitespace, and anchor the key match so a value cannot satisfy it.", "fix_cost": "low", "feature_value": "core", "adjacent_to_blocking": true }, { "id": "CR-82", "category": "in-scope-deferrable", "severity": "Medium", "summary": "§4 reads a whitespace-malformed port range as an ordinary identity and silently judges it disjoint.", "reasoning": "Measured: port ['4080 - 4089'] against ['4085'] produces no entry at all, i.e. dispatch concurrently, while the reversed range '4089-4080' correctly reads unknown. The compare-it-as-the-name-it-is rationale is right for database and external, but for port a value that is neither an integer string nor a well-formed range is near-certainly a typo, and the filter already special-cases malformed ranges — just not this shape. Permissive direction, one typo away from the documented spelling. Fits #256's parser set.", "proposed_action": "Fold into #256.", "fix_cost": "low", "feature_value": "incidental", "adjacent_to_blocking": false } ], "artifacts": { "report_path": ".devwork/feature-qa-intra-run-lane-ownership/code-report.md", "journal_path": ".devwork/feature-qa-intra-run-lane-ownership/code-journal.md", "dispatch_journal": ".devwork/feature-qa-intra-run-lane-ownership/dispatch-journal.md", "swept_head": "a0536e2" }, "notes": { "cr79_is_a_first": "Driver-reproduced with the mutation asserted before the suite ran. Neutralising the pad wrapper's has($k) guard makes padding OVERWRITE real record values — a record naming database [app_test] against a peer co-claiming it becomes [], the shared entry is dropped, and the disposition flips from VOID to RECORDED. Full suite on the mutated tree: rc=0, 58 PASS, 0 FAIL. The document's own prose forbids this, and the round-5 sweep claimed to have measured never-overwrites — but nothing tests it. This is the NINTH would-be dead assertion here and the FIRST in the permissive direction; the eight before it either failed conservative or were caught before shipping. Categorised blocking despite Medium severity for exactly that reason.", "cr77_is_the_same_sentence_twice": "Step 4 totals 'every OTHER actor's claimed workers' while §4's own fence says 'every actor dispatched and not yet released' — the triaged actor's own claim drops out. On §4's OWN worked example (pool 8, two actors claiming 4, which §4 says do not collide) an overrun of 1 reads 'recorded' at a true peak load of 9. This is the sentence CR-74 rewrote last round. The deeper half is a DEFINITION gap: journal-template gives `workers: N` in an overrun record no semantics, and its padding rule (0 if not overrun) is coherent only if N is the excess beyond claim — under which reading the formula is wrong. That is a one-line definition, not new mechanism, and distinct from the executable sum test deferred to #354.", "the_sweep_did_not_manufacture_findings": "It said so explicitly and the claim checks out. Every round-6 fix held: CR-71 verified in BOTH directions against the real journal with 22 of 22 claims lines parsing and the three genuinely sparse records each reported naming exactly the classes missing; all six round-6 scenarios shown able to fail; CR-74's pool-as-addend defect confirmed gone; CR-75's corrected explanation matching measured filter behaviour in both cases; no consumer restating the padded/sparse rule. What failed is adjacent text — CR-78 is a contradiction in a document round 6 never opened, CR-77 a half-fix. That distinction is the most useful thing in the report.", "round_7_scope": "CR-77, CR-78 and CR-79 block. CR-80 and CR-81 are fix-now: CR-80 is one more fixture in the same scenario CR-79 extends, and CR-81 weakens a SAFETY check in two of its three instances (a two-space `overran_claim: true` silently disarms step 3a) rather than being cosmetic. CR-82 folds to #256 — it is the parser/spelling set that issue exists to hold." } } ```

jbr870 commented

2026-08-27 08:32:22 +00:00

Author

Owner

{
  "next_state": "qa",
  "produced": [
    {
      "kind": "qa-report",
      "ref": "2387",
      "summary": "code phase=fix — 6 findings fixed, all 4 gates green"
    },
    {
      "kind": "qa-report",
      "ref": "latest",
      "summary": "code phase=validate — sweep 6, 6 findings, 2 High, first permissive dead assertion"
    },
    {
      "kind": "code-bundle",
      "ref": "a0536e2",
      "summary": "the swept HEAD: fix commit a0536e2 on test_commit 5053a40"
    }
  ],
  "findings": [
    {
      "category": "in-scope-blocking",
      "severity": "high",
      "summary": "[code CR-77] Step 4's budget total omits the triaged actor's own claimed workers, and `workers: N` in an overrun record has no defined meaning — so the rule is permissive and, as written, unanswerable.",
      "reasoning": "Driver-confirmed. Step 4 reads 'total the overrun together with every OTHER actor's claimed workers still open, and compare against the pool', while §4's own fence says 'total = the workers claimed by every actor dispatched and not yet released'. The triaged actor's own claim drops out. On §4's OWN worked example — pool 8, two actors each claiming 4, which §4 states do not collide — actor A overrunning by 1 gives step 4 a total of 1+4=5, under the pool, so 'recorded', while true peak load is 4+1+4=9, over it. Any wave dispatched at capacity therefore reads every overrun of excess up to the actor's own claim as recorded. The deeper half: journal-template gives `workers: N` in an overran_resources record no semantics, and its padding rule ('0 if workers was not overrun') is coherent only if N is the EXCESS beyond claim — under which reading step 4's formula is wrong; under the alternative reading (N is total used) the formula works but the padding rule and §5's 'beyond its claim' language do not. This is the same sentence CR-74 rewrote and declared in scope, and it is distinct from the executable sum test deferred to #354: this is the formula's terms, not its mechanisation.",
      "proposed_action": "Define N as the excess beyond claim, and make the total = every open actor's claimed workers (the triaged actor included) plus that excess.",
      "fix_cost": "low",
      "feature_value": "core",
      "adjacent_to_blocking": true,
      "id": "F-PO-43-10-1"
    },
    {
      "category": "in-scope-blocking",
      "severity": "high",
      "summary": "[code CR-78] journal-template contradicts §7 on what a sparse record means at triage: the template says void pending remedy, the contract says never grounds to void.",
      "reasoning": "journal-template states that a sparse record compared against a peer naming anything real on the omitted classes 'falls through to §3's ordinary absent-key-means-unknown rule and reads as unknown (void pending remedy)', and attributes that to §7 step 4. But since round 5 step 4 pads first — 'Pad first; never hand a raw overran_resources record to this filter directly' — and round 6 added 'a SPARSE record is never grounds to void this triage on its own'. Two canonical documents give opposite verdicts for the same record, and the reference journal contains three genuinely sparse records today. The template's over-voiding reading is precisely the disclosure-punishing inversion §8.4 spends three paragraphs refusing. Nothing in either harness pins that paragraph. On this repo's all-[] journal the two readings converge, which is why five sweeps missed it; against a realistic peer they diverge.",
      "proposed_action": "Update the template sentence to match §7 as it now stands.",
      "fix_cost": "low",
      "feature_value": "core",
      "adjacent_to_blocking": true,
      "id": "F-PO-43-10-2"
    },
    {
      "category": "in-scope-blocking",
      "severity": "medium",
      "summary": "[code CR-79] A PERMISSIVE mutant of the padding wrapper survives all 58 scenarios — padding that overwrites real record values instead of only filling silence.",
      "reasoning": "Driver-reproduced with the mutation asserted before the suite ran. Neutralising the wrapper's has($k) guard makes padding overwrite every record value: a record naming database ['app_test'] against a peer co-claiming it becomes [], the shared entry is dropped, and the disposition flips from VOID to RECORDED. The full suite on the mutated tree: rc=0, 58 PASS, 0 FAIL. The document's own prose forbids this ('padding only fills silence, it never overwrites a real value') and the round-5 sweep claimed to have measured never-overwrites, but nothing tests it. This is the ninth would-be dead assertion on this feature and the FIRST in the permissive direction — the eight before it either failed conservative or were caught before shipping. Categorised blocking despite Medium severity for that reason.",
      "proposed_action": "One scenario_cr67 fixture whose record names a non-empty class the peer co-claims, expecting void.",
      "fix_cost": "low",
      "feature_value": "core",
      "adjacent_to_blocking": true,
      "id": "F-PO-43-10-3"
    },
    {
      "category": "in-scope-deferrable",
      "severity": "medium",
      "summary": "[code CR-80] A second pad-wrapper mutant survives the suite, conservative direction: dropping `external` from the base class list.",
      "reasoning": "Measured, mutation asserted landed, full suite green on the mutated tree. It survives because every scenario_cr67 and scenario_cr73 fixture uses a peer that names all four classes, so the peer-keys union always rescues the base list and the base list is never exercised on its own. Same class as CR-73, remaining cells. Conservative direction, so nothing is unsafe today.",
      "proposed_action": "A fixture whose peer omits a base class the record also omits.",
      "fix_cost": "low",
      "feature_value": "core",
      "adjacent_to_blocking": true,
      "id": "F-PO-43-10-4"
    },
    {
      "category": "in-scope-deferrable",
      "severity": "medium",
      "summary": "[code CR-81] §7's awk checks pin one exact spelling while YAML, the template and step 3's own sed accept more — two false negatives on record-integrity checks, one false positive.",
      "reasoning": "Three executed instances. (a) 'overran_claim:  true' with two spaces — valid YAML — silently disarms step 3a: a journal with that spelling and no overran_resources prints nothing, while the single-space control correctly reports MISSING. A false negative on the record-integrity check. (b) Step 3b false negative: a sparse record whose external value contains the text 'database:' satisfies the /\"?database\"?:/ regex from inside a VALUE, so the missing database key is not reported — and real externals here are free text with colons. (c) Step 3b false positive: a fully padded record with a space before each colon, which step 3's own key-quoting sed explicitly tolerates, is reported SPARSE — so step 3 and step 3b now disagree about the same spelling. These are new instances on the round-5 and round-6 checks rather than the step-3 sed gaps filed as #256, and two of the three weaken a safety check rather than a cosmetic one.",
      "proposed_action": "Tolerate YAML's permitted whitespace, and anchor the key match so a value cannot satisfy it.",
      "fix_cost": "low",
      "feature_value": "core",
      "adjacent_to_blocking": true,
      "id": "F-PO-43-10-5"
    },
    {
      "category": "in-scope-deferrable",
      "severity": "medium",
      "summary": "[code CR-82] §4 reads a whitespace-malformed port range as an ordinary identity and silently judges it disjoint.",
      "reasoning": "Measured: port ['4080 - 4089'] against ['4085'] produces no entry at all, i.e. dispatch concurrently, while the reversed range '4089-4080' correctly reads unknown. The compare-it-as-the-name-it-is rationale is right for database and external, but for port a value that is neither an integer string nor a well-formed range is near-certainly a typo, and the filter already special-cases malformed ranges — just not this shape. Permissive direction, one typo away from the documented spelling. Fits #256's parser set.",
      "proposed_action": "Fold into #256.",
      "fix_cost": "low",
      "feature_value": "incidental",
      "adjacent_to_blocking": false,
      "id": "F-PO-43-10-6"
    }
  ],
  "pending_decisions": [
    {
      "id": "D-PO-43-10-1",
      "type": "scope-disposition",
      "blocking": false,
      "question": "[CR-80] A second pad-wrapper mutant survives the suite, conservative direction: dropping `external` from the base class list. — fix now, spawn a follow-up issue, or accept?",
      "options": [
        "fix-now",
        "defer-to-issue",
        "accept"
      ],
      "recommended": "defer-to-issue",
      "finding_ref": "F-PO-43-10-4",
      "reasoning": "Computed by disposition-recommend.sh from the finding's axes. Full evidence in the sweep qa-report:v1 (domain=code, phase=validate)."
    },
    {
      "id": "D-PO-43-10-2",
      "type": "scope-disposition",
      "blocking": false,
      "question": "[CR-81] §7's awk checks pin one exact spelling while YAML, the template and step 3's own sed accept more — two false negatives on record-integrity checks, one false positive. — fix now, spawn a follow-up issue, or accept?",
      "options": [
        "fix-now",
        "defer-to-issue",
        "accept"
      ],
      "recommended": "defer-to-issue",
      "finding_ref": "F-PO-43-10-5",
      "reasoning": "Computed by disposition-recommend.sh from the finding's axes. Full evidence in the sweep qa-report:v1 (domain=code, phase=validate)."
    },
    {
      "id": "D-PO-43-10-3",
      "type": "scope-disposition",
      "blocking": false,
      "question": "[CR-82] §4 reads a whitespace-malformed port range as an ordinary identity and silently judges it disjoint. — fix now, spawn a follow-up issue, or accept?",
      "options": [
        "fix-now",
        "defer-to-issue",
        "accept"
      ],
      "recommended": "defer-to-issue",
      "finding_ref": "F-PO-43-10-6",
      "reasoning": "Computed by disposition-recommend.sh from the finding's axes. Full evidence in the sweep qa-report:v1 (domain=code, phase=validate)."
    }
  ],
  "suite": {
    "source": "git",
    "sha": "a0536e23affb2053a407942ce2e7d7c7498ed8f7",
    "dirty": false
  }
}

```json { "next_state": "qa", "produced": [ { "kind": "qa-report", "ref": "2387", "summary": "code phase=fix — 6 findings fixed, all 4 gates green" }, { "kind": "qa-report", "ref": "latest", "summary": "code phase=validate — sweep 6, 6 findings, 2 High, first permissive dead assertion" }, { "kind": "code-bundle", "ref": "a0536e2", "summary": "the swept HEAD: fix commit a0536e2 on test_commit 5053a40" } ], "findings": [ { "category": "in-scope-blocking", "severity": "high", "summary": "[code CR-77] Step 4's budget total omits the triaged actor's own claimed workers, and `workers: N` in an overrun record has no defined meaning — so the rule is permissive and, as written, unanswerable.", "reasoning": "Driver-confirmed. Step 4 reads 'total the overrun together with every OTHER actor's claimed workers still open, and compare against the pool', while §4's own fence says 'total = the workers claimed by every actor dispatched and not yet released'. The triaged actor's own claim drops out. On §4's OWN worked example — pool 8, two actors each claiming 4, which §4 states do not collide — actor A overrunning by 1 gives step 4 a total of 1+4=5, under the pool, so 'recorded', while true peak load is 4+1+4=9, over it. Any wave dispatched at capacity therefore reads every overrun of excess up to the actor's own claim as recorded. The deeper half: journal-template gives `workers: N` in an overran_resources record no semantics, and its padding rule ('0 if workers was not overrun') is coherent only if N is the EXCESS beyond claim — under which reading step 4's formula is wrong; under the alternative reading (N is total used) the formula works but the padding rule and §5's 'beyond its claim' language do not. This is the same sentence CR-74 rewrote and declared in scope, and it is distinct from the executable sum test deferred to #354: this is the formula's terms, not its mechanisation.", "proposed_action": "Define N as the excess beyond claim, and make the total = every open actor's claimed workers (the triaged actor included) plus that excess.", "fix_cost": "low", "feature_value": "core", "adjacent_to_blocking": true, "id": "F-PO-43-10-1" }, { "category": "in-scope-blocking", "severity": "high", "summary": "[code CR-78] journal-template contradicts §7 on what a sparse record means at triage: the template says void pending remedy, the contract says never grounds to void.", "reasoning": "journal-template states that a sparse record compared against a peer naming anything real on the omitted classes 'falls through to §3's ordinary absent-key-means-unknown rule and reads as unknown (void pending remedy)', and attributes that to §7 step 4. But since round 5 step 4 pads first — 'Pad first; never hand a raw overran_resources record to this filter directly' — and round 6 added 'a SPARSE record is never grounds to void this triage on its own'. Two canonical documents give opposite verdicts for the same record, and the reference journal contains three genuinely sparse records today. The template's over-voiding reading is precisely the disclosure-punishing inversion §8.4 spends three paragraphs refusing. Nothing in either harness pins that paragraph. On this repo's all-[] journal the two readings converge, which is why five sweeps missed it; against a realistic peer they diverge.", "proposed_action": "Update the template sentence to match §7 as it now stands.", "fix_cost": "low", "feature_value": "core", "adjacent_to_blocking": true, "id": "F-PO-43-10-2" }, { "category": "in-scope-blocking", "severity": "medium", "summary": "[code CR-79] A PERMISSIVE mutant of the padding wrapper survives all 58 scenarios — padding that overwrites real record values instead of only filling silence.", "reasoning": "Driver-reproduced with the mutation asserted before the suite ran. Neutralising the wrapper's has($k) guard makes padding overwrite every record value: a record naming database ['app_test'] against a peer co-claiming it becomes [], the shared entry is dropped, and the disposition flips from VOID to RECORDED. The full suite on the mutated tree: rc=0, 58 PASS, 0 FAIL. The document's own prose forbids this ('padding only fills silence, it never overwrites a real value') and the round-5 sweep claimed to have measured never-overwrites, but nothing tests it. This is the ninth would-be dead assertion on this feature and the FIRST in the permissive direction — the eight before it either failed conservative or were caught before shipping. Categorised blocking despite Medium severity for that reason.", "proposed_action": "One scenario_cr67 fixture whose record names a non-empty class the peer co-claims, expecting void.", "fix_cost": "low", "feature_value": "core", "adjacent_to_blocking": true, "id": "F-PO-43-10-3" }, { "category": "in-scope-deferrable", "severity": "medium", "summary": "[code CR-80] A second pad-wrapper mutant survives the suite, conservative direction: dropping `external` from the base class list.", "reasoning": "Measured, mutation asserted landed, full suite green on the mutated tree. It survives because every scenario_cr67 and scenario_cr73 fixture uses a peer that names all four classes, so the peer-keys union always rescues the base list and the base list is never exercised on its own. Same class as CR-73, remaining cells. Conservative direction, so nothing is unsafe today.", "proposed_action": "A fixture whose peer omits a base class the record also omits.", "fix_cost": "low", "feature_value": "core", "adjacent_to_blocking": true, "id": "F-PO-43-10-4" }, { "category": "in-scope-deferrable", "severity": "medium", "summary": "[code CR-81] §7's awk checks pin one exact spelling while YAML, the template and step 3's own sed accept more — two false negatives on record-integrity checks, one false positive.", "reasoning": "Three executed instances. (a) 'overran_claim: true' with two spaces — valid YAML — silently disarms step 3a: a journal with that spelling and no overran_resources prints nothing, while the single-space control correctly reports MISSING. A false negative on the record-integrity check. (b) Step 3b false negative: a sparse record whose external value contains the text 'database:' satisfies the /\"?database\"?:/ regex from inside a VALUE, so the missing database key is not reported — and real externals here are free text with colons. (c) Step 3b false positive: a fully padded record with a space before each colon, which step 3's own key-quoting sed explicitly tolerates, is reported SPARSE — so step 3 and step 3b now disagree about the same spelling. These are new instances on the round-5 and round-6 checks rather than the step-3 sed gaps filed as #256, and two of the three weaken a safety check rather than a cosmetic one.", "proposed_action": "Tolerate YAML's permitted whitespace, and anchor the key match so a value cannot satisfy it.", "fix_cost": "low", "feature_value": "core", "adjacent_to_blocking": true, "id": "F-PO-43-10-5" }, { "category": "in-scope-deferrable", "severity": "medium", "summary": "[code CR-82] §4 reads a whitespace-malformed port range as an ordinary identity and silently judges it disjoint.", "reasoning": "Measured: port ['4080 - 4089'] against ['4085'] produces no entry at all, i.e. dispatch concurrently, while the reversed range '4089-4080' correctly reads unknown. The compare-it-as-the-name-it-is rationale is right for database and external, but for port a value that is neither an integer string nor a well-formed range is near-certainly a typo, and the filter already special-cases malformed ranges — just not this shape. Permissive direction, one typo away from the documented spelling. Fits #256's parser set.", "proposed_action": "Fold into #256.", "fix_cost": "low", "feature_value": "incidental", "adjacent_to_blocking": false, "id": "F-PO-43-10-6" } ], "pending_decisions": [ { "id": "D-PO-43-10-1", "type": "scope-disposition", "blocking": false, "question": "[CR-80] A second pad-wrapper mutant survives the suite, conservative direction: dropping `external` from the base class list. — fix now, spawn a follow-up issue, or accept?", "options": [ "fix-now", "defer-to-issue", "accept" ], "recommended": "defer-to-issue", "finding_ref": "F-PO-43-10-4", "reasoning": "Computed by disposition-recommend.sh from the finding's axes. Full evidence in the sweep qa-report:v1 (domain=code, phase=validate)." }, { "id": "D-PO-43-10-2", "type": "scope-disposition", "blocking": false, "question": "[CR-81] §7's awk checks pin one exact spelling while YAML, the template and step 3's own sed accept more — two false negatives on record-integrity checks, one false positive. — fix now, spawn a follow-up issue, or accept?", "options": [ "fix-now", "defer-to-issue", "accept" ], "recommended": "defer-to-issue", "finding_ref": "F-PO-43-10-5", "reasoning": "Computed by disposition-recommend.sh from the finding's axes. Full evidence in the sweep qa-report:v1 (domain=code, phase=validate)." }, { "id": "D-PO-43-10-3", "type": "scope-disposition", "blocking": false, "question": "[CR-82] §4 reads a whitespace-malformed port range as an ordinary identity and silently judges it disjoint. — fix now, spawn a follow-up issue, or accept?", "options": [ "fix-now", "defer-to-issue", "accept" ], "recommended": "defer-to-issue", "finding_ref": "F-PO-43-10-6", "reasoning": "Computed by disposition-recommend.sh from the finding's axes. Full evidence in the sweep qa-report:v1 (domain=code, phase=validate)." } ], "suite": { "source": "git", "sha": "a0536e23affb2053a407942ce2e7d7c7498ed8f7", "dirty": false } } ```

jbr870 commented

2026-08-27 08:32:57 +00:00

Author

Owner

{
  "status": "resolved",
  "chosen_option": "fix-now",
  "rationale": "[CR-80] One more fixture in the very scenario CR-79 is already extending, so the marginal cost is a few lines in a file being opened anyway. It also completes a set rather than adding to one: CR-73 closed two cells of the pad wrapper s behaviour last round, CR-79 closes the permissive third, and this is the fourth. Leaving one cell open in a mechanism that has now produced three surviving mutants across two rounds would mean re-opening the same scenario a third time. Resolved by the driver under the operator's standing authority to run the QA phase to completion, stopping only on a blocking decision. Where this resolution differs from disposition-recommend.sh's answer it says so explicitly and gives the reason; the recommender scores each finding in isolation and cannot see that five of these are one recurring class.",
  "rejected_alternative": "defer-to-issue matches the Medium severity and this mutant fails conservative, so nothing is unsafe today. Turned down on adjacency and on the pattern: every time this wrapper has been mutation-tested it has yielded another surviving mutant, which is an argument for finishing the coverage rather than sampling it again later."
}

```json { "status": "resolved", "chosen_option": "fix-now", "rationale": "[CR-80] One more fixture in the very scenario CR-79 is already extending, so the marginal cost is a few lines in a file being opened anyway. It also completes a set rather than adding to one: CR-73 closed two cells of the pad wrapper s behaviour last round, CR-79 closes the permissive third, and this is the fourth. Leaving one cell open in a mechanism that has now produced three surviving mutants across two rounds would mean re-opening the same scenario a third time. Resolved by the driver under the operator's standing authority to run the QA phase to completion, stopping only on a blocking decision. Where this resolution differs from disposition-recommend.sh's answer it says so explicitly and gives the reason; the recommender scores each finding in isolation and cannot see that five of these are one recurring class.", "rejected_alternative": "defer-to-issue matches the Medium severity and this mutant fails conservative, so nothing is unsafe today. Turned down on adjacency and on the pattern: every time this wrapper has been mutation-tested it has yielded another surviving mutant, which is an argument for finishing the coverage rather than sampling it again later." } ```

jbr870 commented

2026-08-27 08:32:57 +00:00

Author

Owner

{
  "status": "resolved",
  "chosen_option": "fix-now",
  "rationale": "[CR-81] Two of its three instances weaken a SAFETY check rather than a cosmetic one, and that is what separates it from #256. A two-space `overran_claim:  true` — valid YAML — silently disarms step 3a, so a record that fails to name what it overran passes the integrity check that exists to catch exactly that. The value-embedded-colon case lets a genuinely sparse record escape step 3b because the regex matches inside a value, and real externals in this very journal are free text containing colons. The third instance is a false positive where step 3 and step 3b disagree about a spelling step 3 s own sed explicitly tolerates, which is two parts of one recipe contradicting each other. All three are regex tolerance in awk blocks rounds 5 and 6 added. Resolved by the driver under the operator's standing authority to run the QA phase to completion, stopping only on a blocking decision. Where this resolution differs from disposition-recommend.sh's answer it says so explicitly and gives the reason; the recommender scores each finding in isolation and cannot see that five of these are one recurring class.",
  "rejected_alternative": "defer-to-issue to #256 was the obvious move, since #256 holds the spelling and parser set. Turned down because #256 was filed against step 3 s sed and against cosmetic wrong answers; these are new checks, added by the last two rounds, and two of them silently disarm a safety check. A false negative on record integrity is not the same kind of thing as a near-miss port spelling."
}

```json { "status": "resolved", "chosen_option": "fix-now", "rationale": "[CR-81] Two of its three instances weaken a SAFETY check rather than a cosmetic one, and that is what separates it from #256. A two-space `overran_claim: true` — valid YAML — silently disarms step 3a, so a record that fails to name what it overran passes the integrity check that exists to catch exactly that. The value-embedded-colon case lets a genuinely sparse record escape step 3b because the regex matches inside a value, and real externals in this very journal are free text containing colons. The third instance is a false positive where step 3 and step 3b disagree about a spelling step 3 s own sed explicitly tolerates, which is two parts of one recipe contradicting each other. All three are regex tolerance in awk blocks rounds 5 and 6 added. Resolved by the driver under the operator's standing authority to run the QA phase to completion, stopping only on a blocking decision. Where this resolution differs from disposition-recommend.sh's answer it says so explicitly and gives the reason; the recommender scores each finding in isolation and cannot see that five of these are one recurring class.", "rejected_alternative": "defer-to-issue to #256 was the obvious move, since #256 holds the spelling and parser set. Turned down because #256 was filed against step 3 s sed and against cosmetic wrong answers; these are new checks, added by the last two rounds, and two of them silently disarm a safety check. A false negative on record integrity is not the same kind of thing as a near-miss port spelling." } ```

jbr870 commented

2026-08-27 08:32:58 +00:00

Author

Owner

{
  "status": "resolved",
  "chosen_option": "defer-to-issue",
  "rationale": "[CR-82] A clean fit for #256, which exists to hold exactly this: a value that is neither an integer string nor a well-formed range, one typo away from the documented spelling, judged disjoint. It is in §4 s filter rather than in the awk checks round 7 is opening, this project declares no ports so it cannot occur here, and the fix is a shape guard that belongs with the other range and spelling work rather than bolted on alone. Resolved by the driver under the operator's standing authority to run the QA phase to completion, stopping only on a blocking decision. Where this resolution differs from disposition-recommend.sh's answer it says so explicitly and gives the reason; the recommender scores each finding in isolation and cannot see that five of these are one recurring class.",
  "rejected_alternative": "fix-now had a real case: it is the PERMISSIVE direction, and the filter already special-cases malformed ranges, so the missing branch is small. Turned down on reachability and cohesion — every other item in round 7 is reachable from this repo s own records, and #256 s set will be fixed as a unit by someone holding the whole parser in their head, which is the right way to fix it."
}

```json { "status": "resolved", "chosen_option": "defer-to-issue", "rationale": "[CR-82] A clean fit for #256, which exists to hold exactly this: a value that is neither an integer string nor a well-formed range, one typo away from the documented spelling, judged disjoint. It is in §4 s filter rather than in the awk checks round 7 is opening, this project declares no ports so it cannot occur here, and the fix is a shape guard that belongs with the other range and spelling work rather than bolted on alone. Resolved by the driver under the operator's standing authority to run the QA phase to completion, stopping only on a blocking decision. Where this resolution differs from disposition-recommend.sh's answer it says so explicitly and gives the reason; the recommender scores each finding in isolation and cannot see that five of these are one recurring class.", "rejected_alternative": "fix-now had a real case: it is the PERMISSIVE direction, and the filter already special-cases malformed ranges, so the missing branch is small. Turned down on reachability and cohesion — every other item in round 7 is reachable from this repo s own records, and #256 s set will be fixed as a unit by someone holding the whole parser in their head, which is the right way to fix it." } ```

jbr870 referenced this issue

2026-08-27 08:33:13 +00:00

run-resource-claims: eleven parser and vocabulary gaps in the shipped recipes and helpers #256

jbr870 commented

2026-08-30 05:49:58 +00:00

Author

Owner

{
  "outcome": "clean",
  "summary": "Round 7 fix stage. All 7 findings fixed and promoted, including all three blockers, plus CR-85 found and closed inside the stage. Zero red markers remain. All four gates green at this commit.",
  "findings": [],
  "artifacts": {
    "fix_commit": "a09e0e0abbf817ec5d1ce6fd27b78866a306d72c",
    "test_commit": "aa95452",
    "fixed": [
      "CR-77 (blocking)",
      "CR-78 (blocking)",
      "CR-79 (blocking)",
      "CR-80",
      "CR-81",
      "CR-83",
      "CR-84",
      "CR-85 (found and closed within this stage)"
    ],
    "files": [
      "plugin/skills/_shared/procedures/run-resource-claims.md",
      "plugin/skills/_shared/procedures/journal-template.md",
      "scripts/test-run-resource-claims.sh"
    ],
    "gates_at_fix_commit": {
      "lint-conventions.sh": "clean",
      "test-lint-conventions.sh": "29 PASS / 0 FAIL / 0 RED",
      "test-run-resource-claims.sh": "65 PASS / 0 FAIL / 0 RED / 0 XPASS — zero red_scenario markers remain",
      "test-plugin-gates.sh": "17 passed, 0 failed, 0 skipped — run AFTER the commit, since it measures HEAD"
    }
  },
  "notes": {
    "cr77_was_a_definition_not_a_formula": "The arithmetic had been wrong twice because its central term was undefined. journal-template gave `workers: N` in an overrun record no semantics, so step 4 and the padding rule each silently assumed a different one. This round DEFINES N as the actor's excess beyond its claim, at the point where the field is defined, and then makes the formula match: total every open actor's claimed workers, the triaged actor's own included, plus that excess. Fixing the sentence without fixing the term is why CR-58 and CR-74 both came back.",
    "cr85_is_the_inverse_of_a_dead_assertion": "The fixer fixed CR-81's document correctly, then found the SCENARIO verifying it could never return 0 — every 'premise no longer holds' branch returned 1, and the function ended in an unconditional return 1 with no empty-reasons early return. It STOPPED and reported rather than forcing a green, cited the standing rule, and stayed inside its file boundary. The cause is exact and general: THE SANITY CHECK AND THE SUCCESS CONDITION WERE THE SAME EVENT. 'If the bad behaviour is gone, the fixture has drifted' is correct for a run_scenario guarding a fixed invariant and precisely wrong for a red_scenario, whose purpose is to go green when the bad behaviour disappears. Nine dead assertions on this feature were always-green; this one was always-red. Both are useless as guards; this one at least fails loudly.",
    "the_refusal_is_why_the_round_earned_its_exit": "This is the second time a fixer's refusal was worth more than a fix. The brief had told F9 about the standing exit rule and then said the opposite of what that might imply — that a reported problem is a good outcome and a forced green the worst, because it would buy an exit that was not earned. It behaved accordingly.",
    "verified_not_reported": "The document fix was checked independently BEFORE the scenario was touched: two-space `overran_claim:  true` now reports MISSING, `database` survives a value containing the text `database:`, space-before-colon is no longer flagged SPARSE, and a genuinely sparse record still is — each with its control. All seven promotions were then verified: reverting both documents to aa95452 while keeping the markers reds CR-77, CR-78 and CR-81; the three harness-side findings were checked by targeted mutant — has($k) dropped, `external` dropped from the PAD WRAPPER's list alone (leaving §4's own list untouched), and cr74's fold reverted — each making its guard fail.",
    "driver_probe_errors": "Two more this round, both caught only because every mutation prints a before/after count: a replacement that hit one of two class-list sites, and a fold anchor that matched nothing. Roughly nine across this QA. The driver's probes have been the least reliable instrument in it, which is the argument for the counts rather than against the probes."
  }
}

```json { "outcome": "clean", "summary": "Round 7 fix stage. All 7 findings fixed and promoted, including all three blockers, plus CR-85 found and closed inside the stage. Zero red markers remain. All four gates green at this commit.", "findings": [], "artifacts": { "fix_commit": "a09e0e0abbf817ec5d1ce6fd27b78866a306d72c", "test_commit": "aa95452", "fixed": [ "CR-77 (blocking)", "CR-78 (blocking)", "CR-79 (blocking)", "CR-80", "CR-81", "CR-83", "CR-84", "CR-85 (found and closed within this stage)" ], "files": [ "plugin/skills/_shared/procedures/run-resource-claims.md", "plugin/skills/_shared/procedures/journal-template.md", "scripts/test-run-resource-claims.sh" ], "gates_at_fix_commit": { "lint-conventions.sh": "clean", "test-lint-conventions.sh": "29 PASS / 0 FAIL / 0 RED", "test-run-resource-claims.sh": "65 PASS / 0 FAIL / 0 RED / 0 XPASS — zero red_scenario markers remain", "test-plugin-gates.sh": "17 passed, 0 failed, 0 skipped — run AFTER the commit, since it measures HEAD" } }, "notes": { "cr77_was_a_definition_not_a_formula": "The arithmetic had been wrong twice because its central term was undefined. journal-template gave `workers: N` in an overrun record no semantics, so step 4 and the padding rule each silently assumed a different one. This round DEFINES N as the actor's excess beyond its claim, at the point where the field is defined, and then makes the formula match: total every open actor's claimed workers, the triaged actor's own included, plus that excess. Fixing the sentence without fixing the term is why CR-58 and CR-74 both came back.", "cr85_is_the_inverse_of_a_dead_assertion": "The fixer fixed CR-81's document correctly, then found the SCENARIO verifying it could never return 0 — every 'premise no longer holds' branch returned 1, and the function ended in an unconditional return 1 with no empty-reasons early return. It STOPPED and reported rather than forcing a green, cited the standing rule, and stayed inside its file boundary. The cause is exact and general: THE SANITY CHECK AND THE SUCCESS CONDITION WERE THE SAME EVENT. 'If the bad behaviour is gone, the fixture has drifted' is correct for a run_scenario guarding a fixed invariant and precisely wrong for a red_scenario, whose purpose is to go green when the bad behaviour disappears. Nine dead assertions on this feature were always-green; this one was always-red. Both are useless as guards; this one at least fails loudly.", "the_refusal_is_why_the_round_earned_its_exit": "This is the second time a fixer's refusal was worth more than a fix. The brief had told F9 about the standing exit rule and then said the opposite of what that might imply — that a reported problem is a good outcome and a forced green the worst, because it would buy an exit that was not earned. It behaved accordingly.", "verified_not_reported": "The document fix was checked independently BEFORE the scenario was touched: two-space `overran_claim: true` now reports MISSING, `database` survives a value containing the text `database:`, space-before-colon is no longer flagged SPARSE, and a genuinely sparse record still is — each with its control. All seven promotions were then verified: reverting both documents to aa95452 while keeping the markers reds CR-77, CR-78 and CR-81; the three harness-side findings were checked by targeted mutant — has($k) dropped, `external` dropped from the PAD WRAPPER's list alone (leaving §4's own list untouched), and cr74's fold reverted — each making its guard fail.", "driver_probe_errors": "Two more this round, both caught only because every mutation prints a before/after count: a replacement that hit one of two class-list sites, and a fold anchor that matched nothing. Roughly nine across this QA. The driver's probes have been the least reliable instrument in it, which is the argument for the counts rather than against the probes." } } ```

jbr870 commented

2026-08-30 07:01:47 +00:00

Author

Owner

{
  "outcome": "issues-found",
  "summary": "SWEEP 7 (round 7 exit gate) — 6 findings against a09e0e0. NO High, no false green, no safety inversion in shipped behaviour: the shipped contract is the soundest it has been in seven rounds. But the agreed STOPPING RULE has tripped, and QA leaves the patch loop for a requirements pass on the VERIFICATION tier rather than advancing to integrating.",
  "findings": [
    {
      "id": "CR-86",
      "category": "in-scope-deferrable",
      "severity": "Medium",
      "summary": "scenario_cr77 is fold-blind to a wrapped reintroduction of the defect it guards — CR-84's property, in a scenario round 7 itself authored.",
      "reasoning": "Driver-measured by insertion after a replacement probe went no-op. cr77 folds step 4 with a plain `tr '\\n' ' '` and no leading-# strip, unlike cr74 and cr78. Injecting the pre-fix phrase UNWRAPPED makes cr77 FAIL correctly; injecting the identical phrase WRAPPED across a #-comment break makes it PASS. Same insertion, only the wrap differs, isolating the wrap as sole cause. It is not literally dead — it fails on the unwrapped shape — but the wrapped shape is exactly what a reword-plus-hard-wrap produces, and CR-84 warned that CR-77's sentence is the one future fixes would touch. The F9 brief flagged that interaction explicitly and the fix stage stripped only cr74's fold. By the accounting this QA has used, where cr74's identical property was called the tenth dead assertion, this is the eleventh.",
      "proposed_action": "The same sed 's/^#[[:space:]]*//' cr74 and cr78 already use — but route it through the verification-tier requirements pass rather than an eighth patch round.",
      "fix_cost": "low",
      "feature_value": "core",
      "adjacent_to_blocking": true
    },
    {
      "id": "CR-87",
      "category": "in-scope-deferrable",
      "severity": "Medium",
      "summary": "The harness helper step4_disposition still implements the pre-CR-77 arithmetic, so the measuring instrument now contradicts the document it measures.",
      "reasoning": "Driver-confirmed by reading the helper and the fixed document. step4_disposition computes total = overrun + peer_workers and has no parameter for the triaged actor's own claim; the document now requires 'every open actor's claimed workers, the TRIAGED ACTOR'S OWN claim included, plus that excess'. On CR-77's own worked example — pool 8, triaged claims 4 with excess 1, peer claims 4 — the document says VOID (9 > 8) and the helper says recorded (5 <= 8). Before the fix the two agreed; the fix changed the document and left the restatement, in the same file it was editing. No current fixture crosses the boundary, so no scenario asserts a wrong verdict today — hence Medium — but it is literally a defect created by round 7's own fix, in the permissive direction, and it is the fourth entry in this one sentence's restatement chain after CR-58, CR-74 and CR-77.",
      "proposed_action": "Give the helper the own-claim term, or stop it restating the formula at all.",
      "fix_cost": "low",
      "feature_value": "core",
      "adjacent_to_blocking": true
    },
    {
      "id": "CR-88",
      "category": "in-scope-deferrable",
      "severity": "Medium",
      "summary": "Step 4's budget total collapses time: it sums every actor whose window intersects, not every actor concurrently open.",
      "reasoning": "Measured. Pool 8; triaged actor claims 2 with excess 1; peers B and C each claim 3, both intersecting the triaged window, but B released before C dispatched. Step 4's formula gives 2+3+3+1 = 9 > 8 and voids; true concurrent peak is 6 and it should record. §4's own fence is instantaneous — 'every actor dispatched and not yet released' — while step 4's restatement sums over the whole window. Conservative direction, which is the contract's deliberate error direction, and pre-existing rather than introduced by round 7, which fixed only the own-claim term. It borders #354's deferred executable sum test but is not covered by it: the prose formula itself overcounts.",
      "proposed_action": "Decide whether the total is instantaneous or window-wide, and say so in one place.",
      "fix_cost": "medium",
      "feature_value": "core",
      "adjacent_to_blocking": false
    },
    {
      "id": "CR-89",
      "category": "in-scope-deferrable",
      "severity": "Low",
      "summary": "Step 3b residual false negative: a quoted value containing a comma before the key text still satisfies the new [{,]-anchored regex.",
      "reasoning": "Measured: overran_resources: {external: \"shared cache, database: also touched\", port: [], workers: 0} is genuinely missing the database key and the recipe prints no SPARSE line, because the comma inside the quoted value satisfies the anchor. Same class as CR-81 bullet 2, one comma deeper, and the reference journal's real external values do contain commas. Informational only — step 4 states a SPARSE hit never voids — which is why it is Low. Folds naturally into #256's parser set.",
      "proposed_action": "Fold into #256.",
      "fix_cost": "low",
      "feature_value": "incidental",
      "adjacent_to_blocking": false
    },
    {
      "id": "CR-90",
      "category": "in-scope-deferrable",
      "severity": "Low",
      "summary": "cr77's semantics guard accepts the opposite definition of N, so a future flip would not fail it.",
      "reasoning": "Its regex passes on 'total workers in use' language as well as on 'excess beyond claim'. A future edit that flipped N's definition — breaking the padding rule's coherence, which is precisely what CR-77 was about — would leave the scenario green. Guard-looseness against a hypothetical future edit rather than a live defect, and it belongs with the verification-tier work rather than on its own.",
      "proposed_action": "Pin the definition, not merely the presence of a definition.",
      "fix_cost": "low",
      "feature_value": "core",
      "adjacent_to_blocking": true
    },
    {
      "id": "CR-91",
      "category": "in-scope-deferrable",
      "severity": "Low",
      "summary": "The journal's pre-definition overran records are ambiguous under the new N=excess reading, with no correction entry restating them.",
      "reasoning": "Sweeps 4, 5 and 6 recorded workers 4, 4 and 3 as overrun magnitudes at a time when N had no stated semantics, so it is not determinable from the record whether those are excesses or totals. Local staging rather than shipped text, and the remedy is the append-only correction entry the contract already defines — which makes it the first real use of CR-52's mechanism for a substantive fact rather than a timestamp.",
      "proposed_action": "Append a DISCOVERY correction restating the three values under the defined semantics.",
      "fix_cost": "low",
      "feature_value": "incidental",
      "adjacent_to_blocking": false
    }
  ],
  "artifacts": {
    "report_path": ".devwork/feature-qa-intra-run-lane-ownership/code-report.md",
    "journal_path": ".devwork/feature-qa-intra-run-lane-ownership/code-journal.md",
    "dispatch_journal": ".devwork/feature-qa-intra-run-lane-ownership/dispatch-journal.md",
    "swept_head": "a09e0e0"
  },
  "notes": {
    "the_rule_and_why_it_tripped": "Agreed with the operator BEFORE round 7 ran: a High, another permissive dead assertion, or a defect created by round 7's own fix stops the patching and routes §4/§7 to requirements. CR-87 is literally the third of those — the harness helper step4_disposition still computes overrun + peer_workers with no own-claim term while the document round 7 fixed now requires it, so on CR-77's own worked example the document says VOID and the measuring instrument says recorded. CR-86 is the second by the accounting this QA has used, where cr74's identical fold-blindness was called the tenth dead assertion. Both driver-verified. The operator was brought the decision rather than the driver arguing 'one more round' an eighth time, and chose to honour the rule.",
    "what_is_actually_sound": "This matters as much as the findings. Every round-7 document fix is real and verified against the EXECUTABLE recipe rather than its text: the two-space overran_claim is caught, a value-embedded `database:` no longer false-satisfies step 3b, a space-before-colon padded record is no longer flagged, a genuinely sparse one still is, step 4's formula includes the own claim, and its boundary agrees with §4 (`exceeds` = `>`). The padding-wrapper enumeration is COMPLETE as well as correct — the sweep's own mutants outside the enumeration were all caught and both claimed-equivalent mutants were upheld. `workers: N` is consistent everywhere it is used in shipped text. CR-78's cross-document contradiction is gone. cr81's rewrite can fail on all three bullets. Zero red markers remain.",
    "the_diagnosis_that_decides_it": "Five hits on ONE sentence's restatement chain: CR-58 (pairwise where §4 is global), CR-74 (pool as addend), CR-77 (own claim dropped, because `N` was undefined), CR-86 (its guard cannot see a wrapped reintroduction), CR-87 (the harness restatement now contradicts it). Every edit to §7 step 4 desynchronises a sibling — the document sentence, the harness helper, or a fold-based guard. The CONTRACT is sound; what has never been made to hold is the agreement between it and the things that verify it. That is a design question about the verification tier, not a defect to patch, which is exactly what the requirements route is for.",
    "next_state": "requirements, not integrating. The exit invariant requires a sweep that finds nothing modified after it, and this one found six — so QA does not exit clean, and saying otherwise would override the invariant rather than satisfy it.",
    "residue_routing": "CR-86, CR-87, CR-88 and CR-90 go to the new verification-tier issue. CR-89 folds to #256 (parser set). CR-91 is answered by an append-only DISCOVERY correction on the run journal — the first substantive use of the supersession mechanism CR-52 added, for a fact rather than a timestamp.",
    "disclosure": "The reviewer disclosed overran_claim: true with workers 3 — self-inflicted concurrency from running test-plugin-gates.sh in the background alongside the foreground suite — plus two read-only forge calls and the git object store. It also named the overrun as self-inflicted rather than environmental, which no previous sweep did."
  }
}

```json { "outcome": "issues-found", "summary": "SWEEP 7 (round 7 exit gate) — 6 findings against a09e0e0. NO High, no false green, no safety inversion in shipped behaviour: the shipped contract is the soundest it has been in seven rounds. But the agreed STOPPING RULE has tripped, and QA leaves the patch loop for a requirements pass on the VERIFICATION tier rather than advancing to integrating.", "findings": [ { "id": "CR-86", "category": "in-scope-deferrable", "severity": "Medium", "summary": "scenario_cr77 is fold-blind to a wrapped reintroduction of the defect it guards — CR-84's property, in a scenario round 7 itself authored.", "reasoning": "Driver-measured by insertion after a replacement probe went no-op. cr77 folds step 4 with a plain `tr '\\n' ' '` and no leading-# strip, unlike cr74 and cr78. Injecting the pre-fix phrase UNWRAPPED makes cr77 FAIL correctly; injecting the identical phrase WRAPPED across a #-comment break makes it PASS. Same insertion, only the wrap differs, isolating the wrap as sole cause. It is not literally dead — it fails on the unwrapped shape — but the wrapped shape is exactly what a reword-plus-hard-wrap produces, and CR-84 warned that CR-77's sentence is the one future fixes would touch. The F9 brief flagged that interaction explicitly and the fix stage stripped only cr74's fold. By the accounting this QA has used, where cr74's identical property was called the tenth dead assertion, this is the eleventh.", "proposed_action": "The same sed 's/^#[[:space:]]*//' cr74 and cr78 already use — but route it through the verification-tier requirements pass rather than an eighth patch round.", "fix_cost": "low", "feature_value": "core", "adjacent_to_blocking": true }, { "id": "CR-87", "category": "in-scope-deferrable", "severity": "Medium", "summary": "The harness helper step4_disposition still implements the pre-CR-77 arithmetic, so the measuring instrument now contradicts the document it measures.", "reasoning": "Driver-confirmed by reading the helper and the fixed document. step4_disposition computes total = overrun + peer_workers and has no parameter for the triaged actor's own claim; the document now requires 'every open actor's claimed workers, the TRIAGED ACTOR'S OWN claim included, plus that excess'. On CR-77's own worked example — pool 8, triaged claims 4 with excess 1, peer claims 4 — the document says VOID (9 > 8) and the helper says recorded (5 <= 8). Before the fix the two agreed; the fix changed the document and left the restatement, in the same file it was editing. No current fixture crosses the boundary, so no scenario asserts a wrong verdict today — hence Medium — but it is literally a defect created by round 7's own fix, in the permissive direction, and it is the fourth entry in this one sentence's restatement chain after CR-58, CR-74 and CR-77.", "proposed_action": "Give the helper the own-claim term, or stop it restating the formula at all.", "fix_cost": "low", "feature_value": "core", "adjacent_to_blocking": true }, { "id": "CR-88", "category": "in-scope-deferrable", "severity": "Medium", "summary": "Step 4's budget total collapses time: it sums every actor whose window intersects, not every actor concurrently open.", "reasoning": "Measured. Pool 8; triaged actor claims 2 with excess 1; peers B and C each claim 3, both intersecting the triaged window, but B released before C dispatched. Step 4's formula gives 2+3+3+1 = 9 > 8 and voids; true concurrent peak is 6 and it should record. §4's own fence is instantaneous — 'every actor dispatched and not yet released' — while step 4's restatement sums over the whole window. Conservative direction, which is the contract's deliberate error direction, and pre-existing rather than introduced by round 7, which fixed only the own-claim term. It borders #354's deferred executable sum test but is not covered by it: the prose formula itself overcounts.", "proposed_action": "Decide whether the total is instantaneous or window-wide, and say so in one place.", "fix_cost": "medium", "feature_value": "core", "adjacent_to_blocking": false }, { "id": "CR-89", "category": "in-scope-deferrable", "severity": "Low", "summary": "Step 3b residual false negative: a quoted value containing a comma before the key text still satisfies the new [{,]-anchored regex.", "reasoning": "Measured: overran_resources: {external: \"shared cache, database: also touched\", port: [], workers: 0} is genuinely missing the database key and the recipe prints no SPARSE line, because the comma inside the quoted value satisfies the anchor. Same class as CR-81 bullet 2, one comma deeper, and the reference journal's real external values do contain commas. Informational only — step 4 states a SPARSE hit never voids — which is why it is Low. Folds naturally into #256's parser set.", "proposed_action": "Fold into #256.", "fix_cost": "low", "feature_value": "incidental", "adjacent_to_blocking": false }, { "id": "CR-90", "category": "in-scope-deferrable", "severity": "Low", "summary": "cr77's semantics guard accepts the opposite definition of N, so a future flip would not fail it.", "reasoning": "Its regex passes on 'total workers in use' language as well as on 'excess beyond claim'. A future edit that flipped N's definition — breaking the padding rule's coherence, which is precisely what CR-77 was about — would leave the scenario green. Guard-looseness against a hypothetical future edit rather than a live defect, and it belongs with the verification-tier work rather than on its own.", "proposed_action": "Pin the definition, not merely the presence of a definition.", "fix_cost": "low", "feature_value": "core", "adjacent_to_blocking": true }, { "id": "CR-91", "category": "in-scope-deferrable", "severity": "Low", "summary": "The journal's pre-definition overran records are ambiguous under the new N=excess reading, with no correction entry restating them.", "reasoning": "Sweeps 4, 5 and 6 recorded workers 4, 4 and 3 as overrun magnitudes at a time when N had no stated semantics, so it is not determinable from the record whether those are excesses or totals. Local staging rather than shipped text, and the remedy is the append-only correction entry the contract already defines — which makes it the first real use of CR-52's mechanism for a substantive fact rather than a timestamp.", "proposed_action": "Append a DISCOVERY correction restating the three values under the defined semantics.", "fix_cost": "low", "feature_value": "incidental", "adjacent_to_blocking": false } ], "artifacts": { "report_path": ".devwork/feature-qa-intra-run-lane-ownership/code-report.md", "journal_path": ".devwork/feature-qa-intra-run-lane-ownership/code-journal.md", "dispatch_journal": ".devwork/feature-qa-intra-run-lane-ownership/dispatch-journal.md", "swept_head": "a09e0e0" }, "notes": { "the_rule_and_why_it_tripped": "Agreed with the operator BEFORE round 7 ran: a High, another permissive dead assertion, or a defect created by round 7's own fix stops the patching and routes §4/§7 to requirements. CR-87 is literally the third of those — the harness helper step4_disposition still computes overrun + peer_workers with no own-claim term while the document round 7 fixed now requires it, so on CR-77's own worked example the document says VOID and the measuring instrument says recorded. CR-86 is the second by the accounting this QA has used, where cr74's identical fold-blindness was called the tenth dead assertion. Both driver-verified. The operator was brought the decision rather than the driver arguing 'one more round' an eighth time, and chose to honour the rule.", "what_is_actually_sound": "This matters as much as the findings. Every round-7 document fix is real and verified against the EXECUTABLE recipe rather than its text: the two-space overran_claim is caught, a value-embedded `database:` no longer false-satisfies step 3b, a space-before-colon padded record is no longer flagged, a genuinely sparse one still is, step 4's formula includes the own claim, and its boundary agrees with §4 (`exceeds` = `>`). The padding-wrapper enumeration is COMPLETE as well as correct — the sweep's own mutants outside the enumeration were all caught and both claimed-equivalent mutants were upheld. `workers: N` is consistent everywhere it is used in shipped text. CR-78's cross-document contradiction is gone. cr81's rewrite can fail on all three bullets. Zero red markers remain.", "the_diagnosis_that_decides_it": "Five hits on ONE sentence's restatement chain: CR-58 (pairwise where §4 is global), CR-74 (pool as addend), CR-77 (own claim dropped, because `N` was undefined), CR-86 (its guard cannot see a wrapped reintroduction), CR-87 (the harness restatement now contradicts it). Every edit to §7 step 4 desynchronises a sibling — the document sentence, the harness helper, or a fold-based guard. The CONTRACT is sound; what has never been made to hold is the agreement between it and the things that verify it. That is a design question about the verification tier, not a defect to patch, which is exactly what the requirements route is for.", "next_state": "requirements, not integrating. The exit invariant requires a sweep that finds nothing modified after it, and this one found six — so QA does not exit clean, and saying otherwise would override the invariant rather than satisfy it.", "residue_routing": "CR-86, CR-87, CR-88 and CR-90 go to the new verification-tier issue. CR-89 folds to #256 (parser set). CR-91 is answered by an append-only DISCOVERY correction on the run journal — the first substantive use of the supersession mechanism CR-52 added, for a fact rather than a timestamp.", "disclosure": "The reviewer disclosed overran_claim: true with workers 3 — self-inflicted concurrency from running test-plugin-gates.sh in the background alongside the foreground suite — plus two read-only forge calls and the git object store. It also named the overrun as self-inflicted rather than environmental, which no previous sweep did." } } ```

jbr870 commented

2026-08-30 07:01:50 +00:00

Author

Owner

{
  "next_state": "requirements",
  "produced": [
    {
      "kind": "qa-report",
      "ref": "2399",
      "summary": "code phase=fix — 7 findings fixed plus CR-85, zero red markers, all 4 gates green"
    },
    {
      "kind": "qa-report",
      "ref": "latest",
      "summary": "code phase=validate — sweep 7, 6 findings, no High, stopping rule tripped"
    },
    {
      "kind": "code-bundle",
      "ref": "a09e0e0",
      "summary": "the swept HEAD: fix commit a09e0e0 on test_commit aa95452"
    }
  ],
  "findings": [
    {
      "category": "in-scope-deferrable",
      "severity": "medium",
      "summary": "[code CR-86] scenario_cr77 is fold-blind to a wrapped reintroduction of the defect it guards — CR-84's property, in a scenario round 7 itself authored.",
      "reasoning": "Driver-measured by insertion after a replacement probe went no-op. cr77 folds step 4 with a plain `tr '\\n' ' '` and no leading-# strip, unlike cr74 and cr78. Injecting the pre-fix phrase UNWRAPPED makes cr77 FAIL correctly; injecting the identical phrase WRAPPED across a #-comment break makes it PASS. Same insertion, only the wrap differs, isolating the wrap as sole cause. It is not literally dead — it fails on the unwrapped shape — but the wrapped shape is exactly what a reword-plus-hard-wrap produces, and CR-84 warned that CR-77's sentence is the one future fixes would touch. The F9 brief flagged that interaction explicitly and the fix stage stripped only cr74's fold. By the accounting this QA has used, where cr74's identical property was called the tenth dead assertion, this is the eleventh.",
      "proposed_action": "The same sed 's/^#[[:space:]]*//' cr74 and cr78 already use — but route it through the verification-tier requirements pass rather than an eighth patch round.",
      "fix_cost": "low",
      "feature_value": "core",
      "adjacent_to_blocking": true,
      "id": "F-PO-43-11-1"
    },
    {
      "category": "in-scope-deferrable",
      "severity": "medium",
      "summary": "[code CR-87] The harness helper step4_disposition still implements the pre-CR-77 arithmetic, so the measuring instrument now contradicts the document it measures.",
      "reasoning": "Driver-confirmed by reading the helper and the fixed document. step4_disposition computes total = overrun + peer_workers and has no parameter for the triaged actor's own claim; the document now requires 'every open actor's claimed workers, the TRIAGED ACTOR'S OWN claim included, plus that excess'. On CR-77's own worked example — pool 8, triaged claims 4 with excess 1, peer claims 4 — the document says VOID (9 > 8) and the helper says recorded (5 <= 8). Before the fix the two agreed; the fix changed the document and left the restatement, in the same file it was editing. No current fixture crosses the boundary, so no scenario asserts a wrong verdict today — hence Medium — but it is literally a defect created by round 7's own fix, in the permissive direction, and it is the fourth entry in this one sentence's restatement chain after CR-58, CR-74 and CR-77.",
      "proposed_action": "Give the helper the own-claim term, or stop it restating the formula at all.",
      "fix_cost": "low",
      "feature_value": "core",
      "adjacent_to_blocking": true,
      "id": "F-PO-43-11-2"
    },
    {
      "category": "in-scope-deferrable",
      "severity": "medium",
      "summary": "[code CR-88] Step 4's budget total collapses time: it sums every actor whose window intersects, not every actor concurrently open.",
      "reasoning": "Measured. Pool 8; triaged actor claims 2 with excess 1; peers B and C each claim 3, both intersecting the triaged window, but B released before C dispatched. Step 4's formula gives 2+3+3+1 = 9 > 8 and voids; true concurrent peak is 6 and it should record. §4's own fence is instantaneous — 'every actor dispatched and not yet released' — while step 4's restatement sums over the whole window. Conservative direction, which is the contract's deliberate error direction, and pre-existing rather than introduced by round 7, which fixed only the own-claim term. It borders #354's deferred executable sum test but is not covered by it: the prose formula itself overcounts.",
      "proposed_action": "Decide whether the total is instantaneous or window-wide, and say so in one place.",
      "fix_cost": "medium",
      "feature_value": "core",
      "adjacent_to_blocking": false,
      "id": "F-PO-43-11-3"
    },
    {
      "category": "in-scope-deferrable",
      "severity": "low",
      "summary": "[code CR-89] Step 3b residual false negative: a quoted value containing a comma before the key text still satisfies the new [{,]-anchored regex.",
      "reasoning": "Measured: overran_resources: {external: \"shared cache, database: also touched\", port: [], workers: 0} is genuinely missing the database key and the recipe prints no SPARSE line, because the comma inside the quoted value satisfies the anchor. Same class as CR-81 bullet 2, one comma deeper, and the reference journal's real external values do contain commas. Informational only — step 4 states a SPARSE hit never voids — which is why it is Low. Folds naturally into #256's parser set.",
      "proposed_action": "Fold into #256.",
      "fix_cost": "low",
      "feature_value": "incidental",
      "adjacent_to_blocking": false,
      "id": "F-PO-43-11-4"
    },
    {
      "category": "in-scope-deferrable",
      "severity": "low",
      "summary": "[code CR-90] cr77's semantics guard accepts the opposite definition of N, so a future flip would not fail it.",
      "reasoning": "Its regex passes on 'total workers in use' language as well as on 'excess beyond claim'. A future edit that flipped N's definition — breaking the padding rule's coherence, which is precisely what CR-77 was about — would leave the scenario green. Guard-looseness against a hypothetical future edit rather than a live defect, and it belongs with the verification-tier work rather than on its own.",
      "proposed_action": "Pin the definition, not merely the presence of a definition.",
      "fix_cost": "low",
      "feature_value": "core",
      "adjacent_to_blocking": true,
      "id": "F-PO-43-11-5"
    },
    {
      "category": "in-scope-deferrable",
      "severity": "low",
      "summary": "[code CR-91] The journal's pre-definition overran records are ambiguous under the new N=excess reading, with no correction entry restating them.",
      "reasoning": "Sweeps 4, 5 and 6 recorded workers 4, 4 and 3 as overrun magnitudes at a time when N had no stated semantics, so it is not determinable from the record whether those are excesses or totals. Local staging rather than shipped text, and the remedy is the append-only correction entry the contract already defines — which makes it the first real use of CR-52's mechanism for a substantive fact rather than a timestamp.",
      "proposed_action": "Append a DISCOVERY correction restating the three values under the defined semantics.",
      "fix_cost": "low",
      "feature_value": "incidental",
      "adjacent_to_blocking": false,
      "id": "F-PO-43-11-6"
    }
  ],
  "pending_decisions": [
    {
      "id": "D-PO-43-11-1",
      "type": "scope-disposition",
      "blocking": false,
      "question": "[CR-86] scenario_cr77 is fold-blind to a wrapped reintroduction of the defect it guards — CR-84's property, in a scenario round 7 itself authored. — fix now, spawn a follow-up issue, or accept?",
      "options": [
        "fix-now",
        "defer-to-issue",
        "accept"
      ],
      "recommended": "defer-to-issue",
      "finding_ref": "F-PO-43-11-1",
      "reasoning": "The operator has honoured the agreed stopping rule, so this round does not patch. Every finding routes to the verification-tier requirements pass, to #256, or to a journal correction."
    },
    {
      "id": "D-PO-43-11-2",
      "type": "scope-disposition",
      "blocking": false,
      "question": "[CR-87] The harness helper step4_disposition still implements the pre-CR-77 arithmetic, so the measuring instrument now contradicts the document it measures. — fix now, spawn a follow-up issue, or accept?",
      "options": [
        "fix-now",
        "defer-to-issue",
        "accept"
      ],
      "recommended": "defer-to-issue",
      "finding_ref": "F-PO-43-11-2",
      "reasoning": "The operator has honoured the agreed stopping rule, so this round does not patch. Every finding routes to the verification-tier requirements pass, to #256, or to a journal correction."
    },
    {
      "id": "D-PO-43-11-3",
      "type": "scope-disposition",
      "blocking": false,
      "question": "[CR-88] Step 4's budget total collapses time: it sums every actor whose window intersects, not every actor concurrently open. — fix now, spawn a follow-up issue, or accept?",
      "options": [
        "fix-now",
        "defer-to-issue",
        "accept"
      ],
      "recommended": "defer-to-issue",
      "finding_ref": "F-PO-43-11-3",
      "reasoning": "The operator has honoured the agreed stopping rule, so this round does not patch. Every finding routes to the verification-tier requirements pass, to #256, or to a journal correction."
    },
    {
      "id": "D-PO-43-11-4",
      "type": "scope-disposition",
      "blocking": false,
      "question": "[CR-89] Step 3b residual false negative: a quoted value containing a comma before the key text still satisfies the new [{,]-anchored regex. — fix now, spawn a follow-up issue, or accept?",
      "options": [
        "fix-now",
        "defer-to-issue",
        "accept"
      ],
      "recommended": "defer-to-issue",
      "finding_ref": "F-PO-43-11-4",
      "reasoning": "The operator has honoured the agreed stopping rule, so this round does not patch. Every finding routes to the verification-tier requirements pass, to #256, or to a journal correction."
    },
    {
      "id": "D-PO-43-11-5",
      "type": "scope-disposition",
      "blocking": false,
      "question": "[CR-90] cr77's semantics guard accepts the opposite definition of N, so a future flip would not fail it. — fix now, spawn a follow-up issue, or accept?",
      "options": [
        "fix-now",
        "defer-to-issue",
        "accept"
      ],
      "recommended": "defer-to-issue",
      "finding_ref": "F-PO-43-11-5",
      "reasoning": "The operator has honoured the agreed stopping rule, so this round does not patch. Every finding routes to the verification-tier requirements pass, to #256, or to a journal correction."
    },
    {
      "id": "D-PO-43-11-6",
      "type": "scope-disposition",
      "blocking": false,
      "question": "[CR-91] The journal's pre-definition overran records are ambiguous under the new N=excess reading, with no correction entry restating them. — fix now, spawn a follow-up issue, or accept?",
      "options": [
        "fix-now",
        "defer-to-issue",
        "accept"
      ],
      "recommended": "defer-to-issue",
      "finding_ref": "F-PO-43-11-6",
      "reasoning": "The operator has honoured the agreed stopping rule, so this round does not patch. Every finding routes to the verification-tier requirements pass, to #256, or to a journal correction."
    }
  ],
  "suite": {
    "source": "git",
    "sha": "a09e0e0abbf817ec5d1ce6fd27b78866a306d72c",
    "dirty": false
  }
}

```json { "next_state": "requirements", "produced": [ { "kind": "qa-report", "ref": "2399", "summary": "code phase=fix — 7 findings fixed plus CR-85, zero red markers, all 4 gates green" }, { "kind": "qa-report", "ref": "latest", "summary": "code phase=validate — sweep 7, 6 findings, no High, stopping rule tripped" }, { "kind": "code-bundle", "ref": "a09e0e0", "summary": "the swept HEAD: fix commit a09e0e0 on test_commit aa95452" } ], "findings": [ { "category": "in-scope-deferrable", "severity": "medium", "summary": "[code CR-86] scenario_cr77 is fold-blind to a wrapped reintroduction of the defect it guards — CR-84's property, in a scenario round 7 itself authored.", "reasoning": "Driver-measured by insertion after a replacement probe went no-op. cr77 folds step 4 with a plain `tr '\\n' ' '` and no leading-# strip, unlike cr74 and cr78. Injecting the pre-fix phrase UNWRAPPED makes cr77 FAIL correctly; injecting the identical phrase WRAPPED across a #-comment break makes it PASS. Same insertion, only the wrap differs, isolating the wrap as sole cause. It is not literally dead — it fails on the unwrapped shape — but the wrapped shape is exactly what a reword-plus-hard-wrap produces, and CR-84 warned that CR-77's sentence is the one future fixes would touch. The F9 brief flagged that interaction explicitly and the fix stage stripped only cr74's fold. By the accounting this QA has used, where cr74's identical property was called the tenth dead assertion, this is the eleventh.", "proposed_action": "The same sed 's/^#[[:space:]]*//' cr74 and cr78 already use — but route it through the verification-tier requirements pass rather than an eighth patch round.", "fix_cost": "low", "feature_value": "core", "adjacent_to_blocking": true, "id": "F-PO-43-11-1" }, { "category": "in-scope-deferrable", "severity": "medium", "summary": "[code CR-87] The harness helper step4_disposition still implements the pre-CR-77 arithmetic, so the measuring instrument now contradicts the document it measures.", "reasoning": "Driver-confirmed by reading the helper and the fixed document. step4_disposition computes total = overrun + peer_workers and has no parameter for the triaged actor's own claim; the document now requires 'every open actor's claimed workers, the TRIAGED ACTOR'S OWN claim included, plus that excess'. On CR-77's own worked example — pool 8, triaged claims 4 with excess 1, peer claims 4 — the document says VOID (9 > 8) and the helper says recorded (5 <= 8). Before the fix the two agreed; the fix changed the document and left the restatement, in the same file it was editing. No current fixture crosses the boundary, so no scenario asserts a wrong verdict today — hence Medium — but it is literally a defect created by round 7's own fix, in the permissive direction, and it is the fourth entry in this one sentence's restatement chain after CR-58, CR-74 and CR-77.", "proposed_action": "Give the helper the own-claim term, or stop it restating the formula at all.", "fix_cost": "low", "feature_value": "core", "adjacent_to_blocking": true, "id": "F-PO-43-11-2" }, { "category": "in-scope-deferrable", "severity": "medium", "summary": "[code CR-88] Step 4's budget total collapses time: it sums every actor whose window intersects, not every actor concurrently open.", "reasoning": "Measured. Pool 8; triaged actor claims 2 with excess 1; peers B and C each claim 3, both intersecting the triaged window, but B released before C dispatched. Step 4's formula gives 2+3+3+1 = 9 > 8 and voids; true concurrent peak is 6 and it should record. §4's own fence is instantaneous — 'every actor dispatched and not yet released' — while step 4's restatement sums over the whole window. Conservative direction, which is the contract's deliberate error direction, and pre-existing rather than introduced by round 7, which fixed only the own-claim term. It borders #354's deferred executable sum test but is not covered by it: the prose formula itself overcounts.", "proposed_action": "Decide whether the total is instantaneous or window-wide, and say so in one place.", "fix_cost": "medium", "feature_value": "core", "adjacent_to_blocking": false, "id": "F-PO-43-11-3" }, { "category": "in-scope-deferrable", "severity": "low", "summary": "[code CR-89] Step 3b residual false negative: a quoted value containing a comma before the key text still satisfies the new [{,]-anchored regex.", "reasoning": "Measured: overran_resources: {external: \"shared cache, database: also touched\", port: [], workers: 0} is genuinely missing the database key and the recipe prints no SPARSE line, because the comma inside the quoted value satisfies the anchor. Same class as CR-81 bullet 2, one comma deeper, and the reference journal's real external values do contain commas. Informational only — step 4 states a SPARSE hit never voids — which is why it is Low. Folds naturally into #256's parser set.", "proposed_action": "Fold into #256.", "fix_cost": "low", "feature_value": "incidental", "adjacent_to_blocking": false, "id": "F-PO-43-11-4" }, { "category": "in-scope-deferrable", "severity": "low", "summary": "[code CR-90] cr77's semantics guard accepts the opposite definition of N, so a future flip would not fail it.", "reasoning": "Its regex passes on 'total workers in use' language as well as on 'excess beyond claim'. A future edit that flipped N's definition — breaking the padding rule's coherence, which is precisely what CR-77 was about — would leave the scenario green. Guard-looseness against a hypothetical future edit rather than a live defect, and it belongs with the verification-tier work rather than on its own.", "proposed_action": "Pin the definition, not merely the presence of a definition.", "fix_cost": "low", "feature_value": "core", "adjacent_to_blocking": true, "id": "F-PO-43-11-5" }, { "category": "in-scope-deferrable", "severity": "low", "summary": "[code CR-91] The journal's pre-definition overran records are ambiguous under the new N=excess reading, with no correction entry restating them.", "reasoning": "Sweeps 4, 5 and 6 recorded workers 4, 4 and 3 as overrun magnitudes at a time when N had no stated semantics, so it is not determinable from the record whether those are excesses or totals. Local staging rather than shipped text, and the remedy is the append-only correction entry the contract already defines — which makes it the first real use of CR-52's mechanism for a substantive fact rather than a timestamp.", "proposed_action": "Append a DISCOVERY correction restating the three values under the defined semantics.", "fix_cost": "low", "feature_value": "incidental", "adjacent_to_blocking": false, "id": "F-PO-43-11-6" } ], "pending_decisions": [ { "id": "D-PO-43-11-1", "type": "scope-disposition", "blocking": false, "question": "[CR-86] scenario_cr77 is fold-blind to a wrapped reintroduction of the defect it guards — CR-84's property, in a scenario round 7 itself authored. — fix now, spawn a follow-up issue, or accept?", "options": [ "fix-now", "defer-to-issue", "accept" ], "recommended": "defer-to-issue", "finding_ref": "F-PO-43-11-1", "reasoning": "The operator has honoured the agreed stopping rule, so this round does not patch. Every finding routes to the verification-tier requirements pass, to #256, or to a journal correction." }, { "id": "D-PO-43-11-2", "type": "scope-disposition", "blocking": false, "question": "[CR-87] The harness helper step4_disposition still implements the pre-CR-77 arithmetic, so the measuring instrument now contradicts the document it measures. — fix now, spawn a follow-up issue, or accept?", "options": [ "fix-now", "defer-to-issue", "accept" ], "recommended": "defer-to-issue", "finding_ref": "F-PO-43-11-2", "reasoning": "The operator has honoured the agreed stopping rule, so this round does not patch. Every finding routes to the verification-tier requirements pass, to #256, or to a journal correction." }, { "id": "D-PO-43-11-3", "type": "scope-disposition", "blocking": false, "question": "[CR-88] Step 4's budget total collapses time: it sums every actor whose window intersects, not every actor concurrently open. — fix now, spawn a follow-up issue, or accept?", "options": [ "fix-now", "defer-to-issue", "accept" ], "recommended": "defer-to-issue", "finding_ref": "F-PO-43-11-3", "reasoning": "The operator has honoured the agreed stopping rule, so this round does not patch. Every finding routes to the verification-tier requirements pass, to #256, or to a journal correction." }, { "id": "D-PO-43-11-4", "type": "scope-disposition", "blocking": false, "question": "[CR-89] Step 3b residual false negative: a quoted value containing a comma before the key text still satisfies the new [{,]-anchored regex. — fix now, spawn a follow-up issue, or accept?", "options": [ "fix-now", "defer-to-issue", "accept" ], "recommended": "defer-to-issue", "finding_ref": "F-PO-43-11-4", "reasoning": "The operator has honoured the agreed stopping rule, so this round does not patch. Every finding routes to the verification-tier requirements pass, to #256, or to a journal correction." }, { "id": "D-PO-43-11-5", "type": "scope-disposition", "blocking": false, "question": "[CR-90] cr77's semantics guard accepts the opposite definition of N, so a future flip would not fail it. — fix now, spawn a follow-up issue, or accept?", "options": [ "fix-now", "defer-to-issue", "accept" ], "recommended": "defer-to-issue", "finding_ref": "F-PO-43-11-5", "reasoning": "The operator has honoured the agreed stopping rule, so this round does not patch. Every finding routes to the verification-tier requirements pass, to #256, or to a journal correction." }, { "id": "D-PO-43-11-6", "type": "scope-disposition", "blocking": false, "question": "[CR-91] The journal's pre-definition overran records are ambiguous under the new N=excess reading, with no correction entry restating them. — fix now, spawn a follow-up issue, or accept?", "options": [ "fix-now", "defer-to-issue", "accept" ], "recommended": "defer-to-issue", "finding_ref": "F-PO-43-11-6", "reasoning": "The operator has honoured the agreed stopping rule, so this round does not patch. Every finding routes to the verification-tier requirements pass, to #256, or to a journal correction." } ], "suite": { "source": "git", "sha": "a09e0e0abbf817ec5d1ce6fd27b78866a306d72c", "dirty": false } } ```

jbr870 added

phase/requirements

and removed

phase/qa

labels

2026-08-30 07:01:51 +00:00

jbr870 commented

Author

Owner

{
  "status": "resolved",
  "chosen_option": "defer-to-issue",
  "rationale": "[CR-86] Goes to the verification-tier requirements pass, not to a patch. The one-line sed that fixes it is known and is not the point: this is the eleventh instance of a class where a guard cannot see the shape a future edit most likely produces, and the round that authored it had been warned in its own brief that CR-77 s sentence was the one CR-84 said future fixes would touch. Fixing the instance again while leaving the pattern is what the stopping rule exists to prevent. Resolved by the driver under the operator's standing authority to run the QA phase to completion, stopping only on a blocking decision. Where this resolution differs from disposition-recommend.sh's answer it says so explicitly and gives the reason; the recommender scores each finding in isolation and cannot see that five of these are one recurring class.",
  "rejected_alternative": "fix-now is genuinely tempting and would take minutes. Turned down because the operator honoured the stopping rule on exactly this reasoning, and because a fold fix applied for the third time without addressing why folds keep being written without the strip would leave the twelfth instance to be found by whoever edits step 4 next."
}

```json { "status": "resolved", "chosen_option": "defer-to-issue", "rationale": "[CR-86] Goes to the verification-tier requirements pass, not to a patch. The one-line sed that fixes it is known and is not the point: this is the eleventh instance of a class where a guard cannot see the shape a future edit most likely produces, and the round that authored it had been warned in its own brief that CR-77 s sentence was the one CR-84 said future fixes would touch. Fixing the instance again while leaving the pattern is what the stopping rule exists to prevent. Resolved by the driver under the operator's standing authority to run the QA phase to completion, stopping only on a blocking decision. Where this resolution differs from disposition-recommend.sh's answer it says so explicitly and gives the reason; the recommender scores each finding in isolation and cannot see that five of these are one recurring class.", "rejected_alternative": "fix-now is genuinely tempting and would take minutes. Turned down because the operator honoured the stopping rule on exactly this reasoning, and because a fold fix applied for the third time without addressing why folds keep being written without the strip would leave the twelfth instance to be found by whoever edits step 4 next." } ```

jbr870 commented

Author

Owner

{
  "status": "resolved",
  "chosen_option": "defer-to-issue",
  "rationale": "[CR-87] The clearest single argument for the requirements route, so it belongs in the pass it argues for. The document and the instrument that measures it now disagree about the same worked example, and they disagree because a fix changed one and not the other IN THE SAME FILE IT WAS EDITING. That is not a bug to patch; it is evidence that nothing keeps the two in step, which is precisely the question the verification-tier pass has to answer. Resolved by the driver under the operator's standing authority to run the QA phase to completion, stopping only on a blocking decision. Where this resolution differs from disposition-recommend.sh's answer it says so explicitly and gives the reason; the recommender scores each finding in isolation and cannot see that five of these are one recurring class.",
  "rejected_alternative": "fix-now would restore agreement today at the cost of the evidence for why agreement keeps breaking. Turned down for that reason: this finding is more useful as an exhibit than as a closed ticket, and the fourth entry in one sentence s restatement chain should be read as a pattern rather than dispatched as a fourth fix."
}

```json { "status": "resolved", "chosen_option": "defer-to-issue", "rationale": "[CR-87] The clearest single argument for the requirements route, so it belongs in the pass it argues for. The document and the instrument that measures it now disagree about the same worked example, and they disagree because a fix changed one and not the other IN THE SAME FILE IT WAS EDITING. That is not a bug to patch; it is evidence that nothing keeps the two in step, which is precisely the question the verification-tier pass has to answer. Resolved by the driver under the operator's standing authority to run the QA phase to completion, stopping only on a blocking decision. Where this resolution differs from disposition-recommend.sh's answer it says so explicitly and gives the reason; the recommender scores each finding in isolation and cannot see that five of these are one recurring class.", "rejected_alternative": "fix-now would restore agreement today at the cost of the evidence for why agreement keeps breaking. Turned down for that reason: this finding is more useful as an exhibit than as a closed ticket, and the fourth entry in one sentence s restatement chain should be read as a pattern rather than dispatched as a fourth fix." } ```

jbr870 commented

Author

Owner

{
  "status": "resolved",
  "chosen_option": "defer-to-issue",
  "rationale": "[CR-88] A real semantic question rather than a defect: is the budget total instantaneous, as §4 s fence says, or window-wide, as step 4 s restatement computes? It needs deciding once and stating in one place, and the answer interacts with #354 s deferred executable sum test, which cannot be built until the semantics are settled. Conservative direction and pre-existing, so nothing is unsafe while it waits. Resolved by the driver under the operator's standing authority to run the QA phase to completion, stopping only on a blocking decision. Where this resolution differs from disposition-recommend.sh's answer it says so explicitly and gives the reason; the recommender scores each finding in isolation and cannot see that five of these are one recurring class.",
  "rejected_alternative": "fix-now was weighed because the overcount is measurable today with three staggered peers. Turned down because picking a reading unilaterally inside a QA round is how §7 step 4 acquired four of its five defects — an undefined term settled by whoever edited last."
}

```json { "status": "resolved", "chosen_option": "defer-to-issue", "rationale": "[CR-88] A real semantic question rather than a defect: is the budget total instantaneous, as §4 s fence says, or window-wide, as step 4 s restatement computes? It needs deciding once and stating in one place, and the answer interacts with #354 s deferred executable sum test, which cannot be built until the semantics are settled. Conservative direction and pre-existing, so nothing is unsafe while it waits. Resolved by the driver under the operator's standing authority to run the QA phase to completion, stopping only on a blocking decision. Where this resolution differs from disposition-recommend.sh's answer it says so explicitly and gives the reason; the recommender scores each finding in isolation and cannot see that five of these are one recurring class.", "rejected_alternative": "fix-now was weighed because the overcount is measurable today with three staggered peers. Turned down because picking a reading unilaterally inside a QA round is how §7 step 4 acquired four of its five defects — an undefined term settled by whoever edited last." } ```

jbr870 commented

2026-08-30 07:02:38 +00:00

Author

Owner

{
  "status": "resolved",
  "chosen_option": "defer-to-issue",
  "rationale": "[CR-89] A clean fold into #256, which holds the parser and spelling set. One comma deeper than CR-81 bullet 2, informational only because step 4 states a SPARSE hit never voids, and best fixed as a unit by someone holding the whole parser in their head rather than one anchor at a time — the same reasoning that sent CR-60, CR-61 and CR-82 there. Resolved by the driver under the operator's standing authority to run the QA phase to completion, stopping only on a blocking decision. Where this resolution differs from disposition-recommend.sh's answer it says so explicitly and gives the reason; the recommender scores each finding in isolation and cannot see that five of these are one recurring class.",
  "rejected_alternative": "fix-now had a case since the reference journal s real external values do contain commas, so the input occurs here. Turned down on cohesion: this is the fourth near-miss in the same regex family, and fixing them one at a time is what produced the fourth."
}

```json { "status": "resolved", "chosen_option": "defer-to-issue", "rationale": "[CR-89] A clean fold into #256, which holds the parser and spelling set. One comma deeper than CR-81 bullet 2, informational only because step 4 states a SPARSE hit never voids, and best fixed as a unit by someone holding the whole parser in their head rather than one anchor at a time — the same reasoning that sent CR-60, CR-61 and CR-82 there. Resolved by the driver under the operator's standing authority to run the QA phase to completion, stopping only on a blocking decision. Where this resolution differs from disposition-recommend.sh's answer it says so explicitly and gives the reason; the recommender scores each finding in isolation and cannot see that five of these are one recurring class.", "rejected_alternative": "fix-now had a case since the reference journal s real external values do contain commas, so the input occurs here. Turned down on cohesion: this is the fourth near-miss in the same regex family, and fixing them one at a time is what produced the fourth." } ```

jbr870 commented

Author

Owner

{
  "status": "resolved",
  "chosen_option": "defer-to-issue",
  "rationale": "[CR-90] Guard-looseness against a future edit rather than a live defect, and it belongs with the verification-tier work because it is the same question in miniature: the guard pins that a definition EXISTS rather than which definition it is, so the flip that would break the padding rule s coherence passes it. Pinning the definition properly is part of deciding how these guards should be written, not a separate errand. Resolved by the driver under the operator's standing authority to run the QA phase to completion, stopping only on a blocking decision. Where this resolution differs from disposition-recommend.sh's answer it says so explicitly and gives the reason; the recommender scores each finding in isolation and cannot see that five of these are one recurring class.",
  "rejected_alternative": "accept was arguable since nothing is wrong today and the scenario does catch the absence of any definition. Turned down because CR-77 existed precisely because that term was undefined, and a guard that would not notice it being redefined is a thin guard over an expensive lesson."
}

```json { "status": "resolved", "chosen_option": "defer-to-issue", "rationale": "[CR-90] Guard-looseness against a future edit rather than a live defect, and it belongs with the verification-tier work because it is the same question in miniature: the guard pins that a definition EXISTS rather than which definition it is, so the flip that would break the padding rule s coherence passes it. Pinning the definition properly is part of deciding how these guards should be written, not a separate errand. Resolved by the driver under the operator's standing authority to run the QA phase to completion, stopping only on a blocking decision. Where this resolution differs from disposition-recommend.sh's answer it says so explicitly and gives the reason; the recommender scores each finding in isolation and cannot see that five of these are one recurring class.", "rejected_alternative": "accept was arguable since nothing is wrong today and the scenario does catch the absence of any definition. Turned down because CR-77 existed precisely because that term was undefined, and a guard that would not notice it being redefined is a thin guard over an expensive lesson." } ```

jbr870 commented

2026-08-30 07:02:38 +00:00

Author

Owner

{
  "status": "resolved",
  "chosen_option": "defer-to-issue",
  "rationale": "[CR-91] Answered by an append-only DISCOVERY correction on the run journal rather than by a code change — and the driver is writing it now, so the deferral is to the mechanism rather than to a future round. It is the first substantive use of the supersession pattern CR-52 added: previous corrections restated a timestamp or a missing field, this one restates three recorded magnitudes under a definition that did not exist when they were written. Resolved by the driver under the operator's standing authority to run the QA phase to completion, stopping only on a blocking decision. Where this resolution differs from disposition-recommend.sh's answer it says so explicitly and gives the reason; the recommender scores each finding in isolation and cannot see that five of these are one recurring class.",
  "rejected_alternative": "fix-now in the sense of a repository change does not apply — nothing shipped is wrong. accept was rejected because the three values are genuinely ambiguous under the new reading and the contract now provides exactly the mechanism for saying so."
}

```json { "status": "resolved", "chosen_option": "defer-to-issue", "rationale": "[CR-91] Answered by an append-only DISCOVERY correction on the run journal rather than by a code change — and the driver is writing it now, so the deferral is to the mechanism rather than to a future round. It is the first substantive use of the supersession pattern CR-52 added: previous corrections restated a timestamp or a missing field, this one restates three recorded magnitudes under a definition that did not exist when they were written. Resolved by the driver under the operator's standing authority to run the QA phase to completion, stopping only on a blocking decision. Where this resolution differs from disposition-recommend.sh's answer it says so explicitly and gives the reason; the recommender scores each finding in isolation and cannot see that five of these are one recurring class.", "rejected_alternative": "fix-now in the sense of a repository change does not apply — nothing shipped is wrong. accept was rejected because the three values are genuinely ambiguous under the new reading and the contract now provides exactly the mechanism for saying so." } ```

jbr870 referenced this issue

2026-08-30 07:03:10 +00:00

run-resource-claims §7 step 4: how do the rule, its restatements and its guards stay in agreement? #483

jbr870 commented

2026-08-30 07:03:10 +00:00

Author

Owner

Linked: this issue is sibling #483 (recorded by the devwork pipeline).

Linked: this issue is **sibling** #483 (recorded by the devwork pipeline).

jbr870 referenced this issue

2026-08-30 07:03:40 +00:00

run-resource-claims: eleven parser and vocabulary gaps in the shipped recipes and helpers #256

jbr870 referenced this issue from a commit

test(43-qa-intra-run-lane-ownership): [WU-43-3-1] mechanical gate for the run-resource-claims contract

jbr870 referenced this issue from a commit

docs: capture 3 learnings from /dev:develop on #43 (gate measurement, in-flight allowances, wrapped anchors)

jbr870 referenced this issue from a commit

test(43-qa-intra-run-lane-ownership): red regression tests for the QA round's 26 findings

jbr870 referenced this issue from a commit

fix(43-qa-intra-run-lane-ownership): repair the contract's executable mechanisms and reachability

jbr870 referenced this issue from a commit

fix(43-qa-intra-run-lane-ownership): stop the harness masking regressions in its own contract

jbr870 referenced this issue from a commit

test(43-qa-intra-run-lane-ownership): red regression tests for the sweep's 12 in-scope findings

jbr870 referenced this issue from a commit

test(43-qa-intra-run-lane-ownership): red tests for round 3, framed at the drift class

jbr870 referenced this issue from a commit

test(43-qa-intra-run-lane-ownership): red tests for round 4's two blockers and four adjacents

jbr870 referenced this issue from a commit

test(43-qa-intra-run-lane-ownership): red tests for round 5, written against a realistic peer

jbr870 referenced this issue from a commit

test(43-qa-intra-run-lane-ownership): red tests for round 6, all in §7's triage steps

jbr870 referenced this issue from a commit