---
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.**