@azure-id/orc 2.1.0 → 2.2.0

package/templates/skills/orc-doc/examples/orc-doc-prd-run.md

@@ -224,7 +224,7 @@ $ orc doc plan checkout-refund --role check --json
       "changed_subparts": [] } ] } ] }
 ```
 
-**One bounded part file per checker**, so there is no line arithmetic anywhere in
+**Bounded part files per checker slice**, so there is no line arithmetic anywhere in
 the check loop and no two checkers ever share a file. The slice carries the
 lint's findings for that file. It never re-reports one: paying a model to repeat
 a free check is the mistake this ordering exists to prevent.
@@ -242,6 +242,13 @@ findings:
 coverage: "sections/04-goals-and-success-metrics.md in full, 1 section, no gaps"
 ```
 
+The return is validated, then RECORDED. One P1 finding is a blocking finding, so
+the section is flagged and the next step is the edit:
+
+```
+$ orc doc parts checkout-refund --findings 04-goals-and-success-metrics=1 --json
+```
+
 ---
 
 ## D8 — the edit wave (cap 2 rounds)
@@ -254,6 +261,10 @@ section. The writer's slice is that one file, the finding, and the instruction.
 
 $ orc doc compile checkout-refund
 ✓ compiled 17 sections → …/document.md  (500 lines)
+
+$ orc doc parts checkout-refund --confirm 04-goals-and-success-metrics --json
+  … the section goes back to the check, and the re-check is clean …
+$ orc doc parts checkout-refund --checked 04-goals-and-success-metrics --json
 ```
 
 For a section stored as sub-parts it opens only the sub-part that needs changing:

package/templates/skills/orc-doc/references/chunking.md

@@ -99,7 +99,9 @@ $ orc doc map prd-checkout-refund-130826 --json
   has not moved does not need re-checking). *The hash is what turns a re-check
   from a full pass into a diff.*
 - **`state`** ∈ `planned | written | checked | user-edited | open | unconfirmed`.
-  COMPUTED from the disk every time — never stored as a claim.
+  COMPUTED from the disk every time — never stored as a claim. `checked` is
+  recorded by `orc doc parts --checked` from a validated checker return and
+  stays only while the hash holds.
 - **Renames are repaired, not lost.** A heading whose text changed but whose
   position and neighbours match is the same section with a new `id`; `doc.json`
   is updated and the history follows it. A heading that appears with no such
@@ -111,7 +113,7 @@ system is ever stale.** That is what makes range-based reading safe.
 ### `unconfirmed` — the state a usage limit leaves behind
 
 A part is `written` only when its hash was recorded from a **validated return**
-(`orc doc parts <slug> --confirm <ids>`, run at the wave's stop sequence). **A
+(`orc doc parts <slug> --confirm <ids>`, run at the wave's stop sequence and after each D8 edit round). **A
 file present with no recorded hash is `unconfirmed`:** a writer killed mid-flight
 leaves a truncated file, and detection is already paid for. `orc doc parts`
 reports it, `orc doc next` offers to re-write it, and `compile` includes it only
@@ -366,7 +368,7 @@ already reported by lint: [{line: 13, rule: "long-sentence", …}]
 rules:     references/generation-rules.md   (5b · 5c · 5d, and the template lock)
 ```
 
-**One bounded part file per checker, so there is no line arithmetic anywhere in
+**Bounded part files per checker slice, so there is no line arithmetic anywhere in
 the check loop**, and no two checkers ever share a file. A checker never opens a
 second file and is never given the whole document. Findings the lint already
 reported are never re-reported — paying a model to repeat a free check is the
@@ -524,4 +526,4 @@ section straight from its own file.
 **The orchestrator never runs `orc doc read`.** It is a command for the HUMAN,
 the same way `orc challenge report` is. Hard rule 0 is not softened by a command
 that happens to print prose: reading the document is still delegated, always, to
-a checker that receives one bounded part file and nothing else.
+a checker that receives the part files of its slice and nothing else.