feat(specify): create a seeding issue for issue-less in-context auto-sign

Step 1.5's issue-less in-context case used to fall back unconditionally
to the human sign-off: with no tracker issue, the `scope-fork` juror had
no auditable source for an in-context fork resolution and (correctly)
blocked, so auto-sign was structurally unreachable on that path.

Close it the same way the lagging-issue case is closed — give the juror
an auditable artefact instead of weakening the gate. When the cycle has
no seeding issue, the orchestrator now creates one recording each
resolved fork WITH provenance (a record of the user's decision, never a
fresh orchestrator one). A new tracker issue is independent and
auditable — unlike the self-referential spec-note the old text rejected
— so it, not the orchestrator's confidence, is what the juror checks.
The provenance gate is unchanged: no real user statement is a Step-1.5
bounce, not a manufactured issue; the orchestrator writes, the juror
enforces.

Also thread a `seeding_issue` field through the scope-fork carrier so
the juror can actually find the issue to read (the lagging issue, the
newly created one, or `none`). Without it the juror had no issue index
and the record was invisible — a latent gap the lagging-issue path
shared.

- specify Step 1.5: issue-less branch creates a provenance-bearing
  seeding issue; body names the work (no forward ref to the unwritten
  spec); explicit create command; capture-the-index instruction.
- specify Step 6 + handoff table: seeding_issue carrier field.
- spec-skeptic: juror reads seeding_issue from the carrier; accepts
  provenance in a created issue's body, not only in a comment.
- consistency: README, pipeline.md, design.md.
This commit is contained in:
2026-06-16 12:50:11 +02:00
parent 161ccc837b
commit 8e72aa5c36
6 changed files with 100 additions and 45 deletions
+24 -17
View File
@@ -75,23 +75,29 @@ In addition, every dispatch:
project's examples / fixtures directory —
you grep these to confirm or refute ratification.
- For the `scope-fork` lens additionally: the sources the spec was
built from. The seeding issue is reachable via the project's issue
show command (its CLAUDE.md project facts) — it MUST render the issue
WITH its comment thread (issue index appended last) — invoke it so
you read the issue **with its comment thread**, not the body alone.
built from. Your carrier names the `seeding_issue` index — append it
to the project's issue show command (its CLAUDE.md project facts,
which MUST render the issue WITH its comment thread) and invoke it so
you read the issue **with its comment thread**, not the body alone. If
`seeding_issue` is `none`, the cycle has no seeding issue and you have
only the spec to judge against — a load-bearing fork the spec leaves
unsourced is then a refutation.
You judge "resolved vs picked" against what the sources actually say,
not against what reads plausibly. A fork the issue *body* still lists
open may have been resolved in an in-context discussion the dispatch
cannot replay to you; the legitimate channel for that resolution is a
**reconciliation comment** on the issue (`specify` Step 1.5). A
reconciliation comment counts as the sources resolving the fork **only
if it carries provenance** — a record of the user's decision (a
verbatim statement, or explicit attribution + date). A bare
`decision: X` with no provenance is an orchestrator self-assertion
dressed as settled, not a source: it does **not** resolve the fork, and
a load-bearing decision whose only support is such a comment is a
refutation. If the project declares no issue show command, you have
only the body — a fork the body lists open is unresolved to you.
**provenance-bearing reconciliation record** written by `specify` Step
1.5 — either a reconciliation *comment* on a seeding issue that lagged
the discussion, or, for a cycle that had *no* seeding issue, the
*body* of the issue `specify` created to record it. Either counts as
the sources resolving the fork **only if it carries provenance** — a
record of the user's decision (a verbatim statement, or explicit
attribution + date). A bare `decision: X` with no provenance is an
orchestrator self-assertion dressed as settled, not a source: it does
**not** resolve the fork, and a load-bearing decision whose only
support is such a record is a refutation. If the project declares no
issue show command, you have only what you can read — a fork no
provenance-bearing record resolves is unresolved to you.
You do NOT read files under `docs/plans` (the plan does not yet
exist). You do NOT read other specs unless the spec under review
@@ -104,6 +110,7 @@ references one — and then only the referenced section.
| `spec_path` | absolute path to the spec under review |
| `iteration_scope` | which sections are in scope for the imminent first iteration (verbatim from specify) |
| `lens` | exactly one of: `criterion`, `grounding`, `scope-fork`, `ambiguity`, `plan-readiness` |
| `seeding_issue` | index of the cycle's seeding issue for the `scope-fork` juror to read via the project's issue show command — the lagging issue reconciled in `specify` Step 1.5, the issue Step 1.5 created for an otherwise issue-less cycle, or `none`. The other four lenses ignore it; if absent, treat as `none`. |
The controller is the `specify` skill's Step 6, running inside a
`/boss` session. You receive the carrier inline in the dispatch
@@ -134,10 +141,10 @@ YOU DO NOT RUN THE FULL TEST SUITE. (TEST LIST, TYPE-CHECK ARE OK.)
pin; your own recall does not pin). For `scope-fork`, this means
listing the load-bearing decisions and checking each against the
sources read via the project's issue show command (issue **with
comments**); a fork the
issue body lists open is resolved only by a reconciliation comment
that carries provenance (see the standing reading list) — a
provenance-less one does not count. For the others, read for the
comments**); a fork the issue body lists open is resolved only by a
provenance-bearing reconciliation record — a comment, or the body of
an issue `specify` created for an otherwise issue-less cycle (see the
standing reading list) — a provenance-less one does not count. For the
specific failure.
4. If you find a genuine defect along your lens → `BLOCK`, and state
it concretely (section ref, the offending text, why it is a defect).