@tyroneross/build-loop 0.36.1 → 0.43.0

package/skills/decision-queue/references/example-large-queue-batching.md

@@ -0,0 +1,164 @@
+<!-- SPDX-FileCopyrightText: 2025-2026 Tyrone Ross, Jr <46267523+tyroneross@users.noreply.github.com> | SPDX-License-Identifier: Apache-2.0 -->
+
+# Worked example: batch-claim triage
+
+Built 2026-08-26 against a personal knowledge-base planner backlog. The pattern
+is reusable; nothing in it is specific to that source beyond the data it was
+pointed at. Counts below are the real ones from that run.
+
+## The problem this variant solves
+
+The base decision-queue pattern gives every decision its own card. That works
+while the decisions are few and genuinely distinct. It fails when the queue is
+large, because a page of 128 cards reproduces exactly the overwhelm that made
+the user ask for a page in the first place.
+
+The planner backlog was 128 open items past their date. Presenting 128 cards
+would have been honest and useless.
+
+## The insight that made it tractable
+
+**Most of a large backlog shares a few causes.** Classify first, and the work
+collapses. Of the 128 items:
+
+- 28 named a clock time on a day that had passed.
+- 13 were example text typed while setting the tool up.
+- 4 were prep for meetings that had a recording proving they happened.
+
+That is 45 items and three decisions. The remaining 83 were the real backlog.
+The user ruled all three batches in three clicks and confirmed every claim
+without a single override.
+
+## The shape
+
+Three levels, which is the same progressive disclosure the base pattern uses,
+with a pyramid substituted for the flat card.
+
+**Level 1 — the batch card.** One claim, then the evidence for it.
+
+- `claim` — the governing thought. A falsifiable sentence stating what is
+  true of every member, with a real predicate. *"These 28 tasks can no longer
+  be done. Each one names an hour on a day that has already passed."*
+- `because` — three peers that answer the one question the claim raises, each
+  an independent fact, each counted from the data rather than asserted.
+  *"23 name a clock time; the other 5 name a drop-off, a pickup, or a
+  departure."*
+- Two actions: rule the whole batch the recommended way, or rule it the
+  opposite way.
+
+**Level 2 — the drill-in.** A full-width panel listing every member of the
+batch with its date and `file:line`, each keeping its own disposition
+dropdown. Restates the claim at the top and offers two ways back.
+
+**Level 3 — the residue.** Everything that did not classify, grouped by owning
+scope, each row with a disposition and a note field.
+
+## Why the claim and the evidence are load-bearing, not decoration
+
+A batch ruling asks someone to close 28 things on the strength of three
+bullets. That is only safe when three conditions hold.
+
+**The claim is falsifiable.** "These are old" cannot be disagreed with
+usefully. "Each one names an hour on a day that has passed" can be checked
+against any row.
+
+**The evidence is counted, not impressionistic.** Every number in the key line
+was computed from the data before it was written. A bullet that turned out to
+be decorative would be doing real damage at 28x leverage.
+
+**The classification rule is stated, so the user can reject the rule rather
+than the outcome.** The footer names how each class was assigned. Disagreeing
+with "a line is *pinned* when it names a clock time" is a more useful
+conversation than disagreeing with 28 individual verdicts.
+
+**The drill-in exists.** A batch ruling you cannot audit is a guess you are
+forced to trust. Per-item override inside the drill-in is what makes the
+batch action a proposal instead of a demand.
+
+## When to use this instead of the base pattern
+
+| Signal | Base decision-queue | Batch-claim triage |
+|---|---|---|
+| Item count | Up to roughly 20 | 50+ |
+| Item independence | Each needs its own judgment | Most share a cause |
+| What blocks the user | Not knowing the tradeoffs | The volume itself |
+| The page's job | Elicit N judgments | Collapse N into a few, then elicit the rest |
+
+Use the base pattern when the items are peers with nothing in common. Use this
+when you can honestly write one sentence that is true of thirty of them. If you
+cannot write that sentence, you do not have a batch, and forcing one produces a
+claim the evidence will not carry.
+
+## Landmines specific to this variant
+
+**Do not classify by repetition count.** The first pass grouped items by how
+many day notes they appeared in, on the theory that a repeatedly-copied task is
+durable work. It conflated two different things: a camp drop-off appeared four
+times because camp ran four days, not because it was carried forward four
+times. Classify by whether the task is time-bound; repetition count is a
+different signal and answers a different question.
+
+**Native `<select>` paints its own bevel.** On macOS the platform control draws
+a gradient and inner bevel underneath any border you set. Combined with a
+colored border for a "set" state, it reads as a glow, which the user rejected
+on sight. Set `appearance: none`, draw the chevron as a background image, and
+indicate state with a flat left rule rather than a fill or a ring. Same for
+textarea and search inputs: `appearance: none; box-shadow: none`.
+
+**A colored wash on a decided row is the same mistake at lower intensity.** Use
+`box-shadow: inset 3px 0 0 <accent>` instead of a background fill.
+
+## Variant on self-publish: single-source instead of two-copy
+
+The base template keeps `HEAD_HTML` and `SAVE_BAR_HTML` as literal constants
+that must be edited in two places whenever the markup changes, and SKILL.md
+correctly warns about that hazard.
+
+This page took a different route to the same safety. **CSS lives only as a JS
+constant inside the app script and is injected into a `<style>` on boot**, so
+the published document and the running document are styled from one source and
+cannot drift. The script re-embeds itself with
+`document.getElementById("app").textContent`, which is the same safe DOM read
+the base template already relies on.
+
+Both approaches avoid the real bug, which is capturing `document.head.innerHTML`
+and sweeping up the viewer's injected bootstrap. Pick by which hazard you would
+rather carry:
+
+- **Two-copy constants:** first paint is immediate; every markup edit must land
+  in two places or the saved page silently diverges.
+- **Single-source injection:** no possible drift; first paint waits one frame
+  for the style injection, which is invisible on a tool but would be wrong on a
+  marketing page.
+
+For a working surface the user returns to, single-source is the better trade.
+
+## Verification that caught real defects
+
+Run these before publishing; each one found something.
+
+```bash
+node --check <extracted app script>        # syntax
+
+# 1. Render smoke test with a DOM stub: assert the item count, the number of
+#    disposition controls, and the number of note fields all match the data.
+# 2. Drill-in test: for each batch class, set the open-batch state, re-render,
+#    and assert the panel emits exactly as many component rows as that class
+#    has members.
+# 3. Save round-trip: call buildDocument(), then assert the output starts with
+#    <!doctype html>, that the app script re-extracts byte-identical to the
+#    original, that a mutated ruling survives the trip, and that no raw
+#    </script> escaped into the embedded source.
+```
+
+The round-trip test is the one that matters. It is the difference between
+"the save button probably works" and knowing the saved page is the same
+program.
+
+## Reusability note
+
+This was built against a personal knowledge-base planner backlog, but nothing in the
+shape depends on that. It applies to any large, classifiable set the user must
+dispose of: a stale-issue sweep, a dependency-upgrade queue, a dead-code
+inventory, an inbox of unrouted records. Point it at a set, find the classes,
+write one claim per class, and make every claim auditable.

package/skills/decision-queue/scripts/regen_template_constants.py

@@ -0,0 +1,160 @@
+#!/usr/bin/env python3
+"""Regenerate the decision-queue template's self-publish constants from its markup.
+
+WHY THIS EXISTS
+---------------
+`assets/template.html` carries its <head> CSS and its save-bar markup TWICE:
+
+  1. as real markup the authored page renders, and
+  2. as the `HEAD_HTML` / `SAVE_BAR_HTML` template-literal constants inside
+     `<script id="app-script">`, which `buildDocument()` splices into every
+     republished copy.
+
+They must be byte-identical. They cannot be replaced with a runtime
+`document.head.innerHTML` read: the claude.ai artifact viewer injects its own
+bootstrap script into <head> before the page's script runs, so a DOM capture
+bakes that injected script into the save. One reload later the viewer injects a
+second copy on top of the stale one and the page's <style> stops applying —
+a real, shipped, user-visible bug (2026-08-26).
+
+SKILL.md told authors to keep the two copies in sync by hand and sketched this
+script without shipping it. The predictable happened: `SAVE_BAR_HTML` was left
+as an empty string while 285 characters of save-bar markup sat in the file, so
+every republished page shipped with no Save button, no status line, and no
+counter — the page could be saved exactly once, then broke.
+
+Hand-syncing is the defect. Run this instead, and let
+`tests/test_decision_queue_template.py` fail the build when the copies drift.
+
+USAGE
+    python3 regen_template_constants.py            # rewrite in place
+    python3 regen_template_constants.py --check    # exit 1 if out of sync
+"""
+from __future__ import annotations
+
+import argparse
+import pathlib
+import re
+import sys
+
+TEMPLATE = pathlib.Path(__file__).resolve().parent.parent / "assets" / "template.html"
+
+# The authored markup runs from <title> to the close of the page's own <style>,
+# and the save bar from its shell div to just before the content-zone script.
+HEAD_BLOCK_RE = re.compile(r"<title>.*?</style>", re.S)
+SAVE_BAR_BLOCK_RE = re.compile(
+    r'<div class="save-bar-shell".*?</div>\s*\n</div>', re.S
+)
+HEAD_CONST_RE = re.compile(r"(  var HEAD_HTML = `)(.*?)(`;)", re.S)
+SAVE_BAR_CONST_RE = re.compile(r"(  var SAVE_BAR_HTML = `)(.*?)(`;)", re.S)
+
+
+class TemplateError(RuntimeError):
+    pass
+
+
+def _authored_region(html: str) -> str:
+    """Everything before the plumbing script — the markup the page renders.
+
+    Bounding the search matters: `HEAD_HTML`'s own value also contains
+    `<title>...</style>`, so an unbounded regex would match the constant and
+    compare it against itself, which passes no matter how far it has drifted.
+    """
+    # Anchor to line start: the authoring comment at the top of the file names
+    # `<script id="app-script">` in prose, and a plain substring search finds
+    # that mention first, truncating the region to ~270 chars and hiding the
+    # real markup entirely.
+    m = re.search(r'^<script id="app-script">', html, re.M)
+    if not m:
+        raise TemplateError('no <script id="app-script"> tag in template')
+    return html[:m.start()]
+
+
+def extract_blocks(html: str) -> tuple[str, str]:
+    authored = _authored_region(html)
+
+    head = HEAD_BLOCK_RE.search(authored)
+    if not head:
+        raise TemplateError("could not find the authored <title>...</style> block")
+
+    bar = SAVE_BAR_BLOCK_RE.search(authored)
+    if not bar:
+        raise TemplateError("could not find the authored save-bar-shell block")
+
+    head_txt, bar_txt = head.group(0), bar.group(0)
+    for name, block in (("head", head_txt), ("save bar", bar_txt)):
+        # These get spliced into JS template literals; a backtick or ${ would
+        # terminate the literal or interpolate, silently corrupting the constant.
+        if "`" in block:
+            raise TemplateError(f"{name} block contains a backtick; template literal would break")
+        if "${" in block:
+            raise TemplateError(f"{name} block contains ${{; template literal would interpolate")
+    return head_txt, bar_txt
+
+
+def render(html: str) -> str:
+    """Return `html` with both constants rewritten from the authored markup."""
+    head_txt, bar_txt = extract_blocks(html)
+
+    for const_re, value, label in (
+        (HEAD_CONST_RE, head_txt, "HEAD_HTML"),
+        (SAVE_BAR_CONST_RE, bar_txt, "SAVE_BAR_HTML"),
+    ):
+        if not const_re.search(html):
+            raise TemplateError(f"could not find the {label} constant to rewrite")
+        # A lambda avoids re.sub's backslash-escape handling mangling CSS.
+        html = const_re.sub(lambda m, v=value: m.group(1) + v + m.group(3), html, count=1)
+    return html
+
+
+def drift(html: str) -> list[str]:
+    """Names of constants that do not match the authored markup."""
+    head_txt, bar_txt = extract_blocks(html)
+    out = []
+    for const_re, value, label in (
+        (HEAD_CONST_RE, head_txt, "HEAD_HTML"),
+        (SAVE_BAR_CONST_RE, bar_txt, "SAVE_BAR_HTML"),
+    ):
+        m = const_re.search(html)
+        if not m:
+            out.append(f"{label} (constant missing)")
+        elif m.group(2) != value:
+            got, want = len(m.group(2)), len(value)
+            out.append(f"{label} (constant {got} chars, markup {want} chars)")
+    return out
+
+
+def main() -> int:
+    ap = argparse.ArgumentParser(description=__doc__)
+    ap.add_argument("--check", action="store_true",
+                    help="report drift and exit 1 instead of rewriting")
+    ap.add_argument("--path", type=pathlib.Path, default=TEMPLATE)
+    args = ap.parse_args()
+
+    html = args.path.read_text(encoding="utf-8")
+    try:
+        bad = drift(html)
+    except TemplateError as e:
+        print(f"error: {e}", file=sys.stderr)
+        return 2
+
+    if args.check:
+        if bad:
+            print("template constants are OUT OF SYNC with the authored markup:")
+            for b in bad:
+                print(f"  - {b}")
+            print("\nfix: python3 skills/decision-queue/scripts/regen_template_constants.py")
+            return 1
+        print("template constants match the authored markup")
+        return 0
+
+    if not bad:
+        print("already in sync; nothing to do")
+        return 0
+    args.path.write_text(render(html), encoding="utf-8")
+    print("regenerated: " + ", ".join(b.split(" ")[0] for b in bad))
+    return 0
+
+
+if __name__ == "__main__":
+    sys.exit(main())

package/skills/defenseclaw-bridge/SKILL.md

@@ -151,6 +151,6 @@ defenseclaw-bridge: missing reference file <path>. Cannot generate DefenseClaw s
 
 ## Related references
 
-- `~/dev/research/topics/product-dev/product-dev.agentic-systems-security-references.md` — the security canon citing DefenseClaw as a T1 reference implementation, plus the three-pillar Govern / Inspect / Prove model.
-- `~/dev/research/topics/product-dev/product-dev.agentic-systems-original-synthesis.md` — recommends adding DefenseClaw to the agent-builder catalog as the security-governance reference architecture.
+- "Agentic Systems — Security References" (private research note — substance summarized here) — the security canon citing DefenseClaw as a T1 reference implementation, plus the three-pillar Govern / Inspect / Prove model.
+- "Agentic Systems — Original Synthesis" (private research note — substance summarized here) — recommends adding DefenseClaw to the agent-builder catalog as the security-governance reference architecture.
 - `https://github.com/cisco-ai-defense/defenseclaw` — DefenseClaw repo. Apache 2.0. Cisco-backed.

package/skills/defenseclaw-bridge/references/dc-config-mapping.md

@@ -4,16 +4,9 @@
 
 Field-by-field mapping from each agent-builder template to the DefenseClaw config row(s) it produces. The bridge skill (`SKILL.md`) walks this mapping when generating `<project>/.defenseclaw/generated/`.
 
-**Canonical agent-builder template paths** (when the plugin is installed locally):
+**Canonical agent-builder templates** (when the `agent-builder` plugin is installed locally): six files under that plugin's `plugin/references/templates/agentic-handoff/` directory — `tool-contract.md`, `agent-manifest.md`, `guardrail.md`, `system-boundary.md`, `flow-topology.md`, `role-card.md`. Locate the plugin's install root the same way any installed plugin is located (`${CLAUDE_PLUGIN_ROOT}` when this bridge is invoked from within it, or the plugin cache/marketplace path otherwise) rather than assuming a fixed absolute path — the plugin is private and not shipped with build-loop.
 
-- `~/dev/git-folder/agent-builder/plugin/references/templates/agentic-handoff/tool-contract.md`
-- `~/dev/git-folder/agent-builder/plugin/references/templates/agentic-handoff/agent-manifest.md`
-- `~/dev/git-folder/agent-builder/plugin/references/templates/agentic-handoff/guardrail.md`
-- `~/dev/git-folder/agent-builder/plugin/references/templates/agentic-handoff/system-boundary.md`
-- `~/dev/git-folder/agent-builder/plugin/references/templates/agentic-handoff/flow-topology.md`
-- `~/dev/git-folder/agent-builder/plugin/references/templates/agentic-handoff/role-card.md`
-
-When the plugin is not installed locally, the project's own copies of these templates (filled in for the build) are the input. Filename match drives the bridge; plugin presence is not required.
+When the plugin is not installed locally, the project's own copies of these templates (filled in for the build) are the input. Filename match drives the bridge; plugin presence is not required. `skills/security-methodology/references/agentic-handoff-templates.md` also carries the vendored substance of `role-card`, `tool-contract`, `guardrail`, `system-boundary`, and `flow-topology` (schemas + the T0–T5 / A0–A4 tables) for repos that don't have `agent-builder` installed at all.
 
 ## Mapping reference (DefenseClaw schema)
 

package/skills/drain-proposals/SKILL.md

@@ -0,0 +1,53 @@
+---
+name: drain-proposals
+description: Walk the cross-repo proposal backlog interactively, deciding apply/reject/defer on each item; never auto-applies. Use when the user says "drain proposals" or "review the proposal backlog".
+user-invocable: false
+argument-hint: "[--all] [--scan-only]"
+---
+
+<!-- SPDX-FileCopyrightText: 2025-2026 Tyrone Ross, Jr <46267523+tyroneross@users.noreply.github.com> | SPDX-License-Identifier: Apache-2.0 -->
+
+You are walking the proposal-drain digest with the user. The drain script is
+`scripts/drain_proposals.py` (cross-repo aggregator; state persists so decided
+items never re-surface). NEVER apply, edit, or delete a proposal without the
+user's explicit decision on that specific item.
+
+A decision is keyed to the finding's CONTENT, scoped to its repo — not to its
+filename. Producers re-emit the same finding under a fresh datestamped filename
+and the daily `drain_self_review_proposals.py` pass archives the superseded copy,
+so a decision recorded here holds across that cycle. The same finding in two
+repos stays two separate decisions, because each repo needs its own fix.
+
+## Procedure
+
+1. Refresh the digest:
+   ```
+   python3 "${CLAUDE_PLUGIN_ROOT:-.}/scripts/drain_proposals.py" scan --json
+   ```
+   Report the headline: `N new / T total` and the per-repo breakdown.
+
+2. If `--scan-only` was passed (`{{ARGUMENTS}}`), stop here — print the digest
+   path and the `new` count, do not walk items.
+
+3. Otherwise walk the `new` items (or all items if `--all` was passed), in the
+   order returned (new first, oldest first). For EACH item present the one-line,
+   repo, id, and age, then ask the user for a decision using AskUserQuestion with
+   options: **Apply**, **Reject**, **Defer**, **Skip** (leave as new), **Stop**.
+   - Batch related items from the same repo into one question when they share a
+     theme, but record each item's decision separately.
+   - **Apply** means: open the proposal, do the work it specifies (or dispatch a
+     build-loop run for it), THEN record `set --status apply`. Applying is real
+     work, not just a state flip — do not mark applied unless the change landed.
+   - **Reject** / **Defer**: record immediately with an optional `--note`.
+
+4. Record every decision:
+   ```
+   python3 "${CLAUDE_PLUGIN_ROOT:-.}/scripts/drain_proposals.py" set --key <KEY> --status apply|reject|defer --note "<why>"
+   ```
+
+5. When the user says Stop or the list is exhausted, re-run `scan` and report the
+   remaining `new` count so the user sees progress.
+
+## Non-negotiable
+- No auto-apply. A proposal is only `applied` after its change actually lands.
+- Decisions are per-item and come from the user, never inferred.

package/skills/focused-loop-builder/SKILL.md

@@ -52,6 +52,37 @@ Keep the runner generic and the loop domain-specific. Do not create a new orches
      python3 .build-loop/loops/<loop-id>/validators/validate_loop.py
      ```
 
+## Deterministic vs AI Step Rubric
+
+For every step in a generated loop, decide whether it is a hardcoded SCRIPT (deterministic) or an AI/LLM step. **Default to code; earn the LLM call.** A probabilistic step placed on a deterministic problem costs money, latency, and audit-failures on *every* run; a deterministic step on a genuinely ambiguous problem fails *visibly* on the long tail. The costs are asymmetric, so when in doubt, choose deterministic.
+
+**DETERMINISTIC (script / rule)** — pick this when the step has any of:
+
+- Enumerable / bounded inputs.
+- Machine-checkable output against a fixed contract.
+- Commits an irreversible or system-of-record action (write, publish, send, migrate).
+- A safety, compliance, or financial threshold.
+- High call-frequency or cost-sensitivity.
+- Must-not-vary-run-to-run output (determinism is part of the contract).
+- Structure the shell / AST / schema already encodes (parse it, don't ask a model to guess it).
+
+**AI / PROBABILISTIC (LLM)** — pick this only when the step genuinely needs:
+
+- Natural-language understanding of intent, tone, or semantics.
+- Open-ended generation, summarization, or insight-extraction.
+- Long-tail inputs no finite rule covers.
+- Judgment or ambiguity as the *actual work*, not incidental to it.
+
+**HYBRID is the default shape:** deterministic scaffold → a narrow LLM step only where a rule can't reach → a deterministic verify/gate on the LLM output. Every generated LLM step must carry (a) an output schema/type and (b) a deterministic post-check. **If you can't write the post-check, the step's boundary is wrong** — narrow the LLM's job until its output is checkable.
+
+**Tie-breaker:** default to deterministic.
+
+This rubric is the loop-authoring twin of build-loop's Item-18 `dispatch_tier` `script` eligibility test (`skills/spec-writing/SKILL.md` §Item 18 — machine-checkable output, fully enumerable inputs, tool exists or is ≤~50 LOC + colocated test) and the repo's deterministic-first posture (`skills/build-loop/references/deterministic-checks.md` where present). Assign the same way here: a loop step earns an LLM tier only when a script cannot reach the work.
+
+Provenance for the rubric (cite when adapting): Anthropic, "Building Effective Agents" (start with the simplest thing that works; prefer composable *workflows* with deterministic code paths + gates over open-ended agents); OpenAI, "A Practical Guide to Building Agents" (validate you actually NEED an agent before building one; rate each tool/action by write-access, reversibility, and financial impact, and gate high-risk actions deterministically). Both land on the same posture build-loop already runs: deterministic by default, LLM where judgment is the work, a check on every probabilistic output. See `build-loop-memory/research/2026-07-06-ai-coding-fundamentals-and-harness-claims.md` (Claim 5).
+
+> **Loop-spec encoding.** Declare each step's assignment with the optional `step_type` (`script | ai | hybrid`) and `post_check` fields per phase — see `references/spec-format.md` §"Deterministic vs AI Steps". These are advisory today (no generator lint yet — see the note in that section); write them so the rubric is auditable by a reviewer and enforceable later.
+
 ## Skill Chaining Guidance
 
 Use skill chaining when the loop has stable phase boundaries and at least one phase is better handled by an existing specialized skill.

package/skills/focused-loop-builder/references/spec-format.md

@@ -46,6 +46,33 @@ skill_chain:
     handoff_artifact: "source_inventory.md"
 ```
 
+## Deterministic vs AI Steps
+
+Each step in a loop is either a hardcoded SCRIPT (deterministic) or an AI/LLM step. **Default to code; earn the LLM call.** The cost of a wrong assignment is asymmetric — a probabilistic step on a deterministic problem burns money/latency/audit-failures every run, while a deterministic step on a genuinely ambiguous problem fails visibly on the long tail — so break ties toward deterministic. The full rubric (DETERMINISTIC / AI / HYBRID triggers, provenance) lives in `SKILL.md` §"Deterministic vs AI Step Rubric".
+
+Phases may declare the assignment with two optional fields:
+
+| Field | Purpose |
+|---|---|
+| `step_type` | `script` \| `ai` \| `hybrid`. Which executor the step uses. Default `hybrid` for any phase that involves generation or judgment. |
+| `post_check` | The deterministic verify/gate applied to an `ai`/`hybrid` step's output. Names the validator id (from `validators`) or an inline pass/fail rule. Required whenever `step_type` is `ai` or `hybrid`. |
+
+Rule: **every `ai`/`hybrid` step must carry (a) an output schema/type and (b) a `post_check`.** If you cannot write the `post_check`, the step's boundary is wrong — narrow the LLM's job until its output is machine-checkable, then re-declare the deterministic parts as `script`.
+
+```yaml
+phases:
+  extract_claims:
+    step_type: hybrid        # deterministic scaffold -> narrow LLM -> deterministic gate
+    summary: "Pull material claims from source text with cited spans."
+    output_schema: "list[{claim: str, source_span: str, assumption: bool}]"
+    post_check: source_trace  # validator id: every claim cites a span or is marked assumption
+  emit_report:
+    step_type: script         # bounded inputs, fixed template -> no model needed
+    summary: "Render the report from the validated claim list."
+```
+
+> **Advisory-only today.** `loop_builder.py` does not yet lint `step_type`/`post_check` — the generator builds packs from presets, and no preset declares per-step types, so there is no field to check at generation time. Adding a linter now would guard a schema nothing emits (a mechanism ahead of its observed need). These fields are defined here so the rubric is auditable by a reviewer and enforceable once presets/specs start declaring them. Aligns with build-loop's Item-18 `dispatch_tier` advisory checks (`tier-sanity-*`), which likewise WARN rather than block.
+
 ## Gate Rules
 
 Keep common gates centralized. Loop specs should name examples, not redefine policy.