decision-propagation

Decision-Propagation Protocol

I. The Philosophy

Architectural decisions are not isolated events. When a decision arrives—especially answering an open question in an existing document—it creates ripples across an entire ecosystem of interdependent files. A decision like "auth bypass" doesn't just answer one question; it changes scope in the master plan, triggers deferrals in other documents, and reshapes the status summary of the architecture.

Without a propagation protocol, decisions become stranded. A spec answers a question, but the master plan still lists it as open. A document defers work, but the dependency graph hasn't updated. The system becomes incoherent—different documents contradict each other about what is decided and when.

This skill prevents that dissonance by treating decision-propagation as a deliberate, multi-document process. The human provides the decision once, in one place. Your job is to trace where that decision echoes and update each location.

Core Principle: Decisions propagate or they die.

II. When to Use This Skill

Use the decision-propagation protocol when:

• A human provides answers to open questions in a document or specification
• An architectural decision changes the scope of a release or work track
• A decision in one document affects the content, sequencing, or priorities of others
• You need to defer work from one release to a later one based on new information
• The STATUS file or master tracking document is out of sync with the decisions living in specs
• Any time a decision made in one place must be reflected in many places

III. The Workflow: Five Steps

Step 1: Record Decisions at Source

Locate the document where the decision was made (scout, spec, or master plan section).

Replace the "Open Questions" section with "Decisions ([Name], [Date])". Number each decision:

## Decisions (Cruz, 2026-02-11)

### 1. Entity Backend Priority

**Decision:** Build entity-centric backend first, before other subsystems.

**Rationale:** Reduces scope and focuses team on core abstraction.

**Alternatives Considered:**
- Parallel development of all subsystems → Rejected: coordination overhead
- Start with API gateway → Rejected: needs entities first

**Impact Scope:**
- Defers non-entity tasks to later release
- Reshuffles parallel track allocation
- Affects integration timeline

**Effective Date:** 2026-02-11

---

### 2. Auth Bypass

**Decision:** Skip production auth layer; ship with debug token instead.

**Rationale:** Unblocks frontend integration work; auth hardening can move to later release.

**Alternatives Considered:**
- Build basic auth → Rejected: adds 2-3 weeks to timeline
- Use third-party auth → Rejected: external dependency, integration complexity

**Impact Scope:**
- Removes auth from current scope
- Adds auth to future scope
- Frontend work can proceed immediately
- Security posture (temporary degradation, acceptable for internal alpha)

**Effective Date:** 2026-02-11