ic1558/bounded-repo-executor

bounded-repo-executor

Purpose

Use this skill when the task is already bounded by a Work Order or explicit lane definition and the job is to execute, verify, close out, or report repo truth without widening scope.

This skill is for disciplined execution.

It is not for broad design or architecture invention.

---

Core Goal

Take a bounded repo task and drive it to one of these honest outcomes:

1. PASS
2. PARTIAL
3. FAIL

The result must be grounded in:

• exact files
• exact diff
• exact proof
• exact blocker

No inflated claim is allowed.

---

Mandatory Pre-Read

Before using this skill on a governed 0luka lane:

1. read /Users/icmini/0luka/core_brain/governance/AGENTS.yaml
2. read /Users/icmini/0luka/CONTRACT.yaml
3. read /Users/icmini/0luka/skills/manifest.md

If a lane-specific WO or protocol exists, read that before taking action.

Do not begin execution from memory alone.

---

When To Use

Use this skill when:

• a WO already defines scope
• the lane is narrow and implementation-ready
• a bounded fix is needed
• exact merge/closeout verification is needed
• exact repo-truth check is needed
• the task requires minimal-diff execution
• the problem is not “what should we do,” but “do the scoped thing now”

---

When Not To Use

Do not use this skill when:

• the lane is still conceptually undefined
• the work requires architecture arbitration first
• the task is broad research without execution boundary
• the best next move is classify/recover/reimplement/promote/park/archive first
• the request actually belongs to stack-engineer or blueprint-specialist

---

Operating Mindset

Think like a bounded engineer, not a strategist.

That means:

• execute the WO as written
• keep the diff narrow
• return proof or exact blocker
• avoid adding “helpful” extra work
• distinguish branch/worktree truth from main truth
• never replace execution with commentary

---

Execution Law

If all are true:

• scope is explicit
• authority boundary is clear
• no new blocker exists
• safety base exists

then default behavior is:

think -> decide -> execute

not:

think -> explain -> wait

---

Primary Workflow

Step 1 — Read and lock scope

Extract from the WO:

• exact objective
• exact files/surfaces in scope
• exact out-of-scope areas
• DoD
• proof requirements

Rewrite scope mentally into a narrow execution boundary. Do not improvise beyond it.

Step 2 — Check execution safety

Before mutation, verify:

• branch/worktree is safe enough
• dirty files outside lane will not contaminate the diff
• main truth vs local/worktree truth is understood
• merge/verification target is explicit

If unsafe:

• report exact blocker
• do not proceed blindly

Step 3 — Execute minimally

Perform only the smallest changes required to satisfy the WO.

Rules:

• no broad cleanup
• no opportunistic refactor
• no redesign
• no side quests
• no unrelated fixes “while here”

Step 4 — Produce proof

At minimum produce:

• exact files changed
• exact proof path
• exact artifacts if any
• exact result against DoD

If proof is missing, the lane is not PASS.

Step 5 — Report exact truth

Truth must distinguish:

• created
• updated
• already satisfied on main
• skipped with exact reason
• missing
• not verified on main
• verified on main

Never claim:

• full completion if only partial diff exists
• main truth if only worktree truth exists
• repo truth if only runtime artifact exists

Step 6 — Merge / closeout if in scope

If the WO includes closeout:

• verify diff isolation
• verify PR scope
• verify merge
• verify main if possible
• close with exact merged truth only

---

Scope Discipline Rules

Always preserve these:

• one lane only
• one objective only
• minimal diff only
• exact DoD only

Not allowed:

• converting a narrow lane into a broad initiative
• opening new sub-lanes inside the task
• adding features beyond the WO
• creating meeting/design detours
• rephrasing a blocker into fake progress

---

Proof Rules

A lane is PASS only if:

• the scoped work is actually done
• proof exists
• the returned summary matches actual diff/artifacts
• no contradiction exists between report and repo truth

PARTIAL if:

• some bounded progress exists
• but DoD is not fully met
• or main verification is missing
• or proof is incomplete

FAIL if:

• scope is not met
• proof contradicts the claim
• blocker prevents execution
• the lane report was inflated

---

Main Truth Rules

This skill must explicitly distinguish:

Worktree truth

What exists only in the current working copy or branch

Branch truth

What exists in the PR branch but not on main

Main truth

What exists on refs/heads/main or refs/remotes/origin/main

Never collapse these into one.

If main ref cannot be verified directly, say so. Do not fake VERIFIED-ON-MAIN.

---

Closeout Rules

For closeout tasks, return exact disposition only:

• files created
• files updated
• already satisfied on main
• skipped with reason
• PR
• merge commit
• main verified = yes/no
• final status

If a prior claim was inflated, correct it directly. Do not preserve old wording for politeness.

---

Blocker Rules

A real blocker must be one of:

• authority conflict
• safety/truth conflict
• missing source/input required by WO
• missing main-ref verification path when that is required
• dirty worktree contamination that would falsify repo truth
• failed proof against DoD

Not blockers:

• mild uncertainty that can be checked
• desire for broader elegance
• temptation to redesign
• discomfort with committing to a bounded next step

---

Output Format

Return only:

1. files created/changed/verified
2. exact scope achieved
3. exact proof path
4. exact repo/main truth status
5. verdict = PASS / PARTIAL / FAIL
6. blocker if any

---

Definition of Done

This skill is done only when:

• the WO scope is obeyed
• the diff is bounded
• proof exists
• the summary matches reality
• closeout is exact
• no architecture drift occurred

---

Failure Modes To Avoid

• scope widening
• design detour
• recommendation without execution
• inflated completion claim
• reporting worktree truth as main truth
• saying “done” when only part of the batch was touched
• broad cleanup hiding inside a narrow lane
• returning elegant prose instead of exact disposition

---

Good Example Outcomes

Example A — Narrow fix

One bug is fixed, one file changed, one proof artifact returned, PASS.

Example B — Bounded batch closeout

Only some paths needed updates, others were already satisfied on main, final report matches exact repo truth.

Example C — Procedural partial

Feature is proven, but direct main-ref verification is missing, so verdict is PARTIAL not FAIL.

Example D — Honest fail

WO expected 5 files but branch touched 1; report is downgraded to FAIL until scope matches truth.

---

Short Operating Principle

Do not ask:

What else can I improve while I’m here?

Ask:

What is the smallest truthful diff that satisfies this WO and how do I prove it?

End of Document