fix: ask the harness question before naming a fault, and name the CI artifact

.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "forge-workflow",
   "displayName": "Forge",
-  "version": "1.5.2",
+  "version": "1.6.0",
   "description": "Gated spec-to-ship lifecycle for Claude Code. One command determines where a project stands and does the next thing: requirements discovery to 95 percent confidence, toolchain and repository bootstrap, then test-driven implementation with enforced resumability, documentation drift gates, and tagged releases.",
   "author": {
     "name": "Dailen Gunter",

CHANGELOG.md

@@ -7,6 +7,66 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+## [1.6.0] - 2026-09-05
+
+### Fixed
+
+- `/forge` Step 0 asks the harness question before it names a fault. Its four
+  mechanical checks all pass when the real cause is a harness that never reads
+  `hooks/hooks.json`, and it then asked for "the likely cause" with a worked
+  example naming Node, so a cause got invented. On one project two different
+  invented causes reached `CONTINUE.md` and were believed for a day; the actual
+  cause was `harness/omp/forge-bridge.ts` never having been copied to
+  `~/.omp/agent/extensions/`, which the plugin's own `harness/README.md`
+  documents. Step 0 now separates a broken machine from an intact one nobody is
+  driving, resolves the harness from a marker table in `harness/README.md`, and
+  reports the missing adapter as one line naming the file to copy. When it
+  cannot identify the harness it says so and reports the consequence anyway;
+  naming a cause the diagnostics did not establish is now explicitly refused.
+  `CLAUDECODE=1` does not establish Claude Code: omp sets it deliberately for
+  tool compatibility alongside its own `OMPCODE=1`. Issue #8
+- `next_action` in `.forge/index.json` no longer names a deliberately parked
+  task. It took the lowest-numbered open task, because `status` was the only
+  field it had. The cause was one level up: the record set had no way to say why
+  an open task is waiting, so the three backlog dispositions `forge-standards`
+  defines all collapsed to `open` and the detection ladder's "leave Deferred
+  items alone" could not be evaluated at all. Issue #9
+- The release CI gate names its artifact. Every other release gate implies an act
+  of measurement; CI runs elsewhere, so a recorded "CI green" line was the
+  cheapest place to look, and a release was cut on top of two pushes with a red
+  job. Issue #10
+
+### Added
+
+- `disposition` on task records: `ready`, `needs-decision`, or `deferred`, with
+  an absent field reading as ready so a project that predates it still has a next
+  action. The index skips anything not ready, `docs/views/open-work.md` shows the
+  column, the linter rejects an unknown value or one on a non-task record, and
+  the migration keeps the TODO section a bullet sat under so `## Blocked` survives
+  as `needs-decision`. A `/forge` Step 2a backfill row offers to fill in the open
+  tasks once, since absent-means-ready is otherwise a silent wrong default forever
+- `harness/README.md` gains a harness marker table (harness, environment marker,
+  adapter, extension path), the single owner of that knowledge, plus a note that
+  forge's enforcement degrades silently: a project can carry a sentence asserting
+  a `PreToolUse` hook denies writes under `docs/views/` that is simply false under
+  a harness which never loads it. Adding a harness is one row and one directory
+- A rule for recorded gate results, in `/forge` Step 2 reconcile: a result whose
+  subject is a commit (CI, suite, coverage) is evidence only for the commit it was
+  measured against, and is absent rather than stale once commits land on top of
+  it. A result whose subject is a surface, such as the polish pass, does not
+  expire this way
+
+### Changed
+
+- The `docs/views/**` guarantee is stated as the portable one. The pre-push
+  `06_views` check is an ordinary program the project runs and holds under any
+  harness; the `PreToolUse` hook is the fast local deny wherever the harness loads
+  it. `forge-code` points at the mechanism `forge-standards` owns rather than
+  restating it
+- `.forge/index.json` `open.tasks` carries `{ id, disposition }` rather than bare
+  IDs, matching how `open.uxd` already carries its severity. The file is generated
+  and gitignored, so `forge-index.js build` reproduces it
+
 ## [1.5.2] - 2026-09-01
 
 ### Changed

docs/index.html

@@ -276,7 +276,7 @@ <h1><span class="thin">A guide for people who are not developers</span>Forge</h1
       <div><span>Audience</span><b>Technical, not a developer</b></div>
       <div><span>Runs in</span><b>Claude Code</b></div>
       <div><span>Reading time</span><b>About 20 minutes</b></div>
-      <div><span>Edition</span><b>v1.5.2 &nbsp;/&nbsp; for Claude 5</b></div>
+      <div><span>Edition</span><b>v1.6.0 &nbsp;/&nbsp; for Claude 5</b></div>
     </div>
   </div>
 </header>
@@ -311,41 +311,39 @@ <h1><span class="thin">A guide for people who are not developers</span>Forge</h1
 <main>
 
 <div class="note go">
-  <h4>New in v1.5.0 &nbsp;/&nbsp; one note per fact, and the summaries write themselves</h4>
+  <h4>New in v1.6.0 &nbsp;/&nbsp; "I cannot tell you why" beats a confident wrong answer</h4>
   <p>
-    v1.4.0 put a size limit on the "where we are now" file. This release fixes the reason it
-    grew. Until now, finishing one piece of work meant writing the same news into four or five
-    different files by hand: the to-do list, the decisions file, the test map, the design
-    notes. Nothing said which file owned which fact, so over time they drifted apart and
-    disagreed, and the one you happened to read first was the one you believed. On one real
-    project a single fixed bug had been written up seventeen times across three files.
+    Three fixes, all the same shape: a step that asked for a conclusion without saying what
+    evidence would support it, so one got invented.
   </p>
   <p>
-    Forge can now keep each note in its own small file, named after the thing it is about, and
-    <em>generate</em> the summaries from them: the test map, the list of open work, the archive
-    of finished work. You never edit a generated summary, and Forge will not let you: it stops
-    the edit and points you at the note to change instead. Change the note, and every summary
-    that mentions it updates itself.
+    Forge runs some of its own machinery through Claude Code hooks, and one of them puts your
+    project state in front of it the moment a session starts. Some other tools that can run
+    Forge do not support that kind of hook at all. When the state never arrived, Forge used to
+    run four checks that all passed and then name a cause anyway. On one real project that
+    wrong cause was written into the project notes and believed for a day. It now separates
+    the two cases: something broken, which it names, or an intact setup that this tool is not
+    reading, in which case it says exactly that, points at the adapter that closes the gap, and
+    tells you what you lose until it is installed. If it cannot tell, it says it cannot tell.
   </p>
   <p>
-    That also settles which answer is current. When a decision replaces an earlier one, the
-    earlier one is marked as replaced and drops out of every summary, while staying on file if
-    you ever want to look it up. No more reading a stale answer at the top of a long file and
-    a corrected one further down.
+    The "what should I do next" line used to pick whichever open job had the lowest number,
+    which on a long-running project meant it kept naming something deliberately parked. Jobs
+    now record <em>why</em> they are waiting: ready to start, waiting on a decision, or parked
+    at your request. Forge skips the last two, and says so plainly when everything left is
+    parked, rather than pointing you at work nobody meant to do.
   </p>
   <p>
-    What you should notice: finishing a piece of work takes fewer steps and produces fewer
-    contradictions, the summaries are always current because nobody maintains them, and asking
-    "what is left to do" reads a short generated list instead of a very long history. Before
-    anything is pushed, Forge checks that every note still points at something real.
+    And before a release, "the automated checks passed" is no longer something Forge can take
+    from its own notes. It now looks up the result for the exact version of the code being
+    released and quotes it. A release went out over a failing check because that line had been
+    written a day earlier and nobody re-read it. More generally, a recorded check result older
+    than the code it covers now counts as missing rather than as proof.
   </p>
   <p>
-    <strong>Already have a project on an older Forge?</strong> Nothing breaks and nothing is
-    treated as damaged. Your project keeps its current files until you say otherwise. Forge
-    offers the change once, explains what it costs, and takes "not now" or "no" for an answer.
-    Moving an existing project over is done as its own separate piece of work, never in the
-    middle of something else, and it never deletes your old files: it moves them aside.
-    See <a href="#away">walking away and coming back</a>.
+    <strong>Already have a project on an older Forge?</strong> Nothing breaks. Existing jobs
+    with no recorded reason are treated as ready to start, exactly as before, and Forge offers
+    to fill them in with you once. See <a href="#away">walking away and coming back</a>.
 </div>
 
 <!-- 01 -->
@@ -544,7 +542,7 @@ <h2>Which edition to install</h2>
       <tbody>
         <tr>
           <td><strong>A current Claude model</strong><br>Claude 5 era. This is almost certainly you.</td>
-          <td><code>forge-workflow</code><br>v1.5.2</td>
+          <td><code>forge-workflow</code><br>v1.6.0</td>
           <td><code>/forge</code></td>
         </tr>
         <tr>
@@ -1289,7 +1287,7 @@ <h3 style="margin-top:2.6rem">If you only remember four things</h3>
 </div>
 
 <footer>
-  <div class="sheet">FORGE &nbsp;/&nbsp; GUIDE FOR NON-DEVELOPERS &nbsp;/&nbsp; REVISED FOR v1.5.2</div>
+  <div class="sheet">FORGE &nbsp;/&nbsp; GUIDE FOR NON-DEVELOPERS &nbsp;/&nbsp; REVISED FOR v1.6.0</div>
 </footer>
 
 </div>

harness/README.md

@@ -27,6 +27,34 @@ forge's enforcement keeps moving into `templates/` programs, and why the
 `docs/views/` guard being a `PreToolUse` hook rather than a `PostToolUse` one
 also happens to be the portable choice.
 
+**Degradation is silent, and a project may assert otherwise in its own docs.** forge is
+written for Claude Code, so a project can carry a sentence like "nothing under
+`docs/views/` may be hand-edited, a PreToolUse hook denies it" that is simply false
+under a harness which never loads that hook, with nothing anywhere to say so. The rule
+that keeps a guarantee honest is to place it in a program the project runs rather than in
+a hook the harness may not provide: `templates/lefthook.yml` runs
+`forge-views.js check` as `06_views` under `pre-push`, which holds everywhere, and
+the PreToolUse hook is the fast local deny where it is available. Word it that way round.
+
+## Telling which harness you are in
+
+A skill cannot ask the harness what it is, but every harness so far marks its own shell
+environment. `/forge` Step 0 reads this table when the SessionStart hook did not fire
+and the four mechanical checks all pass.
+
+| Harness | Environment marker | Adapter | Install to |
+|---|---|---|---|
+| Claude Code | `CLAUDE_CODE_ENTRYPOINT`, `CLAUDE_CODE_SESSION_ID` | none needed | n/a |
+| omp (Oh My Pi) | `OMPCODE=1` | `harness/omp/forge-bridge.ts` | `~/.omp/agent/extensions/` |
+
+**`CLAUDECODE=1` does not identify Claude Code.** omp sets it deliberately, for tool
+compatibility, in the same environment where it sets `OMPCODE=1`. Read it as necessary
+and not sufficient, and match a harness's own marker first. A harness absent from this
+table is the expected case rather than an error, and the honest report is that the
+manifest is probably not being read, with no cause invented.
+
+Adding a harness is one row here and one directory beside this file.
+
 ## omp (Oh My Pi)
 
 `omp/forge-bridge.ts`. Copy to `~/.omp/agent/extensions/forge-bridge.ts` and

skills/forge-code/SKILL.md

@@ -86,7 +86,7 @@ A slice is done when all of these hold:
 - The failure paths log what the SRS observability section says they log, and you have read that output
 - The pre-push hook passes without `--no-verify`
 - `TODO.md` and `CONTINUE.md` reflect reality: this slice's entry has left the backlog for Completed, `CONTINUE.md` states the next action rather than the story of this one, and neither restates what `docs/DECISIONS.md` or `docs/traceability.md` already owns
-- Under `records: backfilled` that closure is two edits, not five: set the task record's `status` and its `satisfies`, and add one decision record carrying the reasoning with `decided_in` naming the task. Then `node .forge/forge-records-lint.js`, `node .forge/forge-index.js build`, `node .forge/forge-views.js render`, and commit the records with the regenerated views. The views are generated, so writing the closure into them by hand is denied by a hook rather than merely discouraged
+- Under `records: backfilled` that closure is two edits, not five: set the task record's `status` and its `satisfies`, and add one decision record carrying the reasoning with `decided_in` naming the task. Then `node .forge/forge-records-lint.js`, `node .forge/forge-index.js build`, `node .forge/forge-views.js render`, and commit the records with the regenerated views. The views are generated, so writing the closure into them by hand is caught rather than merely discouraged, by the mechanism `forge-standards` names
 
 Then merge to `main` with `--no-ff`, delete the branch, and push.
 
@@ -122,7 +122,7 @@ Cadence, gates, and the release checklist are in `forge-standards`. The last str
 The execution order in this phase:
 
 1. Run the `forge-design` polish pass over every surface this milestone touched. Clear the `finish` and `degrades` items or get a decision to slip each one, and record the run, the findings, and their dispositions in the polish log in `docs/DESIGN.md`. In the same pass, sweep every open UX debt row whose slip target is at or below this version: closed, or re-anchored forward with the user's agreement
-2. CI green and the full suite green, coverage reported
+2. CI conclusion read for HEAD's SHA and quoted with its run ids, per `forge-standards`, plus the full suite green and coverage reported. The release proposal cannot be made without that reading; a "CI green" line carried in from an earlier session is not it
 3. Traceability matrix complete for every requirement claimed in this release, `UX-nnn` included
 4. Regenerate API reference and architecture docs from CodeGraph queries
 5. Confirm no screenshots are STALE or MISSING