v1.2.1 — declarative asks no longer mint unclosable blocking deliverables
Live FP from a real hindsight session: "I do have image_attributions.md on
downloads folder" — the user stating a file EXISTS — minted a HARD (blocking)
deliverable. The file lived in ~/Downloads, OUTSIDE the repo, so it could never
ground in a git diff, so the task could never close: it nagged every turn and
under block mode escalates to a BLOCK on work never requested and unable to
exist. Same phantom-deliverable / block-mode wedge v1.0.5 closed for pasted tool
listings, arriving through a different door.
Root cause: isTrackableRequest() has a !framed -> return true fast path, and a
declarative is neither a dismissal (NON_REQUEST_RE) nor a question (QUESTION_RE),
so it fell straight through to "plain imperative -> track".
Fix: DECLARATIVE_RE + a declarative gate in classifyDeliverables that DEMOTES
to soft (surfaced once, auto-expires, never blocks) — never drops, per the
demote-never-drop invariant.
The first cut of that fix was WRONG in the dangerous direction, and both FN
families are now closed:
- Cross-clause anaphora: splitClauses splits on
., so "I have a notes.md.
Add it to the repo." put the token in the declarative clause and the verb in
the next one — silently demoting a GENUINE request (the completeness backstop
going inert, the cardinal sin). Fixed with an ask-wide anaphoric-request scan. - Problem reports (Fable, on review — a family missed entirely): "we have a bug:
cache.js returns stale data", "there is no error handling in parser.js",
"a race condition exists in cache.js" are declarative in FORM but a commission
in FUNCTION. Fixed with a PROBLEM_RE negative gate.
Both gates can only RESTORE pre-fix hardness, never mint new hardness — zero new
FP exposure; worst-case over-match degrades to the old behavior.
Self-check 613 -> 627; red-team 14/14; corpus unchanged (17/23 at-capture).
Co-Authored-By: Claude Opus 4.8 (1M context) noreply@anthropic.com
Full symptom → root-cause → fix → regression-test in FIXES.md (v1.2.1).