h-semio-review

# h-semio-review — Fanout audit (subroutine)

You are running the semiotic fanout audit per FPF X-FANOUT-AUDIT and the semiotics_slideument discipline. The premise: on concept rename / deprecation / spec consistency check, the change must sweep ALL carriers — prose, filenames, manifests, review bundles, provenance, tests, schemas — until fixed-point clean. Skipping carriers leaves zombie references that mislead future operators and agents.

Explicit-only — `disable-model-invocation: true`.

## Step 1 — Identify the object of talk

What CONCEPT or TERM is being renamed / deprecated / audited? Get it from the operator explicitly. Bad: "audit the docs"; good: "rename `Service` to `EnablingSystem` across docs and code".

If renaming, capture both old and new names. If deprecating, capture the old name and the replacement (or explicit "no replacement").

## Step 2 — Map carriers exhaustively

Run discovery across all carrier surfaces:

```bash
# Prose carriers
grep -rl "<term>" --include="*.md" --include="*.txt" --include="*.rst"

# Code carriers
grep -rl "<term>" --include="*.go" --include="*.py" --include="*.ts" --include="*.tsx" --include="*.rs" \
                  --include="*.java" --include="*.js" --include="*.jsx"

# Manifest carriers
grep -rl "<term>" --include="package.json" --include="Cargo.toml" --include="pyproject.toml" \
                  --include="go.mod" --include="*.yaml" --include="*.yml" --include="*.toml"

# Filenames
find . -name "*<term>*" -not -path "./node_modules/*" -not -path "./.git/*"

# Test fixtures
grep -rl "<term>" --include="*_test.*" --include="*.test.*" --include="testdata/*"

# Review bundles & specs
grep -rl "<term>" .haft/ docs/ .context/ 2>/dev/null
```

Build a carrier-by-carrier inventory. Every hit is a potential semio failure if the rename / deprecation doesn't sweep it.

## Step 3 — Classify each hit by statement type

For every hit, classify the statement type (per FPF X-STATEMENT-TYPE):
- Rule (definition / law)
- Promise (deontic commitment)
- Plan (intention)
- Explanation (descriptive)
- Decision (binding choice)
- Gate (admissibility condition)
- Evidence (observation)

This matters because rename behavior differs per type:
- Rule rename = update the definition itself
- Promise rename = potentially break compatibility — flag for operator
- Decision rename = check if referenced in active DRRs (`mcp__haft__haft_query(action="search", query="<term>")`)
- Evidence rename = update label only; observation content is immutable

## Step 4 — Same-name / different-thing check

Look for cases where the term being renamed already has a DIFFERENT meaning elsewhere in the codebase. Example: renaming `Service` to `EnablingSystem` — but `Service` already means something else in `auth/` (HTTP service vs FPF enabling system).

For each ambiguous hit, ask the operator whether this hit is in-scope for the rename.

## Step 5 — Different-name / same-thing check

The inverse: look for cases where the OLD concept appears under different aliases. Example: renaming `Service` to `EnablingSystem` — but the same concept might also be called `Creator`, `Builder`, `Producer` in different carriers. Surface aliases for operator decision.

## Step 6 — Produce fanout repair plan

Output as ordered repair list:

```
Fanout repair plan for rename "<old>" → "<new>":

Phase A — Definitional carriers (update first):
- docs/glossary.md (Rule)
- .haft/specs/term-map.md (Rule)
- internal/types/service.go:42 (Rule — Go type declaration)

Phase B — Reference carriers (update after definitions stable):
- internal/auth/handler.go:80 (uses term in implementation)
- internal/auth/handler_test.go:120 (test fixture)
- README.md:55 (prose explanation)

Phase C — Manifest carriers:
- internal/auth/_meta.yaml:3
- pyproject.toml:14

Out of scope (different concept, same name):
- internal/network/service.go (HTTP service abstraction, not FPF EnablingSystem)

Aliases to disambiguate (operator decision):
- "Creator" appears in 4 files — operator confirm: is this the same concept?
```

## Step 7 — Fixed-point check

After the operator (or downstream agent) applies the repair plan, re-run discovery. Repeat until grep returns zero unexpected hits. Per X-FANOUT-AUDIT: not iterating to fixed-point is the failure mode.

## Step 8 — Surface to operator

Present:
- Carrier inventory (with counts per carrier type)
- Statement-type classification
- Same-name / different-thing ambiguities
- Different-name / same-thing aliases
- Ordered fanout repair plan (Phase A definitional, then references, then manifests)
- Out-of-scope hits explicitly listed

The operator decides what to act on. This skill stops at audit + recommendation — it does NOT execute the renames.

## What NOT to do

- DO NOT bulk-rename without operator approval per ambiguous hit. Same-name / different-thing is the catastrophic semio failure.
- DO NOT skip the fixed-point re-check. Stopping after one pass leaves zombies.
- DO NOT auto-update spec carriers — those are operator authorship per h-onboard discipline.
- DO NOT use this skill for general code search — it's specifically for semio / rename / fanout audit.
- DO NOT classify every hit identically — statement-type matters because rename semantics differ per type.

## FPF spec references

- X-FANOUT-AUDIT — on concept rename, sweep all carriers until fixed-point
- X-STATEMENT-TYPE — every load-bearing sentence = rule / promise / explanation / gate / evidence
- F.17 — Unified Term Sheet (UTS) — the canonical term-mapping carrier
- A.7 — Object / Description / Carrier — what changes vs what holds it
- A.6.9 — Cross-Context Sameness Disambiguation
- E.10 — Lexical discipline

Look up via `mcp__haft__haft_query(action="fpf", query="X-FANOUT-AUDIT")`. The semiotics_slideument in `.context/semiotics_slideument.md` carries the human-facing rationale.