R76.H3 Heritage Tagging — Contract

Round: R76 (Phase 0 → 1 bridge) Task: R76.H3 — inline Phase 0 reality stamps on 4 active skills carrying donor-era tool references Branch: feature/r76-h3-heritage-tagging Date: 2026-04-19

1. Intent

Mark every donor-era tool reference inside four active (non-HERITAGE) skills so that a reader grazing the text cannot confuse donor-era vocabulary for current Phase 0 surface. The skills stay active — they still carry live Phase 0 guidance. This is a belt-and-suspenders layer on top of existing negation prose, not a rewrite.

2. Authored formats

2.1. Inline strike (for specific tool names)

Where a specific donor tool name is mentioned (e.g., gsd_validate, roadmap_nodes, unified_set_project, memory_pack), wrap it in markdown strike-through plus an inline footnote:

~~`gsd_validate`~~ <sup>(Phase 0: deferred to Phase 1.5+ per ADR-005; not in the 14-tool surface)</sup>

The backticks stay inside the strike-through to preserve the monospaced visual. The footnote is a <sup> tag so it renders as a small superscript.

2.2. Phase 0 note callout (for family wildcards and for sections containing many names)

Where a paragraph mentions one or more family wildcards (gsd_*, unified_*, roadmap_*, etc.), or where a table / list contains many names such that per-name inline strikes would cripple readability, add a blockquote callout immediately after the paragraph / table:

> **Phase 0 note:** The `gsd_*`, `unified_*`, `roadmap_*`, `memory_*`, `context_*`, `analysis_*`, `observe_*`, and `watcher_*` families are donor-era and not in the Phase 0 surface. Phase 0 ships **14 tools** — see [ADR-004 R75 Wave H amendment](../../../docs/architecture/decisions/ADR-004-tool-surface.md).

The wildcard backticks stay as-is (they are family markers, not calls).

2.3. Top-of-file R76.H3 reality stamp

Each of the 4 skills already has at least one Phase 0 reality stamp from earlier rounds. R76.H3 adds a short marker line after the existing stamp (never overwriting it):

> **Post-Phase-0 reality stamp (2026-04-19, R76.H3).** Some tool names below mark donor-era deferred capabilities; the Phase 0 shipped 14-tool surface is authoritative — see [ADR-004](../../../docs/architecture/decisions/ADR-004-tool-surface.md).

3. Edit policy

  • Do not delete donor-era tool names. The heritage value of the names (so readers can map donor requests → Phase 0 equivalents) is preserved.
  • Do not blanket-HERITAGE the 4 skills. They are live Phase 0 guidance with pockets of donor vocabulary.
  • Use Edit tool (not Write) to preserve existing file structure.
  • Do not touch .claude/skills/... — mirror sync is a separate task.
  • Do not touch any skill other than the 4 in scope.
  • Do not touch src/.

4. Selection rule (when to strike vs. callout)

For each donor-era mention:

  1. Is it a specific tool name (has a concrete identifier like gsd_validate, roadmap_nodes)?
    • Yes + only 1–3 names in the paragraph → inline strike per name.
    • Yes + 4+ names in the paragraph → single callout after paragraph.
  2. Is it a family wildcard (gsd_*, unified_*)?
    • Callout after paragraph (wildcards are negation markers, not tool calls — striking them would mangle the family vocabulary).
  3. Is the mention inside a table row / bullet list with a heading that already telegraphs the intent (e.g. heading “Donor references — do not use”)?
    • Single callout directly under the heading or immediately after the list/table.
  4. Is the mention inside an existing Phase-0-note paragraph (e.g. the top-of-file stamp that says “Do not invoke donor tools like …”)?
    • Inline strike on each specific tool name only. Do not add a second callout (the paragraph itself is the stamp).

5. Phase 0 14-tool surface (canonical, for cross-reference)

  • β (5): task_create, task_list, task_get, task_update, task_next_actions
  • ζ (4): audit_session_start, thought_record, thought_record_list, audit_verify_chain
  • η (2): merkle_finalize, merkle_root
  • ε (1): skill_list
  • System (2): server_ping, server_health

Any name not in the above list is donor-era.

6. Acceptance

  • Every donor-era family wildcard and specific tool name in the 4 canon skills is covered by either ~~...~~ strike-through + inline footnote, or an immediately-following > **Phase 0 note:** callout.
  • Each of the 4 canon skills carries the R76.H3 reality-stamp marker line (in addition to any pre-existing Phase 0 stamps, not replacing them).
  • Post-edit grep shows every match reconciles against either a ~~ marker in the same line or a > **Phase 0 note:** block immediately below the paragraph containing the match.
  • .claude/skills/ has zero diff (verified via git status).
  • npm run build && npm run lint && npm test green in the worktree.

7. Non-acceptance (fail triggers)

  • Any donor tool name left unstamped (no strike, no adjacent callout).
  • Any edit under .claude/skills/.
  • Any skill touched outside the 4 in scope.
  • Any deletion of a donor tool name from the body.
  • Broken markdown (un-closed strike, missing backticks, mismatched <sup>).

8. Audit trail references

  • Inventory: docs/audits/r76-h3-heritage-tagging-audit.md
  • Edit plan: docs/packets/r76-h3-heritage-tagging-packet.md
  • Verification: docs/verification/r76-h3-heritage-tagging-verification.md
  • ADR-004 (R75 Wave H amendment, 14-tool surface): docs/architecture/decisions/ADR-004-tool-surface.md
  • ADR-005 (multi-model defer to Phase 1.5): docs/architecture/decisions/ADR-005-multi-model-defer.md

R76.H3 contract — inline tagging format, selection rule, and acceptance. Upstream: audit. Downstream: packet → implement → verify.

Back to top

Colibri — documentation-first MCP runtime. Apache 2.0 + Commons Clause.

This site uses Just the Docs, a documentation theme for Jekyll.