From 2873dc1e48c230d8fc1d5335bc1f05cb98a9db16 Mon Sep 17 00:00:00 2001
From: REPPL <77722411+REPPL@users.noreply.github.com>
Date: Sat, 29 Aug 2026 09:10:28 +0100
Subject: [PATCH] chore: capture the findings from the itd-150..162
 implementation run

Seven records the orchestration hit and had not yet written down, including
the spec-close gap that leaves twelve delivered intents out of the next
derived changelog.

Assisted-by: Claude:claude-opus-5[1m]
---
 ...a-merged-implementation-to-closing-its-spec-so.md | 12 ++++++++++++
 ...n-gate-validates-the-assisted-by-trailer-s-sha.md | 12 ++++++++++++
 ...rted-a-pull-request-as-conflicting-when-it-mer.md | 12 ++++++++++++
 ...l-reviews-over-the-assembled-multi-branch-diff.md | 12 ++++++++++++
 ...eport-success-while-pushing-nothing-when-the-p.md | 12 ++++++++++++
 ...rb-refuses-an-unrecognised-source-value-with-a.md | 12 ++++++++++++
 ...st-guards-in-the-scanner-s-adjacency-tests-ass.md | 12 ++++++++++++
 7 files changed, 84 insertions(+)
 create mode 100644 .abcd/work/issues/open/iss-2608290808193471-nothing-ties-a-merged-implementation-to-closing-its-spec-so.md
 create mode 100644 .abcd/work/issues/open/iss-2608290810032799-the-attribution-gate-validates-the-assisted-by-trailer-s-sha.md
 create mode 100644 .abcd/work/issues/open/iss-2608290810033503-the-forge-reported-a-pull-request-as-conflicting-when-it-mer.md
 create mode 100644 .abcd/work/issues/open/iss-2608290810034854-two-adversarial-reviews-over-the-assembled-multi-branch-diff.md
 create mode 100644 .abcd/work/issues/open/iss-2608290810036869-git-push-can-report-success-while-pushing-nothing-when-the-p.md
 create mode 100644 .abcd/work/issues/open/iss-2608290810037524-the-capture-verb-refuses-an-unrecognised-source-value-with-a.md
 create mode 100644 .abcd/work/issues/open/iss-2608290810037763-adversarial-cost-guards-in-the-scanner-s-adjacency-tests-ass.md

diff --git a/.abcd/work/issues/open/iss-2608290808193471-nothing-ties-a-merged-implementation-to-closing-its-spec-so.md b/.abcd/work/issues/open/iss-2608290808193471-nothing-ties-a-merged-implementation-to-closing-its-spec-so.md
new file mode 100644
index 00000000..4a53d4c4
--- /dev/null
+++ b/.abcd/work/issues/open/iss-2608290808193471-nothing-ties-a-merged-implementation-to-closing-its-spec-so.md
@@ -0,0 +1,12 @@
+---
+schema_version: 1
+id: "iss-2608290808193471"
+slug: "nothing-ties-a-merged-implementation-to-closing-its-spec-so"
+severity: "major"
+category: "process"
+source: "impl-review"
+found_during: "intent-implementation-run"
+found_at: ".abcd/development/specs/open"
+---
+
+Nothing ties a merged implementation to closing its spec, so twelve specs stayed open and twelve intents stayed planned after the code that realises them landed on main: abcd spec close is the verb that advances the intent planned to shipped, closes the spec open to closed, and emits the fidelity-audit receipt, but no gate, lint rule or CI step notices that a spec is still open while its acceptance criteria are demonstrably delivered. The consequence is not cosmetic: the changelog composer reads the shipped-intent and resolved-issue folders, so a release cut derived while the intents sit in planned announces the resolved issues and omits every intent the release actually delivers. Found after the itd-150..162 implementation merged with all fourteen issues resolved but all twelve specs left open. Wants a detector for the shape 'spec open, linked intent planned, and the spec's own scope files changed since the spec was written', which is the same reference-graph the dangling-supersedes ratchet already walks.
\ No newline at end of file
diff --git a/.abcd/work/issues/open/iss-2608290810032799-the-attribution-gate-validates-the-assisted-by-trailer-s-sha.md b/.abcd/work/issues/open/iss-2608290810032799-the-attribution-gate-validates-the-assisted-by-trailer-s-sha.md
new file mode 100644
index 00000000..d080bc46
--- /dev/null
+++ b/.abcd/work/issues/open/iss-2608290810032799-the-attribution-gate-validates-the-assisted-by-trailer-s-sha.md
@@ -0,0 +1,12 @@
+---
+schema_version: 1
+id: "iss-2608290810032799"
+slug: "the-attribution-gate-validates-the-assisted-by-trailer-s-sha"
+severity: "minor"
+category: "process"
+source: "impl-review"
+found_during: "intent-implementation-run"
+found_at: "scripts/check-attribution.sh"
+---
+
+The attribution gate validates the Assisted-by trailer's SHAPE but cannot tell whether the model id names the model that actually did the work, so a wrong but well-formed id passes green. In the itd-150..162 run four implementation agents were briefed with an incorrect model id: two used it as instructed and their commits passed the gate, two recognised it as a false disclosure and stamped their real id instead. The convention exists precisely to prevent a false disclosure, and the gate is blind to the only failure that matters. A full mechanical fix may be impossible because the runner cannot attest which model produced a commit, but two partial rungs exist: refuse a vendor and model pair absent from a maintained known-models list, so a typo or a stale id is caught; and have the dispatching harness supply its own model id to the agent, so a hand-written briefing cannot introduce a wrong one. Distinct from iss-211 (making the attribution preference portable) and iss-220 (composing the trailer at creation time): this is about the truthfulness of a trailer that is present and well-formed.
\ No newline at end of file
diff --git a/.abcd/work/issues/open/iss-2608290810033503-the-forge-reported-a-pull-request-as-conflicting-when-it-mer.md b/.abcd/work/issues/open/iss-2608290810033503-the-forge-reported-a-pull-request-as-conflicting-when-it-mer.md
new file mode 100644
index 00000000..d965e3f1
--- /dev/null
+++ b/.abcd/work/issues/open/iss-2608290810033503-the-forge-reported-a-pull-request-as-conflicting-when-it-mer.md
@@ -0,0 +1,12 @@
+---
+schema_version: 1
+id: "iss-2608290810033503"
+slug: "the-forge-reported-a-pull-request-as-conflicting-when-it-mer"
+severity: "nitpick"
+category: "process"
+source: "agent-observation"
+found_during: "intent-implementation-run"
+found_at: ".github"
+---
+
+The forge reported a pull request as conflicting when it merged cleanly against both the current main and the tip of the pull request queued ahead of it, and dropped its armed auto-merge as a result. Verified by merging locally against both refs with zero conflicting paths, twice, several minutes apart. The state cleared only after pushing a merge of main into the branch, which forced the forge to recompute, after which it reported mergeable and auto-merge could be re-armed. Cost roughly twenty minutes of diagnosis on the assumption that a real conflict existed. Recording it so a future run recognises the shape: a conflicting verdict that no local merge reproduces is a stale computation, and updating the branch is the cheap remedy rather than hunting for a conflict that is not there.
\ No newline at end of file
diff --git a/.abcd/work/issues/open/iss-2608290810034854-two-adversarial-reviews-over-the-assembled-multi-branch-diff.md b/.abcd/work/issues/open/iss-2608290810034854-two-adversarial-reviews-over-the-assembled-multi-branch-diff.md
new file mode 100644
index 00000000..0290c490
--- /dev/null
+++ b/.abcd/work/issues/open/iss-2608290810034854-two-adversarial-reviews-over-the-assembled-multi-branch-diff.md
@@ -0,0 +1,12 @@
+---
+schema_version: 1
+id: "iss-2608290810034854"
+slug: "two-adversarial-reviews-over-the-assembled-multi-branch-diff"
+severity: "minor"
+category: "process"
+source: "impl-review"
+found_during: "intent-implementation-run"
+found_at: ".abcd/work/reviews"
+---
+
+Two adversarial reviews over the assembled multi-branch diff each returned a blocker that the same class of review had already passed over on the individual branch, and both blockers were branch-local rather than merge-only: a bare git-directory existence check that let a worktree read and enforce an unrelated repository's private name store, and a test fixture built from a live session identifier and carried past the repository's own new detector by three separate escapes in one commit. The lesson is not that more review is better. A reviewer reading one branch in isolation judges the diff against itself, while a reviewer reading the assembled tree judges it against the repository's stated invariants and notices a change that contradicts one. Worth recording in the reviews charter as the reason an integration-level pass is not redundant with the per-branch pass, and worth giving the per-branch reviewer the invariants explicitly rather than hoping it infers them.
\ No newline at end of file
diff --git a/.abcd/work/issues/open/iss-2608290810036869-git-push-can-report-success-while-pushing-nothing-when-the-p.md b/.abcd/work/issues/open/iss-2608290810036869-git-push-can-report-success-while-pushing-nothing-when-the-p.md
new file mode 100644
index 00000000..49ad74c9
--- /dev/null
+++ b/.abcd/work/issues/open/iss-2608290810036869-git-push-can-report-success-while-pushing-nothing-when-the-p.md
@@ -0,0 +1,12 @@
+---
+schema_version: 1
+id: "iss-2608290810036869"
+slug: "git-push-can-report-success-while-pushing-nothing-when-the-p"
+severity: "major"
+category: "bug"
+source: "agent-observation"
+found_during: "intent-implementation-run"
+found_at: ".githooks/pre-push"
+---
+
+git push can report success while pushing nothing, when the pre-push preflight outlasts the SSH idle timeout. The hook runs the full preflight, which takes minutes, and the connection is opened before the hook runs, so the server closes it mid-hook: the push dies with a connection-closed message, the remote ref is unchanged, and the preflight's own passing output scrolls past the failure so the whole thing reads as a clean run. Hit twice in one session. The second time the push was also piped to another command, which returns that command's exit status, so a failed push reported zero. Remedies that worked: set SSH keepalive options for the push, never pipe the push, and confirm with a remote ref listing that the tip actually moved. Worth considering whether the hook should run before the connection is opened, or whether a push wrapper should verify the remote tip afterwards; the silent half is the defect, not the slowness.
\ No newline at end of file
diff --git a/.abcd/work/issues/open/iss-2608290810037524-the-capture-verb-refuses-an-unrecognised-source-value-with-a.md b/.abcd/work/issues/open/iss-2608290810037524-the-capture-verb-refuses-an-unrecognised-source-value-with-a.md
new file mode 100644
index 00000000..534bb19b
--- /dev/null
+++ b/.abcd/work/issues/open/iss-2608290810037524-the-capture-verb-refuses-an-unrecognised-source-value-with-a.md
@@ -0,0 +1,12 @@
+---
+schema_version: 1
+id: "iss-2608290810037524"
+slug: "the-capture-verb-refuses-an-unrecognised-source-value-with-a"
+severity: "nitpick"
+category: "ux"
+source: "agent-observation"
+found_during: "intent-implementation-run"
+found_at: "internal/surface/cli"
+---
+
+The capture verb refuses an unrecognised source value with a message that names neither the offending flag nor the accepted set, and blames the wrong layer: an invalid source produces a malformed-frontmatter error quoting the value, when the value came from a command-line flag and never reached any frontmatter the caller wrote. The accepted values are discoverable only by grepping existing records. The flag's help text lists no enumeration either. The same shape likely applies to category and to any other closed-set flag on this path. A closed set should be named in the refusal and in the help text.
\ No newline at end of file
diff --git a/.abcd/work/issues/open/iss-2608290810037763-adversarial-cost-guards-in-the-scanner-s-adjacency-tests-ass.md b/.abcd/work/issues/open/iss-2608290810037763-adversarial-cost-guards-in-the-scanner-s-adjacency-tests-ass.md
new file mode 100644
index 00000000..fc485726
--- /dev/null
+++ b/.abcd/work/issues/open/iss-2608290810037763-adversarial-cost-guards-in-the-scanner-s-adjacency-tests-ass.md
@@ -0,0 +1,12 @@
+---
+schema_version: 1
+id: "iss-2608290810037763"
+slug: "adversarial-cost-guards-in-the-scanner-s-adjacency-tests-ass"
+severity: "minor"
+category: "tech-debt"
+source: "impl-review"
+found_during: "intent-implementation-run"
+found_at: "internal/adapter/scanner/adjacency_test.go"
+---
+
+Adversarial cost guards in the scanner's adjacency tests assert wall-clock seconds, which is a property of the machine rather than of the code, so they pass locally and fail on slower CI hardware under the race detector. One failed on both CI runners at 22.5 seconds against a 15 second bar while passing locally at 11.0 seconds on the same commit; the branch that introduced the probe and the merged tree measured identically, so it was not a regression. It was fixed for the costliest shape by shrinking that case's input, which is the lever the test file's own helper documents, but three sibling bars carry the same fragility and the same thin headroom. The machine-independent cost-CLASS guard beside them is the better model: it doubles the input and asserts the growth ratio, which no hardware difference can flip. Worth converting the remaining wall-clock ceilings to ratio assertions, or at least measuring a per-machine baseline and asserting a multiple of it.
\ No newline at end of file