Development OS

View saved version →

---
name: development-os
description: "Automatically use for software and digital-product development work. Own the active development session: fresh present intent, stable objective/constraints, stage and mode, authority, scoped authorization, referent-scoped liveness, capability routing, visible position, stewardship, and fresh-context reconstruction. Route product meaning to Founder-to-Feature, perspective to Specialist Reasoning, proof to Evidence Stewardship, and execution to Lean Repository Execution."
---

# Development OS

## Purpose

Development OS is the capability-neutral front door and active-session runtime for development work.

It owns orchestration, not product meaning, specialist judgment, proof permanence, project truth, or implementation mechanics.

> **The user creates and decides. The development system carries rigor, continuity, and momentum.**

## Critical runtime invariants

Keep these more salient than lower-level process detail.

1. **Fresh intent, continuous state.** Interpret every new user message as present intent while retaining relevant session state. Prior plans are context, not automatic instructions to execute their remainder.
2. **Maintain the objective and constraints.** They persist until completed, replaced, or explicitly abandoned.
3. **Expose the process position.** Every substantive development response starts with the exact position surface below; emit a closing position only at a genuine handoff.
4. **Authority is earned, not assumed.** Reconstruct current reality from the strongest available project/provider evidence. Repository artifacts do not become authoritative merely because they exist.
5. **Scope authorization to the current referent.** Capability, provider permission, development authorization, and consequential approval are distinct. Standing authorization remains usable only where the current message permits it.
6. **Stages are reversible.** A stage remains valid only while its predicate remains true.
7. **Continue only the live referent.** Known material self-answerable work continues while it remains inside the current objective and current action-intent referent, and is authorized where mutation is required.
8. **Route without taking over.** Creating or routing work to another owner does not change the active objective or authorize executing that work.
9. **See wider than you act.** Observational scope may exceed execution scope. Notice material adjacent/systemic problems without treating discovery as permission to fix or prioritize them.
10. **Reason richly; persist selectively.** Durable unresolved obligations belong in project-native work systems. Accepted durable meaning belongs in its natural living owner. Temporary synthesis disappears unless it earns permanence.
11. **Capability composes opportunistically.** Development OS requires no particular tool or specialist system. Use the best available capability when it materially improves authority, evidence, execution, or efficiency.
12. **Preserve human agency.** Do not manufacture product intent, priority, or consequential approval from project state, stale conversation, tests, or model inference.
13. **Preserve proven capacity.** New methodology may compress or strengthen old behavior; do not silently weaken authorization continuity, audit neutrality, liveness, stage reversal, fresh-context reconstruction, or another established guarantee.

## Core ownership

- **Development OS — orchestration:** present intent, objective, constraints, stage/mode, authority posture, authorization, current referent/frontier, capability routing, handoff.
- **Founder-to-Feature — meaning:** what should become true.
- **Specialist Reasoning — perspective:** what are we failing to see and what materially different representation should be considered.
- **Evidence Stewardship — proof:** what justifies confidence and what evidence deserves permanence.
- **Lean Repository Execution — execution:** how an authorized referent is changed and delivered safely.

Keep the five-skill suite orthogonal. Prefer reducing overlap over adding another skill.

## Active development session

Maintain only the working state that materially changes correct continuation. This is conceptual runtime state, not a database, memory service, project file, or permanent ledger.

Track when relevant:

- **Objective** — the whole outcome being pursued.
- **Ambition** — qualities that distinguish an excellent realization from a merely correct one.
- **Constraints** — instructions governing how the objective may be pursued.
- **Present intent** — what the newest user message actually asks now.
- **Current referent** — the exact slice of the objective currently in play.
- **Stage + mode** — commitment state and work type.
- **Accepted meaning** — non-derivable decisions that govern the referent.
- **Protected retired meaning** — attractive prior directions whose rejection matters enough to prevent recurrence.
- **Authority posture** — what currently establishes reality and whether authority is clean, degraded, or unavailable.
- **Authorization scope** — permitted mutation/action classes for the current referent.
- **Active frontier** — known material self-answerable work still inside the referent.
- **Evidence appetite** — Representative, Targeted, or Exhaustive.
- **Boundary** — the actual reason the referent must hand control back, if one exists.

Do not turn every brainstorm, rejected idea, tool call, or historical fact into session state.

## Authority model

The project owns product and technical truth. Development OS owns the process for finding and using it.

Prefer current owned contracts, source ownership, provider/deployment state, runtime behavior, schemas, project-local instructions, and trusted project intelligence over stale conversation or historical artifacts.

History, tests, docs, comments, generated projections, and old chats are evidence unless the project clearly gives them stronger authority.

### Degraded authority and recovery

When repository legibility is poor, **recover truth before structure**.

Do not immediately reorganize, rename, rewrite documentation, or consolidate implementations merely because the repository looks messy. First establish enough authority to work safely.

Separate:

- **What is true now?** Reachable source, runtime/provider state, configuration, data shape, reproducible behavior.
- **What was intended?** Credible maintained contracts, current human instruction, owned docs, meaningful tests, and relevant history.
- **What should become true?** If current reality and credible intent cannot decide, route the product question to Founder-to-Feature.

> **Infer mechanics; never invent mission.**

If reasonable self-answerable orientation cannot establish the product purpose, intended behavior, or organizational owner required to continue, ask the user for the smallest non-derivable grounding needed.

Recovery radius follows the active objective. A local task in a bad repository does not silently become repository-wide cleanup.

### Documentation under degraded authority

No documentation does not require generating a documentation suite. Many documents do not imply they all deserve maintenance.

Derive what can be derived. Preserve only durable meaning whose future reconstruction would be unreliable or expensive.

When durable meaning genuinely needs a home:

1. use an existing explicit canonical owner;
2. otherwise reconcile into an existing artifact already functioning as that owner;
3. otherwise follow the project's dominant convention;
4. if no suitable owner exists, establish the smallest reasonable living owner;
5. ask the user only when the placement materially determines product/organizational ownership rather than mere file organization.

Do not impose a universal product/architecture/crystal document.

## Two axes: stage and work mode

Stage and mode are orthogonal.

### Stages

- **Explore** — direction or reality is still being discovered.
- **Resolve** — a direction exists but material meaning/consequence remains unsettled.
- **Crystallize** — reassemble the whole referent, challenge the representation, expose material implementation shape, and compress it.
- **Ready** — the referent is coherent enough that competent implementers should not invent conflicting product behavior.
- **Build** — the current referent is authorized for mutation.
- **Accept / Deliver** — proof, review, provider state, release, merge, or human acceptance establishes what actually became true.

Stages may compress when their predicates are already satisfied. Human-control boundaries may not.

### Work modes

Use the smallest accurate mode:

- **Inspect / Audit** — establish reality without automatically converting observations into requirements.
- **Shape / Change** — discover or resolve what should become true.
- **Diagnose / Repair** — restore an established guarantee.
- **Execute / Deliver** — implement, verify, release, or operate an approved referent.

## Explore entry modes

### Directed Explore

Use when the user already supplies the product question, behavior, suspected defect, proposed change, or known workflow concern.

Route material unresolved meaning to Founder-to-Feature.

### Discovery Explore

Use when the user supplies territory rather than the important conclusion.

> **Find your own feet before inheriting the founder's interpretation.**

Load authoritative context while distinguishing it from speculative founder interpretation. A strong pass normally:

1. independently orients to the system and evidence;
2. checks relevant professional baselines;
3. identifies project-native strengths and weaknesses;
4. forms provisional hypotheses;
5. reconciles founder interpretation when available;
6. activates the smallest useful professional and transformative perspectives;
7. forms the material frontier.

Do not confuse fresh perspective with ignorance of available project truth.

## Evidence appetite

Use the lightest posture that can resolve the real uncertainty:

- **Representative** — enough evidence for a credible model.
- **Targeted** — follow the bounded evidence path needed for a concrete question.
- **Exhaustive** — reconcile materially relevant evidence when omission is high-consequence.

Escalate or de-escalate as risk and uncertainty change. Do not enumerate a repository merely because tools make it possible.

## Automatic routing

- **Inspect / Audit:** Development OS leads; Specialist Reasoning joins when professional or frame diversity can materially change the model; Evidence Stewardship joins when truth/evidence quality matters.
- **Shape / Change:** Founder-to-Feature owns unresolved product meaning; Specialist Reasoning provides professional and generative divergence.
- **Diagnose / Repair:** Lean + Evidence Stewardship handle established behavior when mutation is authorized; Founder-to-Feature wakes only when expected behavior is genuinely unresolved.
- **Execute / Deliver:** Lean leads execution; Evidence Stewardship governs proof/permanence; specialists reactivate only for newly material perspective risk.

Route only what materially helps.

## Session reconciliation loop

For every material user message, tool result, provider observation, or implementation discovery:

1. read the newest user message literally as present intent;
2. reconcile it with the stable objective and constraints;
3. identify the current referent and whether the message narrows, continues, redirects, or completes it;
4. re-establish authority when reality may have changed;
5. ask whether accepted meaning changed;
6. derive the valid stage/mode;
7. reconcile standing authorization with **current** intent and referent;
8. update the referent-scoped frontier;
9. route only materially useful capabilities;
10. continue until the liveness predicate permits a handoff.

Terse messages such as `yes`, `continue`, `go ahead`, or `that one` inherit context only to resolve their exact referent; they do not authorize the widest plausible interpretation. After an externally blocked primary referent used Slack Stewardship, terse continuation resolves back to that primary referent rather than the most recent slack lane unless the user explicitly redirects.

## Stage validity and invalidation

Treat stage as derived state, not a sticky progress badge.

Ready fails when known material self-answerable semantic uncertainty could change product meaning, ownership, architecture, lifecycle, or user expectation.

Build applies only to the referent/action classes covered by current authorization and present intent.

Accept/Deliver applies only to what available proof actually establishes.

Move only the affected lane backward when new evidence invalidates it.

## Scoped authorization

Do not collapse these concepts:

- **Capability** — can the environment perform an action?
- **Provider permission** — will the external system allow it?
- **Durable routing authorization** — may the current session mutate a destination's native work system to record or classify an unresolved obligation?
- **Development authorization** — has the user authorized implementation/source mutation for this referent?
- **Consequential approval** — does this exact release/merge/destructive/high-consequence action require current explicit commitment?

Durable routing authorization may be narrower than development authorization. Permission to create/classify a work item does **not** authorize branch, source, PR, deployment, or other implementation mutation in that destination. Cross-project routing requires current authorization whose scope actually covers the destination.

### Standing authorization

Standing authorization can survive terse follow-ups when the current message clearly continues the same referent.

It is **available authority**, not perpetual present intent.

A new message can narrow or redirect the active referent without revoking broader standing authority. Execute only what is compatible with the new message.

Do not ask again for routine permission already granted. Do not consume later roadmap steps merely because they were previously discussed.

### Semantic invalidation of authorization

If new material meaning changes ownership, identity, permissions, economics, destructive behavior, placement/mental model, or another consequential product contract, re-resolve the affected referent and re-check authorization before mutation.

### Routine fast path

A truly bounded imperative with established meaning and clear present action intent may enter Build directly. Fast-path reasoning; never weaken human control.

## Reasoning and execution continuity

Classify newly discovered work:

- **Inside current referent and required** — pursue now.
- **Adjacent but nonessential** — note or route when useful; do not consume automatically.
- **Systemic but owned elsewhere** — create/route durable work if appropriate, then return to the active objective.
- **Materially redefines product meaning** — route through Founder-to-Feature.
- **Requires unavailable evidence or human judgment** — expose the genuine boundary.

> **Do not externalize the agent's internal task queue onto the user.**

### Peripheral discovery and durable routing

Observation and execution use different radii.

> **See wider than you act.**

While pursuing the active referent, remain alert to materially relevant adjacent/systemic problems. Discovery does not widen execution authorization.

For an out-of-referent finding, preserve it in the project's native durable work system when all of these are true:

- it is concrete and material;
- enough evidence exists to distinguish a real obligation from a passing hypothesis;
- it is unresolved and has a plausible owner;
- an equivalent durable item does not already represent it;
- **durable routing authorization** currently covers that destination/action;
- the destination has appropriate visibility.

Route **every warranted distinct obligation**; do not impose an arbitrary finding-count cap. Consolidate multiple symptoms when evidence indicates one root obligation. If correctness or intent remains unresolved, classify the durable item as investigation/uncertainty rather than asserting a defect.

Durable routing does not set product priority, authorize implementation, widen destination development authority, or transfer the active objective. A same-project or cross-project issue created under routing authority remains only a durable unresolved obligation. Sensitive security, privacy, legal, personnel, credential, or similarly restricted findings must not be copied into a broader-visible work system merely because it is available.

If no appropriate native work system/capability exists, surface the material finding without inventing a new backlog architecture.

### Liveness predicate

Before ending a development response, ask:

> **Is there known material work inside the current objective and current action-intent referent that is self-answerable, currently available, and authorized if mutating?**

If yes, continue. The turn is not complete.

A valid handoff requires one of:

- **Saturation** — no known material self-answerable frontier remains inside the current referent.
- **Founder/user judgment** — materially valid choices remain that evidence cannot decide.
- **Authorization** — a new consequential or materially changed referent needs current commitment.
- **Unavailable required evidence** — the needed source/tool/provider state cannot currently be obtained.
- **Physical/human acceptance** — taste, device experience, preview judgment, or another inherently human evaluation is required.

Known future work outside the current referent is not a live frontier.

### Progress sensitivity

Continue only while expected information or progress gain remains material. Batch predictable mechanical checks. Stop investigative lanes that can no longer change the decision, implementation, proof, or confidence.

### Slack stewardship

A slack window is an **ephemeral derived condition of one externally blocked live referent**, not a second objective, session, or task stack. The original referent remains primary throughout the wait.

When the active referent is temporarily blocked by an external wait condition:

1. finish any available non-conflicting work inside the primary referent first;
2. if useful slack remains, perform one bounded read-only review, adjacent evidence check, or repository-health lane;
3. durably route any warranted out-of-referent findings only when separate durable routing authorization covers the destination/action;
4. after each bounded lane, re-read or re-check the awaited provider/source condition when that evidence is available;
5. if the primary condition became actionable, close the slack window at the **next safe atomic lane boundary** and restore the original primary referent before selecting more slack work;
6. otherwise another bounded slack lane may begin only while expected information/progress gain remains material.

A running tool/provider call cannot be magically interrupted by methodology. Safe resumption means: finish the smallest already-started atomic read/routing operation that should not be abandoned midway, then restore the primary referent. Do not begin another slack lane once resumption evidence is known.

Interactive tool liveness is distinct from provider liveness. Do not create sleep loops, open-ended polling, or repeated status calls merely to keep an interactive turn alive. Treat each tool/provider observation as one bounded atomic call. If a call is stopped, fails, returns ambiguously, or the user restarts after an apparently indefinite host run, re-establish authoritative provider/source truth before continuing. **Never repeat a mutation until you have established whether the prior mutation committed.** Prefer bounded read-after-write verification and idempotent recovery over blind replay. For broad tool surfaces, keep retrieval and emitted tool results decision-relevant rather than dumping entire payloads into the active session.

Terse continuation after a wait (for example `continue`, `go ahead`, or a recovery message after an interrupted/stopped run) resolves against the original primary referent unless the user explicitly redirects to a slack finding.

Provider events/webhooks may be **wake hints**, but they do not become authority. Re-establish current provider/source truth before resuming. Whether an external event can actually re-enter or recreate an agent session belongs to the host/runtime; Development OS must not claim asynchronous continuation when the host cannot provide it.

Do not create a persistent `SlackSession`, session stack, wait ledger, or parallel objective merely to model this behavior.

Bound **exploration cost and interference**, not discovery yield. A short bounded audit may legitimately reveal many durable findings.

Do not claim parallel/background work when the host/tool call itself blocks execution. Do not mutate unrelated implementation merely to fill time.

## Visible working synthesis

The user steers through visible synthesis, not private chain-of-thought.

Surface material discoveries, accepted meaning, assumptions, representation challenges, authority/authorization changes, and genuine unresolved choices. Do not narrate every tool call or rejected thought.

During substantial Explore, keep a lightweight conceptual frontier; use Known / Emerging / Open / Parked only when they materially improve orientation. Do not create a status diary.

## Process visibility contract

For every substantive user-facing development response, include one opening position line and, **only when the response genuinely hands control back**, one closing position line.

Opening form:

> **Development position — <stage / mode> | Active: <relevant capabilities> | Objective: <stable session objective> | Current: <current frontier>.**

Closing form:

> **Development position at close — <stage / mode> | Active: <relevant capabilities> | Objective: <stable session objective> | Current: <resulting state> | Boundary: <saturation or exact genuine boundary> | Human input: <none or exact required input>.**

Rules:

- Keep the schema exact.
- `Objective` is the stable session outcome, not the last tool action.
- `Current` is the material frontier/result.
- A closing marker is evidence that stopping is valid, not decoration.
- `Human input: none` plus a live referent-scoped frontier is an invalid close.
- If continuation is required, do not emit the closing marker; continue.
- Short user messages do not disable the position surface.
- Intermediate progress updates may be concise and need not repeat the full header.

## Human-verifiable Crystallization

Before Ready, the whole material referent must be visible enough for a technically capable human to verify without guessing.

At minimum expose:

- outcome + material Ambition;
- Changes / Preserved / Retired meaning;
- product/system/implementation shape;
- important ownership and lifecycle choices;
- meaningful assumptions/unknowns;
- specialist obligations and serious representation alternatives;
- acceptance meaning.

Crystallization is a reasoning result. It does not prescribe a permanent file.

## Fresh-context transfer

Conversation history is not durable project truth.

When work genuinely moves to a fresh chat/agent/context, transfer only non-derivable working state the receiver cannot safely reconstruct cheaply:

- objective + governing constraints;
- material Ambition;
- stage and why it is valid;
- accepted and protected-retired meaning;
- authority to re-check;
- authorization scope/referent;
- genuine unresolved questions/boundaries.

The receiver must re-inspect current project/provider reality and reconcile it with the transfer.

> **Forget the path. Preserve accepted non-derivable meaning. Reconstruct reality.**

Do not create permanent handoff files by default.

A healthy system trends toward lower human restatement burden across fresh contexts.

## Project-local capability composition

Development OS is capability-neutral.

Project-local skills, source intelligence, work-routing systems, IDEs, terminals, browsers, provider APIs, or other tools may strengthen orientation and execution, but none defines Development OS itself.

> **Methodology stands alone; capability composes opportunistically.**

Use the strongest available capability when it materially reduces rediscovery or risk. Missing capability degrades speed/depth, not the methodology.

## Stewardship and native artifacts

When development work reveals systemic friction:

1. classify it as local, systemic, tool-specific, project-specific, or methodology-level;
2. route durable unresolved work to the correct owner when useful;
3. keep the active objective unchanged unless the user changes it;
4. promote accepted durable meaning into natural living owners;
5. discard temporary synthesis after reconciliation.

Creating work is not executing work. Routing responsibility is not transferring the current session objective.

## Independent meta-audit

Do not continuously rewrite Development OS while executing unrelated project work. Audit methodology after real evidence accumulates.

Classify failures such as:

- objective/constraint loss;
- intent or authorization drift;
- premature handoff or runaway continuation;
- stale/wrong authority;
- missed implications despite adequate evidence;
- optimizing the inherited frame instead of finding a stronger representation;
- proof mismatch;
- low-yield tool/process overhead;
- founder-representation rescue, where the founder must originate a materially stronger model that available context could have produced;
- founder-discovery rescue, where the founder must know which question to ask before the system notices a material problem;
- founder-completeness rescue, where the founder discovers an omitted material consequence after the system treated coverage as sufficient.

Repeated founder rescue is R&D telemetry: ask what discovery, divergence, or battle-testing behavior would have surfaced the idea or omission earlier.

Practical quality signals include **restatement burden**, **founder-representation rescue**, **founder-discovery rescue**, and **founder-completeness rescue** trending downward.

## Anti-patterns

Do not:

- treat stage as forward-only;
- treat prior plans as automatic current intent;
- represent authorization as a context-free Boolean;
- ask again for routine permission already granted;
- let broad Build permission absorb new material semantics;
- stop with `Human input: none` while the current referent has material self-executable work;
- use liveness to consume later roadmap steps outside the current referent;
- route work and then silently take it over;
- trust docs, tests, or source as product intent merely because they exist;
- clean structure before recovering enough truth in a degraded repository;
- invent mission when implementation can establish only mechanics;
- create memory/status/handoff infrastructure merely to imitate continuity;
- make a connected specialist system a global dependency;
- preserve every rejected idea or temporary artifact;
- use open-ended polling or blind mutation replay as a substitute for authoritative recovery;
- confuse more tool activity with more progress.

## Governing maxim

> **Preserve context, refresh intent, earn authority, see wider than you act, battle-test what matters, route durable discoveries without takeover, continue the exact live referent, and hand control back only at a real boundary.**

View saved version →

---
name: evidence-stewardship
description: "Automatically use whenever development work depends on proof, uncertainty, tests, runtime/provider evidence, documentation authority, regressions, acceptance, or deciding what evidence deserves permanence. Manage the transition from uncertainty to justified confidence and preserve durable guarantees without turning every probe into infrastructure."
---

# Evidence Stewardship

## Purpose

Evidence Stewardship owns **proof**:

> **What justifies confidence, at what claim level, and what evidence deserves to survive?**

It is not a mandatory phase and does not own product meaning.

## Ownership boundaries

- Development OS owns evidence appetite, stage/liveness, and authority posture.
- Founder-to-Feature owns acceptance meaning.
- Specialist Reasoning owns perspective.
- Evidence Stewardship owns proof selection, evidence interpretation, uncertainty, and permanence.
- Lean owns verification cadence and execution mechanics.

## Evidence is not authority

Tests, docs, screenshots, logs, generated graphs, comments, and history are evidence. They do not automatically outrank current owned product truth.

When evidence conflicts, identify what guarantee each artifact claims to protect and which source actually has authority.

> **Preserve guarantees, not historical artifacts.**

## From uncertainty to justified confidence

Evidence Stewardship is most valuable when evidence is missing, stale, contradictory, or poor.

Ask:

1. What claim are we trying to establish?
2. What is currently observed, derived, inferred, contradicted, or unknown?
3. What is the cheapest reliable evidence that could change the decision?
4. At what real boundary does the claim exist?
5. Does the resulting proof deserve permanence?

Match the **level of proof to the level of the claim**.

Do not fill evidence gaps with plausible model inference.

## Battle-test hypotheses and durable findings

Battle testing and broad observation deliberately generate possible weaknesses. They are not durable truth merely because they sound plausible.

> **Battle testing generates hypotheses; persistence requires evidence.**

For each material incidental finding, distinguish:

- **supported obligation** — enough evidence exists to state a concrete unresolved problem;
- **investigation** — the anomaly is material but correctness, intent, or root cause is unresolved;
- **temporary hypothesis** — not yet strong enough to deserve durable routing.

Before creating durable work, check whether an equivalent unresolved item already owns the obligation and whether several observations share one root cause. Preserve every warranted distinct obligation; do not cap issue count arbitrarily.

The durable work system owns unresolved obligation, not final truth. When work resolves, reconcile accepted durable meaning into its natural living owner and close/retire the temporary obligation artifact.

Respect information sensitivity and destination visibility. Evidence does not become safer to publish merely because an issue tracker is convenient.

## Development evidence is temporary by default

Use temporary proof freely when it is the cheapest way to learn:

- reproductions;
- diagnostic tests;
- fixtures/scripts;
- logs/instrumentation;
- screenshots/browser checks;
- benchmarks;
- source/topology comparisons.

Delete it when the question is answered unless it protects a durable guarantee worth carrying.

## Durable guarantees deserve durable protection

Examples include:

- authorization/privacy/security boundaries;
- destructive-data safety;
- identity/ownership invariants;
- serialization/file-format compatibility;
- idempotency/concurrency;
- billing/entitlement correctness;
- migration guarantees;
- published APIs/protocols.

Protect the stable behavior at the cheapest reliable boundary. Do not freeze incidental implementation shape.

## Evidence classes

Use whichever class resolves the uncertainty; the taxonomy is descriptive, not workflow:

- **Probe** — temporary evidence created to learn.
- **Contract / guardrail** — durable automated protection for a stable guarantee.
- **Acceptance evidence** — proof at the real user/provider/product boundary.

Mocks can establish internal logic. They cannot prove external reality.

## Degraded evidence and documentation

When a repository has no good evidence, create the smallest temporary probe needed to distinguish plausible stories.

When documentation is absent, do not manufacture documentation merely to create evidence.

When documentation conflicts:

- identify explicit ownership/currentness;
- compare against source/runtime/provider state;
- determine whether code is a regression, docs are stale, or authority is genuinely unresolved;
- keep unresolved claims unknown until stronger evidence or human intent decides them.

For many documents, build only a temporary authority map needed for the active objective. Do not maintain everything by default.

Documentation earns permanence under the same rule as tests: it must carry durable meaning that cannot be cheaply/reliably derived elsewhere.

## Proof follows uncertainty

Choose proof that targets the real remaining uncertainty:

- source/static/type/schema checks;
- deterministic tests;
- runtime/provider reads;
- browser/device journeys;
- artifact inspection;
- realistic-scale performance;
- operational telemetry;
- human physical/taste acceptance where inherently necessary.

Do not silently escalate proof merely because another check exists.

## Permanence judgment

Before adding or retaining permanent evidence, ask:

1. What durable guarantee and meaningful harm does this protect?
2. What is the cheapest stable mechanism/boundary that can prove or enforce it?
3. Is that guarantee already protected elsewhere?

If the answers are weak, keep evidence temporary.

## Use the Founder-to-Feature crystal

When a Crystallized referent exists, derive proof from **acceptance meaning**, not from incidental code structure.

A crystal is working semantic context; it does not need a permanent crystal artifact.

## Bugs and regressions

For a failure:

- preserved accepted behavior failed → likely regression;
- behavior intentionally changed/retired → old evidence may be obsolete;
- test only freezes implementation → reconsider permanence;
- intended meaning unclear → return to Founder-to-Feature;
- harness/environment broken → repair/isolate proof infrastructure.

Do not bend accepted behavior around an obsolete test just to make CI green.

## Consolidation and deletion

Delete or consolidate:

- duplicate proof;
- stale source-text/import assertions without compatibility reason;
- snapshots freezing incidental structure;
- obsolete behavior;
- one-time migration probes after stronger protection exists;
- redundant regressions subsumed by guardrails;
- abandoned fixtures/helpers/docs that no longer own unique durable meaning.

Evidence is institutional memory only when it protects something worth remembering.

## Performance and external reality

Measure performance at realistic scale and boundary when it matters. Prove provider/auth/deployment behavior against the real provider when practical.

Do not claim production or external truth from local mocks.

## Evidence debt

Evidence debt exists when important accepted guarantees have no reliable proof, proof is so brittle it blocks safe change, or competing evidence prevents trustworthy decisions.

Prioritize evidence debt by consequence, not coverage percentage.

## Completion

Evidence work is complete when the objective-level claim has enough justified proof, material contradictions/unknowns are explicit, and temporary evidence has been removed or deliberately promoted.

Green CI alone is not product acceptance.

## Communication style

Keep Evidence Stewardship mostly invisible. Surface only material uncertainty, proof boundaries, contradictions, or permanence decisions.

## Anti-patterns

Do not:

- add tests for coverage theater;
- require TDD universally;
- add a permanent regression for every bug;
- treat tests or docs as unquestionable authority;
- claim external reality from mocks;
- keep probes forever;
- create testing/evidence ledgers by default;
- automate unstable taste judgments merely for objectivity;
- generate documentation because documentation is missing.

## Governing maxim

> **Move from uncertainty to justified confidence at the real claim boundary, then keep only the evidence worth carrying forward.**

View saved version →

---
name: founder-to-feature
description: "Automatically use when development work contains unresolved product meaning: substantial feature ideas, architecture-affecting behavior, workflow redesign, or audit findings that require deciding what should become true. Own Explore → Resolve → Crystallize → Ready for the semantic referent; do not own session state, proof permanence, or implementation mechanics."
---

# Founder to Feature

## Purpose

Founder-to-Feature owns **product meaning**:

> **What should become true?**

Translate natural creator input into implementation-ready meaning without requiring the user to write a PRD or technical contract.

## Ownership boundaries

- Development OS owns present intent, session state, stage validity, authorization, liveness, and handoff.
- Founder-to-Feature owns unresolved product meaning and the Crystallized behavioral contract.
- Specialist Reasoning supplies professional and generative perspective.
- Evidence Stewardship owns proof/permanence.
- Lean Repository Execution owns implementation/delivery.

## Activation

Activate when a materially unresolved decision can change user expectation, product philosophy, ownership, identity, permissions, lifecycle, placement/mental model, ecosystem ownership, or another durable rule.

Do not take over generic observation, known bugs with established behavior, or routine implementation.

## Semantic stages

### Explore

Discover the problem space, desired outcome, Ambition, constraints, and serious representations without prematurely accepting one.

### Resolve

Settle material semantic and technical consequences. Derive engineering implications from accepted product rules instead of asking the user to decide derivable mechanics.

### Crystallize

Reassemble the referent as one coherent product, reconcile specialists, expose material implementation shape, challenge the representation, and compress the result.

If a material contradiction appears, return only the affected lane to Resolve.

### Ready

Ready means the Crystallized referent is coherent enough that competent implementers should not invent conflicting product behavior, substantial referents have survived an appropriate Specialist Reasoning battle test, and no known self-answerable semantic uncertainty is likely to materially change meaning, ownership, architecture, lifecycle, or user expectation.

Ready is semantic confidence, not Build authorization.

## Behavioral delta

For established products, distinguish:

- **Changes** — what becomes newly true.
- **Preserved** — important behavior, philosophy, ownership, identity, or invariants that intentionally remain.
- **Retired** — behavior, assumptions, workflows, or attractive alternative models that intentionally stop being true.

Preserve a retirement reason only when a fresh agent is likely to rediscover the direction or reconstructing the decision later would be expensive.

## Founder correction synthesis

When the founder materially corrects a concrete proposal, ask whether the correction reveals a durable invariant, Ambition, anti-goal, ownership rule, or quality principle.

Promote only genuinely reusable meaning. Do not turn every preference into doctrine.

## Whole-product reasoning: Depth × Breadth × Time

Resolve only dimensions that can materially change the referent:

- **Purpose / Placement / Experience** — outcome, representation, discoverability, journey, empty/failure/recovery states.
- **System** — canonical owners, identity, durable state, permissions/trust, persistence/data safety, concurrency, performance/scale, provider boundaries, operational cost.
- **Lifecycle** — creation, revision, collaboration, migration, recovery, extension, maintenance, archival/deletion, provider evolution, retirement.
- **Ecosystem** — build vs integrate vs hybrid where it changes burden or product control.

Activate Specialist Reasoning rather than embedding every professional discipline here.

## Local authority

Use the smallest relevant current project truth. History is evidence; current owned project truth is specification.

When authority is degraded, let Development OS reconstruct mechanics first. If product purpose or intended behavior remains non-derivable, ask the founder for minimum grounding rather than inferring mission from code shape.

## Deep semantic resolution

Resolve only material:

- **Owners** — canonical owners and any necessary projections/caches/provider-owned state.
- **Identity** — which users/accounts/objects/projects/revisions/sessions are actually the same or different thing.
- **Invariants** — the few truths that must survive implementation changes.
- **Transitions** — state changes capable of changing user expectation.
- **Failure/destructive semantics** — partial success, retry, recovery, irreversibility.
- **Acceptance meaning** — what must observably be true at the product-claim level.

Prefer one native owner. Do not add parallel authorities for convenience.

## Founder decision vs engineering consequence

Ask the founder only for non-derivable product choices. Derive engineering consequences from accepted meaning.

Do not make the founder choose import paths, schema mechanics, retry plumbing, or similar implementation details unless those mechanics materially change product meaning or risk.

## Adversarial reasoning

Challenge transitions and assumptions that can materially change meaning, safety, ownership, lifecycle, or recoverability. Stop when additional cases produce no materially new information.

## Crystallization pass

Before Ready:

1. **Reassemble the whole.** Review the behavioral delta and material product/system/lifecycle/ecosystem choices.
2. **Expose implementation shape.** Surface material language/runtime/framework, repository/package, persistence/authority, provider/tool, deployment/hosting, automation/distribution, credential/permission choices—and intentional absence.
3. **Challenge scope.** Ask whether concepts can disappear, merge, become native, or remain external.
4. **Require serious alternatives when design-sensitive.** Reconcile at least one materially different representation generated independently by Specialist Reasoning when such divergence could improve the outcome.
5. **Battle-test completeness.** Ask Specialist Reasoning to attack the candidate across the smallest sufficient set of material consequence layers. Current-referent omissions return only the affected lane to Resolve; supported out-of-referent findings may be durably routed without takeover.
6. **Future-maintainer test.** What will a capable maintainer wish had been decided now?
7. **Fresh-outsider test.** What contradictions, duplicate owners, unexplained concepts, or needless complexity remain?

The goal is not novelty for novelty's sake. Serious alternatives must return to the accepted objective and survive professional evaluation.

## The crystal

When Crystallization passes, compress the referent into:

- **Outcome**
- **Ambition** when material
- **Changes**
- **Preserved**
- **Retired**
- **Product shape**
- **System shape**
- **Implementation shape**
- **Lifecycle**
- **Ecosystem choice**
- **Acceptance meaning**
- **Known constraints / bounded unknowns**

The crystal is working context by default, not a new permanent document.

## Authorization reconciliation

Founder-to-Feature never assumes semantic resolution authorizes mutation.

When meaning materially changes inside an authorized Build session:

1. resolve/crystallize only the affected lane;
2. identify the changed referent;
3. return it to Development OS;
4. let Development OS reconcile present intent and standing authorization;
5. obtain current commitment when the changed referent is not clearly covered.

## Build handoff

After Ready and valid scoped Build authorization:

- hand the behavioral delta/crystal to Development OS + Lean;
- carry forward material specialist obligations;
- let Evidence Stewardship choose proof;
- preserve implementation freedom inside the accepted contract.

If Build exposes a genuinely unresolved product question, return only that question.

## Anti-patterns

Do not:

- convert audits into requirements automatically;
- make every ambiguity a founder question;
- treat existing implementation representation as product intent;
- let tests decide unresolved meaning;
- preserve every brainstorm or rejected idea;
- use professional convention as a ceiling on project-native opportunity;
- treat Crystallization as ceremonial summary;
- treat Ready as Build authorization;
- implement changed meaning under stale authorization.

## Governing maxim

> **Resolve what should become true deeply enough that implementation cannot invent the product, while deliberately considering stronger representations before commitment.**

View saved version →

---
name: lean-repository-execution
description: "Automatically use for authorized implementation, debugging, refactoring, repository/provider operations, verification, and delivery. Own orientation, canonical-owner changes, mutation integrity, execution cadence, verification cadence, recovery, provider operations, and completion while relying on Development OS for intent/authorization and Evidence Stewardship for proof permanence."
---

# Lean Repository Execution

## Purpose

Lean owns **execution**:

> **How do we change the exact authorized referent efficiently, coherently, and safely?**

It is project-neutral. Project-local source, instructions, provider rules, branch policy, CI, and release mechanics supply the execution environment.

## Ownership boundaries

- Development OS owns present intent, current referent, stage, authorization, liveness, and handoff.
- Founder-to-Feature owns unresolved meaning.
- Specialist Reasoning owns perspective/representation challenge.
- Evidence Stewardship owns proof choice and permanence.
- Lean owns execution mechanics, mutation integrity, verification cadence, and delivery.

> **Deliver the approved outcome with the least process that protects correctness and the actual risk boundary.**

## Startup

Before substantial mutation:

1. confirm Development OS says the current referent/action class is authorized;
2. inspect project/repository instructions and current branch/provider state;
3. identify the accepted behavioral delta/crystal when one exists;
4. identify canonical owners and affected boundaries;
5. identify local verification/delivery rules;
6. use trusted project intelligence/tools when they materially reduce rediscovery;
7. carry forward material specialist obligations.

Do not infer mutation authorization from an old roadmap or action verb alone.

## Orient once, re-anchor when reality changes

Read the smallest trustworthy slice needed:

- project/agent instructions;
- affected owners/interfaces;
- relevant living contracts;
- current source/ref/provider state;
- external provider/framework guidance where material;
- only necessary history.

Reuse orientation until ancestry, authority, ownership, provider state, affected scope, or authorization referent changes.

When Development OS marks authority degraded, preserve clues and reconstruct enough truth before cleanup.

## Risk and consequence

Use local risk models when present. Otherwise distinguish roughly:

- **Routine** — narrow reversible changes.
- **Product** — user behavior, data models, compatibility, meaningful refactors.
- **High consequence** — auth, privacy/security, billing, destructive/irreversible persistence, production migration, legal/binding provider state.

Risk changes proof, recovery, rollout, and approval—not ceremony for its own sake.

## One coherent objective

Use one coherent implementation stream by default.

Split only at genuinely independent ownership or rollout/revert boundaries.

Do not broaden the active referent merely because adjacent cleanup exists.

## Canonical owner first

When changing behavior:

- find the native/canonical owner;
- fix the owner rather than symptoms;
- avoid parallel ownership/workarounds;
- retire superseded active paths when parity and accepted meaning justify it.

Capability growth should not require concept-count growth at the same rate.

## Native-first external boundaries

When touching external providers/frameworks:

1. inspect current official/native behavior when needed;
2. identify the concrete project need native behavior cannot satisfy;
3. prefer native capability where it satisfies the requirement;
4. add custom abstraction only for a real product/operational boundary.

Do not recreate provider functionality merely for control.

## Cohesive implementation

Implement the complete current referent, not a succession of model-visible microtasks.

Batch predictable mechanical work. Keep intermediate implementation freedom inside the accepted contract.

## Mutation integrity and recovery

For substantial multi-step mutation:

- know the last authoritative committed/ref/provider state;
- prefer atomic/coherent writes where supported;
- distinguish local/intermediate objects from published authority;
- never claim publication until the intended branch/ref/provider state moved;
- after interruption/ambiguous response, re-read authority before retrying;
- avoid replaying destructive/non-idempotent operations blindly;
- preserve recoverable authored work before cleanup/reset.

Tool failure is not product failure when project truth remains clear.

### Repository recovery execution

When repository recovery itself is authorized:

- recover truth before reorganizing structure;
- establish/consolidate one canonical owner at a time;
- preserve evidence needed to distinguish active from abandoned paths;
- delete stale/duplicate implementation and docs only after their unique durable meaning is reconciled;
- stop when the repository has a trustworthy canonical spine, not when every aesthetic imperfection is gone.

## New meaning during Build

If implementation exposes a genuinely unresolved product question:

1. stop only the affected semantic lane;
2. return it through Development OS to Founder-to-Feature;
3. keep independent authorized work moving when safe;
4. after resolution, let Development OS re-evaluate present intent and authorization.

A broad refactor/hardening authorization does not automatically authorize new ownership, permission, identity, economics, placement, or product philosophy.

## Agent and worker use

Do not fan out by default.

Use independent workers for independent investigation, specialist review, materially cross-owner review, or isolated implementation lanes after semantic freeze.

Do not parallelize workers that can invent conflicting shared abstractions or product semantics.

## Verification budget

Lean owns when/how often checks run; Evidence Stewardship owns what proof is appropriate and what survives.

Honor Development OS Evidence Appetite.

Rerun checks only after relevant change or changed external state. Prefer one coherent final/full gate over repeated model-tool-model crossings.

## Evidence permanence

Apply Evidence Stewardship automatically. Temporary proof normally disappears; stable high-value guarantees may earn durable protection.

Do not create permanent tests/docs merely because they helped implementation.

## Loop breaker

Stop repeated checking when no relevant state changed or the next result cannot materially change the decision, implementation, proof, or confidence.

Take the smallest available action that can answer the real unanswered question. Batch predictable operations.

## Debugging

For established bugs:

1. reproduce at the smallest useful boundary;
2. identify the violated accepted guarantee;
3. localize the canonical owner;
4. fix the owner;
5. prove the guarantee at the appropriate level;
6. decide whether recurrence deserves durable protection.

If expected behavior is unclear, route that meaning question rather than letting old tests/code decide it.

## Provider and production operations

For consequential external mutation:

- establish current state;
- identify the native operation;
- make the minimum approved mutation;
- verify once at the real boundary;
- preserve rollback/recovery where relevant;
- obey project-local approval/release gates.

## Review

Review the coherent candidate for:

- fidelity to accepted meaning;
- duplicate ownership/leftover legacy;
- concurrency/idempotency/provider mistakes;
- needless complexity or maintainability regression;
- evidence that freezes implementation instead of guarantees;
- local proof being overclaimed as product acceptance;
- methodology-driven ceremony with no decision value.

Do not turn review into a new product workshop without new evidence.

For substantial or high-consequence candidates approaching acceptance, reactivate Specialist Reasoning for a pre-Accept battle test of the built reality. Evidence Stewardship validates material findings. Resolve supported in-referent defects before acceptance; route supported out-of-referent obligations to the native work system when authorized without expanding the execution referent.

## Completion and delivery

Before calling execution complete:

- the current authorized referent is implemented;
- important behavior has appropriate proof;
- temporary probes are removed or deliberately promoted;
- obsolete evidence/paths are retired when required;
- provider/production proof is complete where needed;
- unresolved material risk is explicit;
- material battle-test findings are resolved in-scope or durably routed out-of-scope;
- durable product meaning is reconciled into living owners when it changed;
- authoritative branch/ref/provider state matches the claim.

Follow the project's actual PR/review/preview/release process. Do not invent generic gates.

## Reporting

Report only meaningful finding, blocker, founder decision, approval boundary, material scope/risk change, or completion.

Development OS owns the process-position surface. Lean returns execution facts into it rather than inventing a parallel status format.

## Anti-patterns

Do not:

- rediscover unchanged context;
- create status/process files by default;
- split one coherent change into needless PR chains;
- fan out workers without independent value;
- ask again for routine permission already granted;
- silently widen the referent;
- treat intermediate artifacts as publication;
- blindly retry ambiguous provider operations;
- keep checking unchanged state;
- use a live frontier to justify low-yield work;
- equate tests with product authority;
- reopen settled meaning without evidence.

## Governing maxim

> **Execute the exact authorized referent coherently, change canonical owners rather than symptoms, and preserve authoritative state through interruption and delivery.**

View saved version →

---
name: specialist-reasoning
description: "Automatically use when professional perspective or materially different representations could improve software/product work. Select the smallest sufficient professional team, reason independently before synthesis, distinguish evidence from inference, deliberately diverge before convergence on substantial conceptual work, and return only findings that materially change the owning workflow."
---

# Specialist Reasoning

## Purpose

Specialist Reasoning owns **perspective**:

> **What are we failing to see, and what else could this be?**

Its purpose is useful cognitive diversity without persona theater or committee process.

## Ownership boundaries

- Development OS decides when perspective is needed and keeps the overall work anchored.
- Founder-to-Feature owns product meaning.
- Specialist Reasoning owns professional perspective, independent analysis, generative divergence, representation challenge, and synthesis.
- Evidence Stewardship owns proof/permanence.
- Lean owns worker/tool coordination during Build.

Real project/domain evidence outranks simulated expertise.

## Activation

Activate when perspective could materially change value, mental model, architecture, reliability, security/privacy, operations, economics, adoption, acceptance, or domain correctness.

Routine bounded fixes usually need no virtual team.

## Smallest sufficient professional team

Select only professional disciplines that can materially change the objective.

Typical core perspectives when relevant:

- Product strategy / management
- User research / behavioral understanding
- Product / interaction design
- Technical architecture / staff engineering
- Quality / reliability

Add experience, risk, business, operations, developer-experience, legal, or domain perspectives only on a real trigger.

> **Use the smallest sufficient professional team and the smallest useful diversity of thought.**

Load specialist reference files only when they materially help.

## Independent-first reasoning

Do not blend every discipline into a generic checklist.

Give each activated professional function a short independent pass over:

- opportunity;
- risk;
- unsupported assumption;
- blocker/decision;
- success signal.

A professional perspective may conclude it has no material finding.

## Evidence, hypothesis, inference

Distinguish:

- **Observed / externally supported**
- **Project-derived**
- **Founder hypothesis**
- **Model inference**
- **Generative hypothesis**

Professional reasoning is not evidence by itself. Research current authoritative sources when a high-stakes or changing external fact materially determines the conclusion.

## Cross-functional disagreement

Surface only disagreements that materially change the objective or contract. Resolve internally when project truth/evidence is sufficient; ask the founder only when materially valid alternatives remain.

Productive disagreement matters more than role count.

## Worth-building and countercase

For substantial new capability, pressure-test whether it deserves complexity:

- What need/outcome justifies it?
- What simpler alternative solves enough?
- What opportunity cost does it create?
- What evidence argues against building it?

## Generative divergence

Professional reasoning establishes the floor; it must not define the ceiling.

For substantial Explore or Crystallize work, before declaring saturation, deliberately generate a small set of materially different representations when doing so could improve the outcome.

At least one serious alternative should originate independently of both the founder's proposed solution and the current implementation when the problem admits meaningful representation choice.

> **Bad hypotheses are allowed during divergence; bad conclusions are not.**

Useful lenses:

- **Simplifier** — what can disappear, merge, become one owner, or become native?
- **Enhancer** — what existing capability or small design change materially amplifies the same objective?
- **Productive ignorance / naive outsider** — what obvious, dumb, category-confused, or seemingly impossible question exposes an assumption?
- **Inversion** — what if ownership, flow, control, or responsibility ran the opposite direction?
- **Analogy transfer** — how would a mature unrelated domain represent this shape of problem?
- **Constraint experiment** — what does forbidding a database/dashboard/second owner/background system reveal?
- **Architectural runway** — what probable future need has high later migration cost but a cheap neutral seam today?

These are reasoning lenses, not fictional professionals and not accepted meaning.

## Scope discipline and elasticity

Specialists operate for the accepted objective, but the accepted objective is not automatically the accepted representation.

> **Leave the frame when needed; do not lose the objective.**

A perspective may inspect beyond the current component, abstraction, or feature boundary when doing so can reveal the real cause or a materially better representation. It must return with demonstrated relevance.

Classify discoveries:

- **Required for the objective** — analyze now.
- **Adjacent but nonessential** — note/route without expanding the active referent.
- **Systemic cause of the objective** — inspect far enough to establish it; route wider cleanup separately unless recovery itself is the objective.
- **Would redefine product intent** — surface to Founder-to-Feature.

Do not use scope discipline to suppress materially better architecture. Do not use innovation to justify unrelated redesign.

## Battle testing

Battle testing is a deep adversarial completeness pass over a candidate conclusion, contract, architecture, document, or implementation.

> **Attack the result across the smallest sufficient set of consequence layers until additional attacks stop revealing material omissions, contradictions, unsafe assumptions, or stronger representations.**

Battle testing is not a generic checklist and not synonymous with exhaustive evidence. Select only layers capable of changing the result, such as:

- meaning and reachable states;
- representation and abstraction;
- ownership and authority;
- lifecycle, migration, deletion, and retirement;
- failure, interruption, recovery, and rollback;
- permissions, trust, identity, and external boundaries;
- scale, time, cost, and operational burden;
- human comprehension, misuse, recovery, and accessibility;
- maintenance and fresh-context legibility;
- external legal/provider/standards reality when materially relevant.

Use materially different attack directions where useful:

- **Omission** — what necessary dimension is absent?
- **Contradiction** — what accepted statements cannot both remain true?
- **Reachability** — what valid sequence reaches an unresolved state?
- **Misuse/adversary** — what happens under error, abuse, or unexpected use?
- **Change over time** — what breaks after migration, provider change, growth, or organizational change?
- **Failure/recovery** — can partial or damaged states recover coherently?
- **Authority/dependency** — what must be true externally, and are we merely assuming it?
- **Fresh outsider** — what would a capable newcomer question that insiders stopped seeing?

For substantial Crystallize work, battle-test before declaring Ready. For substantial or high-consequence implementation near acceptance, battle-test the built reality again because a strong contract does not prove the delivered system.

Battle testing generates hypotheses and findings; Evidence Stewardship determines which are supported enough to affect the active referent or earn durable routing.

## Transformative synthesis

After professional passes and divergence, synthesize only ideas that could materially improve the work.

Ask especially:

- What is everyone assuming?
- Which constraint is merely historical?
- What could disappear rather than be improved?
- Which separate problems become simpler when modeled together?
- What project-native capability is underused?
- If the current solution did not exist, would we invent it this way?
- Are we improving an abstraction because it deserves to exist or because it already exists?
- Is there a cheap seam now that avoids an expensive likely migration later?

Evaluate generated alternatives professionally before returning them to the owning workflow.

## Internal vs multi-agent mode

Default to internal separated reasoning passes.

Use independent agents/subagents only when real independence adds value for substantial or high-consequence work. Do not create permanent agents per profession.

## Output to the owning workflow

Return a compact synthesis:

- relevant professional team;
- material opportunities/risks;
- unsupported assumptions and evidence status;
- meaningful conflicts and battle-test omissions;
- serious representation alternatives/simplifications;
- contract implications;
- irreducible founder decisions.

Do not create permanent specialist reports by default.

## During Build

Reactivate when implementation reveals a newly material professional/domain risk or representation problem that could invalidate the accepted referent, and for a pre-Accept battle test on substantial or high-consequence candidates. Return bounded findings; do not take over execution.

## Saturation

Stop when:

- the sufficient professional team covered material risk/opportunity;
- serious generative alternatives were considered where representation mattered;
- substantial candidates were battle-tested across the material consequence layers;
- further perspectives/alternatives/attacks are unlikely to change the objective or quality;
- remaining uncertainty belongs to evidence, founder decision, bounded implementation freedom, or human taste.

Repeated founder rescue after saturation is evidence that divergence was too weak.

## Anti-patterns

Do not:

- turn roles into personas;
- load every profession;
- manufacture findings;
- treat inference as user/external evidence;
- create permanent specialist specifications;
- make scope so tight that the real cause/stronger representation cannot be discovered;
- let generative hypotheses become conclusions without professional evaluation;
- generate novelty merely to appear creative;
- optimize inherited abstractions without asking whether they should exist.

## Governing maxim

> **Establish a professional floor, diverge beyond the inherited frame, battle-test the candidate across material consequence layers, and converge only on conclusions that survive relevance, evidence, and professional scrutiny.**

Referenced files: 3