@erclx/aitk 0.76.0 → 0.77.1

package/claude/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "aitk",
   "description": "Automated governance, versioning, and discovery tools for Claude Code.",
-  "version": "0.76.0",
+  "version": "0.77.1",
   "author": {
     "name": "Eric Le",
     "url": "https://github.com/erclx"

package/claude/skills/claude-orchestrate/REQUIREMENT.md

@@ -13,6 +13,10 @@ The queue fails in both directions. It empties and a free worker waits, or it fi
 
 Refilling on a merge and on a thinning ready list leaves the window between them unwatched. A wave mid-build has merged nothing and has moved no rows, so both conditions stay silent across the whole build and the wave finishes into an empty queue, which lands planning on the critical path directly after the stretch where it would have cost nothing.
 
+Every one of those triggers looks forward, so a row already parked is measured once and re-tested never. A blocker cell is a claim about the tree that was true the day it was written, and a merge changes the tree under every parked row at once rather than under the rows naming it. A row therefore sits on a condition that stopped holding weeks earlier with nothing reporting the gap.
+
+Re-measuring one goes wrong twice over, and both ways return a confident number rather than an error. A count read looser than its consumer defines the shape answers a question nobody asked, and a condition measured against the tree at hand reads as unreachable while it stays live in the corpus a shipped command runs against. Waiting is not evidence either, so a row untouched for weeks invites promotion on its age, and a task colliding with everything by construction gets re-measured every pass rather than split.
+
 Writing those plans against the tree alone is the second half, since several branches are already changing the shape a plan describes. A plan carrying a bare path list rather than a constraint per in-flight track leaves the worker guessing which act each path forbids, which is the dangling citation the rule against bare paths already exists to prevent.
 
 The session also writes surfaces it is told only how to read. Refilling the queue promotes and demotes rows in the priority file with no stated method, so a session invents one, and an inline rewrite exits clean when it matches nothing and leaves the board wrong with nothing reporting it. A row carrying prose where a plan pointer belongs costs a worker dispatch, because the ship chain refuses at its guard after the worktree is already open. A plan archived from a worker's own branch strands the pointer the board still carries, and the row reads as correct until someone follows it.
@@ -23,7 +27,7 @@ Output drifts everywhere the contract stops. The specified shape covers invocati
 
 Naming that reader without naming the way in fails on the next axis, and it fails circularly. The command that routes a resume request lives in this body, which is the surface a long session is likeliest to have dropped, and dropping it is the condition the handoff exists to survive, so the session holding a complete handoff cannot reach the runbook that reads it back. The review poll is lost in the same moment and recovered by neither, since it is session-scoped and the resume performs no restart, which leaves a reader who follows the whole handoff with a board and no trigger.
 
-The runbooks the session cannot run from memory fail on a third axis, which is where they are kept. A runbook reached by an installed path is a dependency on a channel this skill does not travel on, so a project holding the plugin and running no install follows the citation to nothing, and nothing reports the break because a missing file produces no error until someone opens the path. Every one of them therefore has to ship inside the skill, the three covering the moments the loop cannot detect and the fourth holding the review trigger. That fourth one fails on an axis of its own, since it names one client's command as the way to start the loop, so a session holding a different recurring-prompt scheduler reaches no path and a client without that command reaches none either, and the file ships to every target holding the plugin.
+The runbooks the session cannot run from memory fail on a third axis, which is where they are kept. A runbook reached by an installed path is a dependency on a channel this skill does not travel on, so a project holding the plugin and running no install follows the citation to nothing, and nothing reports the break because a missing file produces no error until someone opens the path. Every one of them therefore has to ship inside the skill, the four covering the moments the loop cannot detect and the fifth holding the review trigger. That last one fails on an axis of its own, since it names one client's command as the way to start the loop, so a session holding a different recurring-prompt scheduler reaches no path and a client without that command reaches none either, and the file ships to every target holding the plugin.
 
 The session also records nothing of what it learns. Both other callers of memory capture are ship-chain skills and this one never ships, so the session taking every operator correction is the session with no moment that writes one down. Hanging that moment on the merge sweep answers it and bills the operator a capture pass per batch of merges while nothing is being built, which is a cost paid on the days shipping is fastest.
 
@@ -52,6 +56,11 @@ The session also records nothing of what it learns. Both other callers of memory
 - State which rule wins where the tracked-file ban collides with the root instruction on small edits, and where a correction no open task owns goes
 - State the review trigger as a recurring prompt rather than as one client's command, since the runbook ships to targets running whatever client they run
 - Read the handoff or the resume runbook when the human asks for that side of a compaction, since the request is the only signal available for a moment the loop cannot detect
+- Re-test every parked row's blocker against the current tree on request, since every refill trigger looks forward and none of them re-reads a row already waiting
+- Measure a condition the way the code consuming it defines the shape, and settle which tree the condition is about before counting, since both errors return a number rather than a failure
+- Write each re-test into the row and its measurement into that task's Findings, since a result reported in chat is gone at the next compaction and the next pass measures the same thing
+- Plan a row the re-test clears, since a cleared row carrying no plan is one the next pass looks at again
+- Split a task whose file set collides with every other by construction, rather than re-measuring a scoping defect that reads as a blocker
 
 ## Must not
 
@@ -61,6 +70,8 @@ The session also records nothing of what it learns. Both other callers of memory
 - Hand a worker anything but a plan, because scope lives there
 - Run a second orchestrator against the same board
 - Promote a task to fill the queue when nothing qualifies. A thin queue is a real answer.
+- Promote a parked row on how long it has waited, since age is not a measurement of the blocker
+- Schedule the parked-row pass on a recurring loop, since the review poll owns the one recurring trigger this skill has and a second loop fires into a static board
 - Rewrite the board with a shell stream editor or an inline string replace, both of which exit clean when they match nothing
 - Restate the board, a task file, or a groundwork folder in the pre-compact handoff, which is the padding that makes a handoff stop being read
 - Specify a shape for a correction, since a format for admitting error invites ceremony where plainness is the whole value
@@ -71,6 +82,7 @@ The session also records nothing of what it learns. Both other callers of memory
 - Roadmap absent: omit the roadmap line rather than asserting a version the file does not state
 - Roadmap present but never committed: report the date as uncommitted, since a blank reads as a formatting slip
 - This body dropped from a long session approaching a compaction: name the re-invocation and the runbook paths, since the routing lives in the body and a user-invoked skill routes nothing once it is gone
+- Blocker only an operator can clear: record the row as untestable this pass and name the action owed, rather than re-measuring what no session can move
 
 ## Out of scope
 

package/claude/skills/claude-orchestrate/SKILL.md

@@ -39,7 +39,9 @@ A compaction is a moment this skill cannot detect, so the human asks for each si
 
 The review trigger takes the same shape. `references/orchestrator-poll.md` holds the loop prompt and the condition under which the poll runs, and `scripts/poll.sh` is what the prompt invokes. A session holding a recurring-prompt scheduler starts and cancels that loop itself, and no hook or check does, so the condition holds only while whoever holds the loop applies it.
 
-That routing lives in this body and this skill is user-invoked, so a session that has dropped the body routes nothing and the request lands as ordinary conversation. Approaching a compaction is when a long session is likeliest to have dropped it, which is the same moment the handoff exists for. Re-invoke `/aitk:claude-orchestrate` first whenever the session has run long or the ask goes unanswered. The two runbooks sit at `references/orchestrator-handoff.md` and `references/orchestrator-resume.md` inside this skill's own folder, so a person who knows their plugin root opens either one directly and follows it without this skill loaded at all.
+A board that is not moving is a third such moment. On a request to re-test the parked rows, read `${CLAUDE_SKILL_DIR}/references/orchestrator-parked.md` and follow it. It re-tests every `## Up next` and `## Needs a plan` blocker against the current tree, writes what each test showed into the row, and plans what it clears. Its trigger is the inverse of the refill sweep's below, which fires on a merge and asks what to promote next rather than whether a row already parked is still parked for a reason.
+
+That routing lives in this body and this skill is user-invoked, so a session that has dropped the body routes nothing and the request lands as ordinary conversation. Approaching a compaction is when a long session is likeliest to have dropped it, which is the same moment the handoff exists for. Re-invoke `/aitk:claude-orchestrate` first whenever the session has run long or the ask goes unanswered. The three runbooks sit at `references/orchestrator-handoff.md`, `references/orchestrator-resume.md`, and `references/orchestrator-parked.md` inside this skill's own folder, so a person who knows their plugin root opens any one of them directly and follows it without this skill loaded at all.
 
 ## Output
 
@@ -129,7 +131,7 @@ It counts unclaimed plans against workers rather than reading the reserve in ste
 3. Archive what closed. A task whose outcomes are all `[x]` runs `claude-docs` for the plan sweep, then `claude-tasks` to archive. A task whose outcomes describe standing policy rather than a deliverable never closes on its own, so hand it to a worker to encode the policy where it is enforced, then cut the outcomes with the reason recorded and archive once that branch merges. Encoding it from this session would write a tracked file, which Boundaries forbids.
 4. Read `.claude/tasks/priority.md` and count entries under its `## Run now` heading that carry a written plan. Keep one in reserve beyond what is running.
 5. Promote by whether a task establishes functionality rather than by age. Prefer a task that adds or proves a mechanism over one that trims, tidies, or audits an existing surface.
-6. Before promoting a candidate, list the files it touches against every task already running, per Parallelism below. Name the overlap and serialize when the sets are not disjoint.
+6. Before promoting a candidate, list the files it touches against every task already running, per Parallelism below. Name the overlap and serialize when the sets are not disjoint. A candidate held by something outside the tree stays where it is whatever those sets show. A collision is one of the reasons a task cannot start, so disjointness clears that reason alone and leaves an external condition standing.
 7. Write a plan for each newly promoted task with `claude-feature`, carrying the in-flight constraint that The loop above states, then report:
 
 ```plaintext

package/claude/skills/claude-orchestrate/references/orchestrator-parked.md

@@ -0,0 +1,72 @@
+---
+title: Orchestrator parked row runbook
+description: Re-testing every parked blocker against the current tree, the trigger that separates this pass from the merge sweep, and the two ways a re-test goes wrong
+---
+
+Re-test every parked row as orchestrator. A blocker cell is a measurement taken the day the row was parked and nothing re-takes it, so a row can wait on a condition that stopped holding weeks earlier with no surface reporting the gap.
+
+Run this when nothing merged and the board is not moving. Workers are building, no pull request is waiting on a first pass, and the session is otherwise idle.
+
+That trigger is the inverse of the sweep's. `orchestrator-sweep.md` runs after a batch of merges and asks which parked row to promote next, taking the blocker cell as read. This pass asks whether that cell is still true. Both walk the same rows and both can end in a promotion, so a session reading them as one pass runs whichever it remembers and re-tests nothing.
+
+A merge is still worth following with this pass even though the sweep already ran. A merge changes the tree under every parked row at once rather than under the rows naming it, and the sweep re-reads none of them.
+
+Nothing starts this pass, and it takes no scheduler of its own. `orchestrator-poll.md` owns the one recurring trigger this skill has, and a second loop firing into a static board is the always-on failure that file already warns about.
+
+## Scope
+
+Every row under `## Up next` and `## Needs a plan` in `.claude/tasks/priority.md`. A `## Run now` row carries no blocker by definition, so the pass skips it. Resolve the board and each task file at the main worktree root, per Worktrees in `CLAUDE.md`.
+
+Take the rows in board order and finish one before opening the next. Clearing a row changes what the next row collides with, so a pass that measures every row first and writes afterwards writes against a board it has already invalidated.
+
+## Re-testing a row
+
+The blocker cell states what the row waits on, and each kind is tested differently.
+
+- Collision with a track in flight: intersect the row's Touches column with that of every `## Run now` row. A track that merged since the row was parked is no longer in flight, whatever the sets still share. A `## Needs a plan` row carries no Touches column, so read its file set off the task file before claiming a collision either way.
+- A dependency on another task: open that task. One whose outcomes are all `[x]`, or one already archived, holds nothing.
+- A condition about the tree, such as a count of some shape or the presence of a construct: measure it again, per Two ways a re-test goes wrong below.
+- Waiting on a plan: nothing external holds the row, so the pass writes the plan rather than testing anything. See The plan half below.
+- Waiting on an operator action, such as a run that happens from a shell: record it as untestable this pass and name what the operator has to do. A session cannot clear it, and re-measuring it every pass is waste.
+
+Write the result into the row. A re-test reported in chat is lost at the next compaction and the next pass measures the same thing again. Rewrite a blocker cell whose test no longer holds, move the row to the group its new state puts it in, and record the measurement in that task's `## Findings` with the date it was taken. `### Writing the board` in `claude-orchestrate` owns the method, and `aitk tasks validate` runs once the board is rewritten and before the report.
+
+## Two ways a re-test goes wrong
+
+Both return a confident wrong answer rather than an error, which is why each gets a step of its own.
+
+The first is reading the condition looser than the code defines it. A row parked on a count of some shape names a shape its consumer defines precisely, and a count taken by eye or by a pattern that approximates it lands somewhere else. The row that motivated this runbook counted 19 instances of a shape whose real count under the consumer's definition was zero.
+
+Find the code that consumes the shape, read the definition off it, and measure with that. A count taken any other way is not evidence about the blocker.
+
+The second is measuring against the wrong tree. A command that ships to targets is at risk in corpora this repository never formats, so a condition measured here reads as unreachable while it stays live where the command runs. Ask which tree the condition is about before asking what the count is. A local formatter removing the shape on contact says nothing about a target running no such formatter.
+
+## The plan half
+
+Plan what the pass clears, and plan any `## Needs a plan` row whose only blocker is the missing plan. The window is the argument: this pass runs while workers build and the session is otherwise idle, which is when planning costs the critical path nothing, and a row cleared with no plan is a row the next pass looks at again.
+
+Run `claude-feature` for each, carrying the constraint per in-flight track that `## The loop` in `claude-orchestrate` requires. Verify each plan against the tree the way that step does, since a plan written now is written against a tree several branches are already changing.
+
+Stop where `## Parallelism` stops rather than planning every row the pass cleared. A plan whose file set collides with every track in flight is one nobody can dispatch.
+
+Do not restate the refill procedure. `claude-orchestrate` owns it under `## Refilling the ready queue` and `orchestrator-sweep.md` wraps it for a batch of merges, so this pass promotes through that method rather than a second one.
+
+## Two results that are not a re-test
+
+Age is not evidence. A row untouched for weeks invites promotion, and the waiting is not an argument for it. `claude-orchestrate` refuses to promote a task to fill the queue and this pass inherits that refusal, so a row whose blocker still holds stays where it is. Reporting it as still parked, against a measurement taken this pass, is a result.
+
+A scoping defect can wear a blocker. A task whose file set collides with every other task by construction is oversized rather than blocked, and planning it again produces the same plan nobody can dispatch. Split it into tasks with disjoint file sets, so the board stops carrying a row that re-measures the same way every pass.
+
+## Output
+
+```plaintext
+Re-tested: <row>, <blocker> → <what the measurement showed>
+Cleared: <row>, now <group>, plan at <path>
+Still parked: <row>, <blocker> re-confirmed against <what was measured>
+Untestable: <row>, waits on <operator action>
+Split: <task> into <tasks>, file set collided with everything by construction
+```
+
+Omit any row with nothing in it. Name what was measured rather than the verdict alone, since a re-test the reader cannot check is the same claim the row already carried.
+
+Lead the reply with the three slots under `### Every later turn` in `claude-orchestrate`, so the human reads what they own before the evidence for it.

package/docs/agents/context-audit-checks.md

@@ -19,7 +19,7 @@ It reports rather than gates by default, the closer call because a missing secti
 
 ## Length
 
-Length quotes its checkpoint from `.claude/standards/context.md`: roughly 150 rendered lines for an entry. It counts rendered lines rather than source lines, wrapping each line at 80 columns and summing the heights. A line is wrapped at the width it renders at, so a link counts as its anchor text and a backticked path counts whole. That moves 2 of the 48 entries measured, `extensions.md` by 2 lines and `governance.md` by 1, because an entry cites a path in backticks rather than as a link. Entries here are authored one line per bullet, so a block of fifteen paragraph-bullets occupies fifteen source lines and renders past sixty, which source counting cannot see. The measure counts fenced blocks and frontmatter, so a reference-heavy entry ranks by its examples, which the legend states on every run alongside the width, since a number in rendered lines cannot be reproduced without it.
+Length quotes its checkpoint from `.claude/standards/context.md`: roughly 150 rendered lines for an entry, applied to each of the 60 entries the audit measures, 51 of them under `.claude/context/` and 9 diagram files beside them. It counts rendered lines rather than source lines, wrapping each line at 80 columns and summing the heights. A line is wrapped at the width it renders at, so a link counts as its anchor text and a backticked path counts whole, which parts the rendered count from a source count wherever an entry cites a path in backticks rather than as a link. Entries here are authored one line per bullet, so a block of fifteen paragraph-bullets occupies fifteen source lines and renders past sixty, which source counting cannot see. The measure counts fenced blocks and frontmatter, so a reference-heavy entry ranks by its examples, which the legend states on every run alongside the width, since a number in rendered lines cannot be reproduced without it.
 
 Depth and bullet weight are quoted from `.claude/standards/markdown.md`, which states both over every markdown file rather than over a context entry, so `aitk markdown audit` measures them and this command no longer does. They share `renderedHeight` with the length measure, since the two checkpoints sit in one section of that standard and a reader compares them. What the split costs is that a session wanting both numbers for one entry runs two commands, and what it buys is that either number can be had for a file in a folder this audit refuses to resolve.
 
@@ -45,7 +45,7 @@ A fence answers that test for itself, because every scan here skips a fenced lin
 
 The opening delimiter decides that for the whole block rather than each line deciding for itself. A blank line inside an indented fence carries no indentation to read, and a content line may sit at column zero inside one because CommonMark strips the fence's own indent and nothing further. Reading either as unindented ends a run that should have continued, which costs findings rather than inventing them, so no corpus count moves when it is wrong.
 
-Two fenced blocks with nothing between them read as one, so the second takes the first's answer. An unindented block written directly behind an indented one therefore leaves a run standing that it should have ended, which is a false positive rather than a missed finding. Separating the two needs the closing delimiter, which the line walker does not report, and no entry writes adjacent fences today.
+Two fenced blocks with nothing between them are one contiguous run of fenced lines, so the mark alone cannot say where the first ends. The line walker reports which block each line sits in, and the boundary re-reads indentation whenever that number changes, so an unindented block written directly behind an indented one ends the run rather than inheriting the answer above it. No markdown file this repository tracks holds that shape, because a formatter inserts a blank line between two fences on contact, and a target running these commands over an unformatted tree still can.
 
 Precision is the whole value, so recall is the accepted exposure, and two shapes are knowingly out of reach. A narration written as one bullet carrying its own before and after slips through, and nothing else sees it either. So does the perfect passive, since `has been superseded` narrates a supersession and the copula guard rejects it with the passives it exists for. A rejected alternative is a back-reference in the past tense by construction, and the standard keeps what was tried and why it lost, so a legitimate hit exists and no measure separates it from a violation. The report states that on every run, which is why the finding names a line to read rather than a line to delete. The JSON record carries the findings per entry as `entries[].narration` and the sets as `checkpoints.narration`, which is absent under `--citations-only` where the run never loads them and null where no rule publishes both.
 

package/docs/agents/docs.md

@@ -7,7 +7,7 @@ description: How aitk docs resolves the toolkit's own reference surface from an
 
 `aitk docs` emits the toolkit's own reference docs so an agent in a target project can orient without the toolkit source checked out. The CLI resolves `docs/` and `.claude/context/` from its install root, and which of the two it finds depends on how the CLI was installed. A registry install carries `docs/` alone, since `.claude/` is not published. A clone or a linked worktree carries both.
 
-- `aitk docs list [--json]` lists the downstream catalog: the consumer-facing `docs/` surface plus per-domain narrative from `.claude/context/` when that root is present. Toolkit-internal context entries (`ci`, `development`, `extensions`, `sandbox`) are dropped. From a registry install the context section is absent rather than empty.
+- `aitk docs list [--json]` lists the downstream catalog: the consumer-facing `docs/` surface plus per-domain narrative from `.claude/context/` when that root is present. Toolkit-internal context entries (`ci`, `development`, `sandbox`) are dropped. From a registry install the context section is absent rather than empty.
 - `aitk docs <topic>` prints one doc to stdout, resolved by exact name from `docs/` first, then `.claude/context/`. Any doc the install carries is reachable by name, including the toolkit-internal topics the list omits.
 
 A domain too large for one file splits into `<domain>/` with a generated `index.md`, and both verbs name it by the folder. `aitk docs <domain>` prints that index, which is the catalog routing to the sub-area files, and the listing describes it from the index's `subtitle` where a sibling file supplies `description`. A sibling file wins over a folder of the same name. A folder carrying no `index.md` is absent from both, since a catalog is what makes the sub-areas reachable.

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@erclx/aitk",
   "type": "module",
-  "version": "0.76.0",
+  "version": "0.77.1",
   "description": "Infrastructure and quality tooling for developer workflows",
   "license": "MIT",
   "bin": {

package/scripts/docs/list.sh

@@ -11,7 +11,7 @@ source "$PROJECT_ROOT/scripts/lib/frontmatter.sh"
 DOCS_DIR="$PROJECT_ROOT/docs"
 CONTEXT_DIR="$PROJECT_ROOT/.claude/context"
 
-INTERNAL_TOPICS=" ci development extensions sandbox "
+INTERNAL_TOPICS=" ci development sandbox "
 
 show_help() {
   echo -e "${GREY}┌${NC}"

package/src/context/audit.ts

@@ -306,7 +306,8 @@ function narration(
 
   const findings: NarrationFinding[] = []
   let following = false
-  let fenceInsideList: boolean | undefined
+  let fenceBlock: number | undefined
+  let fenceInsideList = false
 
   for (const line of lines) {
     // A fenced line is never a bullet, but an unindented block still ends the
@@ -314,29 +315,25 @@ function narration(
     // the bullets around it are two lists and the second has no antecedent
     // above it. A block indented under its bullet stays inside the item.
     //
-    // The first delimiter of a contiguous fenced run decides for every line of
-    // it. Reading each line instead ends the run on a blank line inside an
-    // indented fence, which has no indentation to read, and on a content line
-    // at column zero, which CommonMark permits since only the fence's own
-    // indent is stripped.
+    // The opening delimiter decides for every line of its own block. Reading
+    // each line instead ends the run on a blank line inside an indented fence,
+    // which has no indentation to read, and on a content line at column zero,
+    // which CommonMark permits since only the fence's own indent is stripped.
     //
-    // Two blocks with nothing between them are one such run, so the second
-    // inherits the first's answer and an unindented block behind an indented
-    // one leaves a run standing that should have ended. Telling them apart
-    // needs the closing delimiter, which `BodyLine` does not carry, and parsing
-    // one here would be the second fence walker this repository consolidated
-    // away after its first pair disagreed. That fix belongs in
-    // `src/markdown/scan.ts` rather than in a copy of it.
+    // The block index is what re-opens that decision, so two blocks written
+    // with nothing between them are answered separately rather than the second
+    // inheriting the first. Indentation stays the test here because what
+    // interrupts a list is this check's own judgment, and the walker only says
+    // which lines share a block.
     if (line.fenced) {
-      if (fenceInsideList === undefined) {
+      if (line.fenceBlock !== fenceBlock) {
+        fenceBlock = line.fenceBlock
         fenceInsideList = INSIDE_LIST.test(line.text)
       }
       if (!fenceInsideList) following = false
       continue
     }
 
-    fenceInsideList = undefined
-
     if (line.text.trim() === '') continue
 
     const bullet = line.text.match(TOP_BULLET)

package/src/markdown/scan.ts

@@ -39,6 +39,17 @@ export interface BodyLine {
   readonly text: string
   /** True on a fence delimiter and on every line between one pair. */
   readonly fenced: boolean
+  /**
+   * Which fenced block the line sits in, counted from one, and undefined
+   * outside one. Two blocks written with nothing between them are one
+   * contiguous run of fenced lines, so this is the only field telling them
+   * apart. Counting from one keeps the outside answer from reading as a block.
+   *
+   * The name carries the fence because `block` alone already names a run of
+   * `BodyLine` values in `src/markdown/structure.ts`, and one word meaning both
+   * an aggregate of lines and an index on each line reads as a bug.
+   */
+  readonly fenceBlock: number | undefined
 }
 
 export type BanKind = 'character' | 'word' | 'spelling'
@@ -58,17 +69,25 @@ export interface BanSets {
 }
 
 /**
- * Marks which lines sit inside a fence without dropping them.
+ * Marks which lines sit inside a fence without dropping them, and which block
+ * each of those lines belongs to.
  *
  * Each measure excludes a fence for its own reason and needs a different
  * response. The depth measure skips a fenced line so an example cannot break
  * the run around it, bullet folding treats one as a break so a bullet does not
  * absorb the block below it, and the ban scan ignores it outright. Returning
  * the mark rather than a filtered list is what lets one walk serve all three.
+ *
+ * The block index answers the consumer that has to decide per block rather
+ * than per contiguous run, since two adjacent blocks are indistinguishable
+ * through the mark alone. It is counted here because the walk already holds
+ * the opening delimiter, and a consumer parsing its own would be the second
+ * fence walker this repository consolidated away.
  */
 function markFences(texts: readonly string[], offset: number): BodyLine[] {
   const lines: BodyLine[] = []
   let fence: string | undefined
+  let fenceBlock = 0
 
   for (const [index, text] of texts.entries()) {
     const match = FENCE.exec(text.trim())
@@ -82,9 +101,15 @@ function markFences(texts: readonly string[], offset: number): BodyLine[] {
     } else if (match) {
       fenced = true
       fence = match[1]
+      fenceBlock += 1
     }
 
-    lines.push({ number: offset + index + 1, text, fenced })
+    lines.push({
+      number: offset + index + 1,
+      text,
+      fenced,
+      fenceBlock: fenced ? fenceBlock : undefined,
+    })
   }
 
   return lines