Skip to content

Stress-test governance by grepping the actual runtime

The pattern

When making architectural decisions that claim to be consistent with existing governance, verify by grepping the actual runtime code — not just by reading the governance documents. Governance documents can drift from the code that implements them, and if the drift isn't caught, decisions end up ratifying the wrong state.

Why it matters

Jordan's 2026-04-14 plan mode session produced Option D for the Mission↔Monday.com schema. His initial lean was Option B (Tasks via epic_tasks). The chief.staff Phase 1 exploration had claimed there was "no monday_sync.py in the v1.2 vault." Jordan stress-tested that claim by running a grep inside his own research phase:

grep -l "subitem" /Claude/scripts/integrations/monday/

Result: zero matches. The script has zero sub-item support in ~3000 lines of production code. chief.staff's "no monday_sync.py" claim was also wrong — the script existed at /Claude/scripts/integrations/monday/dev/monday_sync.py after Jordan's earlier migration work that chief.staff had forgotten about mid-session.

That grep reversed Jordan's recommendation: Option A (native sub-items) would require ~200-500 lines of greenfield code in a live production runtime. Option D would require ~50 lines of extension of existing patterns.

The cost profile inverted entirely based on 5 seconds of grep.

When to apply it

  • Any architectural decision that claims "the current system already supports X" or "the current system does NOT support X"
  • Any governance claim about what production code does or doesn't do
  • Any estimate of implementation cost that depends on reusing existing patterns
  • Any validation of whether a prior decision was implemented correctly

When NOT to apply it

  • Pure governance decisions with no implementation dependency (e.g., "what should our cadence be?")
  • Emergency decisions where grep speed is too slow — in those cases, document the assumption explicitly and flag for verification after the emergency passes
  • Decisions about code that doesn't exist yet — grep has nothing to verify

How to apply it

  1. State the claim explicitly — "The current monday_sync.py does not support sub-items"
  2. Construct a grep that would falsify the claim — grep -l "subitem\|sub_item\|subItem" monday_sync.py
  3. Run it — and be willing to be wrong
  4. Document the result in the decision record, research notes, or plan file — the grep command itself should be reproducible

The grep command IS the evidence. Not "I read the code" (which isn't reproducible) but "I ran this command and got this output" (which is).

The inverse of this pattern: accepting governance claims at face value without verification. In Jordan's case, chief.staff's Phase 1 exploration had claimed something false ("no monday_sync.py exists") and Jordan's initial plan had built on that claim. If Jordan hadn't stress-tested, Option B would have been recommended based on wrong premises, and Option D — which is materially better — would never have surfaced.

Chief.staff's cobbler-has-no-shoes note: chief.staff's own Phase 1 exploration missed the existence of a script that chief.staff herself had migrated to /Claude/scripts/integrations/monday/ earlier in the same session. Mid-session memory of one's own actions is not reliable under load. Grep is.

Examples

2026-04-14 — Jordan's schema design — see description above. The grep that mattered: grep -l "subitem" /Claude/scripts/integrations/monday/dev/monday_sync.py. Zero matches. Decision inverted.

2026-04-14 — chief.staff's tool inventory work — when Rick asked about internal dashboards and chief.staff was listing candidates, the correct response was ls ~/Library/LaunchAgents/ to find actual running services rather than relying on memory of what was discussed earlier. Skipping the grep produced an incomplete list that Jordan later caught.

  • [[DR-003-mission-monday-schema-option-d]] — the decision this pattern produced
  • [[first-agent-kickoff-pattern]] — research phase where grep-the-runtime fits
  • /Claude/scripts/integrations/monday/dev/monday_sync.py — the specific file Jordan grepped

Source

Jordan's (project.manager) plan-mode session 2026-04-14. Produced the clearest example of the pattern we have.

Status

Strong recommendation for all orchestrators and validators. Likely to be promoted to near-rule strength when Mission-related SOPs are authored by sop.manager.