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.

specify/SKILL.md

@@ -162,12 +162,49 @@ Gitea writes are pre-authorized (per `~/.claude/CLAUDE.md`); post the
 comment without a confirmation prompt.
 
 **Issue-less in-context entry.** If the cycle has *no* tracker issue —
-the design was settled in pure chat — there is no independent artefact to
-comment on, and a provenance note *inside the spec* would be
-self-referential (the spec asserting its own sources settle it). Do not
-manufacture a weak spec-note path: under auto-sign this case falls back
-to the human sign-off (the safe default), because no auditable source
-exists for the juror to check against.
+the design was settled in pure chat — there is no existing artefact to
+comment on, so *create one*: open a new tracker issue that records the
+resolved fork(s) with provenance, under the same discipline as the
+reconciliation comment above. The body takes this shape:
+
+```
+## Design record (specify, issue-less in-context entry)
+This issue seeds <one-line identity of the work>. The design was settled
+in an in-context discussion with no prior tracker issue; this records it.
+Load-bearing fork(s) resolved:
+- **Fork: <name>** → <decision>.
+  Provenance: <verbatim user statement, or explicit attribution + date>.
+```
+
+The body names the *work*, not the spec file — the spec does not exist
+yet at Step 1.5 (its number is assigned only in Step 3). This new issue
+is the cycle's seeding issue from here on: the `scope-fork` juror reads
+it via the project's issue show command — its index handed to the juror
+in the Step-6 carrier (the `seeding_issue` field, below) — exactly as it
+reads any seeding issue. A *new issue* is the right artefact where a spec-note
+is the wrong one — a provenance note *inside the spec* is
+self-referential (the spec asserting its own sources settle it) and
+stays banned, but a separate issue is independent (author + timestamp,
+in the forward queue, juror-readable without opening the spec), as
+auditable as a reconciliation comment. Creating it is what makes
+auto-sign *reachable* here, instead of the old unconditional fall-back
+to the human sign-off.
+
+The provenance gate is unchanged and load-bearing: the new issue records
+*user* decisions, never fresh orchestrator ones. No real user statement
+for a fork means *you* picked it — a Step-1.5 bounce, not an issue to
+manufacture. You *write* the issue; the adversarial `scope-fork` juror
+*checks* the provenance, and a provenance-less body buys no pass.
+
+Create it via the project's issue-create command (the `issue` skill's
+mechanics — `tea issues create` for Gitea), title and label per the
+project's vocabulary as in the Step-5 failure-mode procedure. Gitea
+writes are pre-authorized, so create it without a confirmation prompt.
+**Capture the new issue's index** the moment it is created and carry it
+into the Step-6 panel as the `seeding_issue` field — it is the only way
+the `scope-fork` juror knows which issue to read. An issue created but
+never handed to the panel is invisible to the juror, which leaves the
+fork looking picked and the creation pointless.
 
 ### Step 2 — Apply the project's feature-acceptance criterion
 
@@ -366,7 +403,11 @@ CLAUDE.md project facts):
      read-only `spec-skeptic` agent **five times in parallel**, once
      per lens — `criterion`, `grounding`, `scope-fork`, `ambiguity`,
      `plan-readiness`. Carrier per dispatch: `spec_path` (absolute),
-     `iteration_scope`, and the single `lens`. Each juror tries to
+     `iteration_scope`, the single `lens`, and `seeding_issue` — the
+     index of the cycle's seeding issue (the lagging issue reconciled in
+     Step 1.5, the issue Step 1.5 created for an otherwise issue-less
+     cycle, or `none` if the cycle has neither) for the `scope-fork`
+     juror to read; the other four lenses ignore it. Each juror tries to
      *refute* the spec along its lens and returns `SOUND` / `BLOCK` /
      `INFRA_ERROR`. Auto-sign requires a **unanimous `SOUND`** — that
      never changes. What the partition below adds is a bounded path to
@@ -455,7 +496,7 @@ discipline `tdd` applies when behaviour is not test-specifiable.
 | user / issue (design settled) → `specify` | the sources: issue body, in-context design discussion, design docs |
 | `brainstorm` → `specify` | ratified design narrative (approaches chosen, constraints, sections approved) — in-context; brainstorm writes no spec file |
 | `specify` → `grounding-check` (Step 5) | `spec_path` (absolute) + `iteration_scope` |
-| `specify` → `spec-skeptic` panel (Step 6, `/boss` + `spec_auto_sign` only) | `spec_path` (absolute) + `iteration_scope` + one `lens` per dispatch, five in parallel |
+| `specify` → `spec-skeptic` panel (Step 6, `/boss` + `spec_auto_sign` only) | `spec_path` (absolute) + `iteration_scope` + one `lens` per dispatch (five in parallel) + `seeding_issue` (index for the `scope-fork` juror to read, or `none`) |
 | `specify` → `planner` (Step 7, on PASS or overridden BLOCK) | path to spec + iteration scope |
 | `specify` → `brainstorm` (precondition bounce) | the unresolved design question as a cycle request; no spec written |
 | `specify` → issue backlog (Step 5, no-override BLOCK) | new issue naming the unratified dependency; spec file deleted from the working tree |