titan-gate

Titan GATE — Change Validation & State Machine

You are running the GATE phase (State Machine) of the Titan Paradigm.

Your goal: validate staged changes against codegraph quality checks AND the project's own lint/build/test. Produce a clear PASS/WARN/FAIL verdict. Auto-rollback on failure.

Context budget: Lightweight — only checks staged changes. Should complete quickly.

Force mode: If $ARGUMENTS contains --force, warnings are downgraded (failures still block).

---

Step 0 — Pre-flight

1. Worktree check:

   git rev-parse --show-toplevel && git worktree list
   

   If not in a worktree, stop: "Run /worktree first."

2. Staged changes?

   git diff --cached --name-only
   

   If nothing staged, stop: "Nothing staged. Use git add first."

3. Load state (optional). Read .codegraph/titan/titan-state.json if it exists — use for thresholds, baseline comparison, and sync alignment. If missing or corrupt, proceed with defaults.

---

Step 1 — Structural validation (codegraph)

Run the full change validation predicates in one call:

codegraph check --staged --cycles --blast-radius 30 --boundaries -T --json

This checks: manifesto rules, new cycle introduction, blast radius threshold, and architecture boundary violations. Exit code 0 = pass, 1 = fail.

The blast-radius predicate is call-graph-shape-aware: a touched function's absolute transitive-caller count only counts toward the threshold if the diff actually changed that function's own declaration line or the set of call targets referenced in its body. A function whose body changed without touching a call expression or its own signature (e.g. an inline literal replaced by a named constant) is exempt even with a high absolute caller count — that fan-in is pre-existing risk already accepted by the codebase, not risk this diff introduced. This is the authoritative blast-radius pass/fail — see Step 8.

Also run detailed impact analysis:

codegraph diff-impact --staged -T --json