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:
@@ -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).
|
||||
|
||||
Reference in New Issue
Block a user