diff --git a/boss/SKILL.md b/boss/SKILL.md index b628473..014a5d4 100644 --- a/boss/SKILL.md +++ b/boss/SKILL.md @@ -293,6 +293,25 @@ things at once: rollback hard-drops the commits (below), the issue thread is what remains of the dead-ended line. +These decision-log comments are issue entries — they obey +`../issue/SKILL.md` rule 4, the reachability test: a later run or user +lands on the **comment**, not the chat that produced it, so each must be +self-contained and reachable from the tracker. + +- **Quote a user decision's provenance inline** — the words and the date + ("`ja, mach B`" — 2026-06-28) — never a pointer at the chat ("settled + in the discussion", "decided in-context"). The chat is unreachable from + the tracker; a pointer to it strands every later reader. +- **Reproduce each fork's options and chosen rationale inline.** A bare + label ("Approach B") indexes a set the reader cannot see — spell the + options out, or name the choice on its own terms. +- **Tie a later comment to an earlier one by that comment's full URL, or + restate the point** — never "above" / "logged above" / "the prior + comment", which a reader on a direct comment-anchor link cannot resolve. + +The provenance block in § Skill-system feedback shows the form: +provenance written into the issue body, never pointed at. + A run that reaches a fork decision without a reference issue to record it on is a bug: create the seeding issue first (Step 1.5 mechanic), then decide. @@ -642,6 +661,7 @@ the user wants it — there is no autonomous filing to govern. | "This spec is clearly good — I'll sign it on my judgement" | Your judgement is not the signature; the Step-5 `grounding-check` `PASS` is. Run grounding and sign on the PASS. A no-override grounding `BLOCK` routes to the human — never signed over on confidence. (The old unanimous `spec-skeptic` panel is retired; do not re-introduce it as a gate.) | | "There's an open fork — I'll bounce to `brainstorm` to be safe" | If you can *derive* an answer (sources, code, consistency, risk), decide it boldly and record it in the reference issue. Only a *pure-preference* fork bounces. Bouncing a derivable fork is exactly the timidity the bold stance retired; unsure if your leaning is bias, pull one ad-hoc `spec-skeptic` lens, then decide. | | "I derived a fork but didn't bother logging it on the issue" | The reference-issue comment is mandatory. It is the user's only window into a call made without them — and, because a rollback hard-drops the commits, the only surviving trace of the attempt. No reference issue, no fork decision: create the seeding issue first. | +| "The user was in the discussion, so 'as decided in-context / above' is enough on the issue" | The decision log is read later by a run or user who was NOT in that discussion and may land on the comment alone. Quote the user's words + date inline, reproduce the fork's options and rationale, and link any sibling comment by its full URL — never "above" / "in-context". The chat is not reachable from the tracker (`../issue/SKILL.md` rule 4). | | "Auto-sign let me continue, so I don't need to notify — it's just progress" | The auto-sign notify is mandatory and carries a decision (the user's veto over a signature made without them). It is the one sanctioned mid-flow notify precisely because it is not progress — it is the audit trail for a delegated gate. | | "I hit a gap in the skill system itself — I should notify the user about it" | No. File it on the plugin's own tracker with an autonomous-provenance body block and continue (§ Skill-system feedback). It needs no mid-run decision, so notifying would be the attention-burning progress ping the notify discipline forbids; the filed issue is the durable record. | | "Something was awkward this run — file it against the plugin tracker" | Only a *durable plugin* deficiency qualifies: the fault is the plugin's (not the project's) and it would recur on the next run. One-off project friction is not plugin feedback; when unsure whose fault it is, it is the project's. File on the plugin tracker (never the project's), dedupe against its issues first, and mark provenance in the body — never with a new label. | @@ -663,6 +683,7 @@ the user wants it — there is no autonomous filing to govern. - About to re-introduce the retired `spec-skeptic` panel as a sign gate (a unanimous five-juror pass as a precondition) — it is now only the optional Step-1.5 bias-breaker; or to run any auto-sign path outside a `/boss` session, or to skip the mandatory auto-sign notify after signing. - About to *decide* a fork that hangs on pure user preference (no derivable better) instead of bouncing it — or its inverse, bouncing a *derivable* fork to `brainstorm` out of timidity. - About to make a fork decision without recording it on the run's reference issue, or to run autonomously with no reference issue at all. +- About to record a fork decision that points at the chat ("settled in the discussion", "decided in-context") or at an earlier comment by "above" / "logged above" — the decision log is tracker-reachable per `../issue/SKILL.md` rule 4: quote the provenance and reproduce the options inline, and link a sibling comment by its full URL. - About to `git reset` below the session anchor, or to `reset` a commit that has been pushed — the rollback sandbox is the orchestrator's *own unpushed* commits above the anchor only; user-ratified and pushed history is forward-only (`git revert`). - About to notify the user about a skill-system deficiency instead of filing it on the plugin's own tracker and continuing (§ Skill-system feedback) — it is captured, never a notify event. - About to file plugin feedback for one-off project friction rather than a durable plugin deficiency, against the *project's* tracker instead of the plugin's, without deduping against the plugin's issues, or marked with a new provenance label instead of the body block.