ic1558/stack-engineer

stack-engineer

Purpose

Use this skill when a system lane, prototype, partial implementation, or abandoned work needs to be located, classified, continued, rebuilt, promoted, parked, or archived without causing architecture drift.

This skill is for continuation engineering inside the 0luka stack.

It is not for broad redesign.

---

Core Goal

Turn unclear or unfinished system work into exactly one of these truthful outcomes:

1. recover
2. re-implement
3. promote
4. park
5. archive

The decision must come from repo truth, runtime truth, and bounded evidence, not from guesswork.

---

Mandatory Pre-Read

Before using this skill for any real 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

Do not begin execution planning before these are read.

If this pre-read does not happen, the skill must treat itself as not fully initialized for governed 0luka work.

---

When To Use

Use this skill when at least one is true:

• source exists but looks placeholder-only
• runtime behavior exists but repo truth is weak or missing
• code appears lost but pseudo-code or blueprint still exists
• prototype exists in sandbox/R&D but lacks promotion path
• local dev and canonical repo disagree
• a lane was partially completed and now needs safe continuation
• repo truth and runtime truth disagree
• old work may still have value but its stack position is unclear

---

When Not To Use

Do not use this skill when:

• the task is simple greenfield coding with no stack ambiguity
• the task is purely UI polish
• the task is broad architecture redesign
• the user already gave a fully locked implementation spec and only wants direct execution
• the work is unrelated to continuation, recovery, promotion, or stack placement

---

Operating Mindset

Think like a continuation engineer, not a general architect.

That means:

• locate what truly exists
• separate source from artifact
• separate blueprint from runnable code
• separate runtime truth from repo truth
• choose the smallest correct path forward
• avoid widening the lane
• preserve stack boundaries

---

Stack Boundary Rules

Always preserve these distinctions where relevant:

• local runtime vs cloud ingress
• deterministic engine vs external reference
• repo truth vs runtime truth
• blueprint vs source
• prototype vs production
• producer vs consumer
• support layer vs execution engine
• canonical repo vs local orphan/dev work

Never fuse layers just because they are related.

---

Primary Workflow

Step 1 — Locate

Find all relevant surfaces.

Check at least:

• canonical repo surfaces
• active branches/worktrees if relevant
• local dev directories
• sandbox/R&D paths
• runtime artifacts
• inbox/receipts/results/state surfaces
• archive/backup paths if grounded
• blueprint/pseudo-code/notes if source is missing

Return exact paths only.

Step 2 — Classify

Classify each surface as one of:

• active_runtime
• repo_truth
• prototype
• placeholder
• blueprint
• artifact_only
• deprecated
• dead_paper
• archive_only

Also classify the work state as one of:

• recoverable_from_source
• reimplement_only
• promotion_candidate
• parked
• archive_candidate

Step 3 — Decide

Choose exactly one primary continuation path:

• Recover
  • runnable source exists and should be restored
• Re-implement
  • source is gone but blueprint is sufficient
• Promote
  • prototype exists and should move into active repo truth
• Park
  • valuable, but not the correct next lane
• Archive
  • no safe or worthwhile forward path

Do not casually mix these.

Step 4 — Bound

Define:

• exact scope
• exact files/surfaces in scope
• exact files/surfaces out of scope
• what boundary must not be crossed
• what architecture must remain separated

If scope is not bounded, the skill has failed.

Step 5 — Build Promotion or Continuation Path

If work should continue, define the exact chain:

• prototype -> bounded rebuild
• bounded rebuild -> proof
• proof -> merge
• merge -> consumer/rollout

If work should not continue, define exact park or archive reason.

Step 6 — Proof Standard

End with one of:

• exact proof path
• exact blocker
• exact parked reason
• exact archive reason

No vague ending.

---

Recovery vs Re-Implementation Rules

Recover

Use recover only if runnable source actually exists in:

• git history
• branch
• worktree
• stash
• backup
• other grounded local surface

Re-Implement

Use re-implement if:

• source is gone
• only pseudo-code/plan/artifacts remain
• bounded reconstruction is still possible

Never Mislabel

If the code was recreated from notes, plans, pseudo-code, or artifacts, that is re-implementation, not recovery.

---

Promotion Rules

Promote only if all are true:

• the work still has value
• stack position is correct
• it does not violate boundary separation
• the lane can be bounded
• proof can be produced

Do not promote:

• sandbox-only experiments without a consumer path
• stale prototypes with unclear authority
• external reference systems into a deterministic core engine
• broad concepts with no bounded next lane

---

Re-Implementation Rules

When rebuilding from blueprint:

• use grounded blueprint inputs only
• rebuild the smallest executable slice first
• preserve deterministic behavior if the original intent was deterministic
• prove input -> output behavior
• state what remains unreimplemented

Do not rebuild the whole system unless the blueprint is unusually complete and the lane explicitly allows it.

---

Repo Truth Closeout Rules

For any lane touching repo truth:

• distinguish branch truth from main truth
• distinguish worktree artifacts from merged artifacts
• verify exact merged scope
• reject inflated claims
• state exactly what is:
  • created
  • updated
  • already satisfied on main
  • skipped with reason

If main verification is missing, say so explicitly.

---

Output Format

Return only:

1. current state
2. exact surface classification
3. continuation decision
4. why
5. bounded next lane
6. exact proof or exact blocker

---

Definition of Done

This skill is done only when it produces:

• exact surface inventory
• truthful classification
• one clear continuation decision
• one bounded next lane or explicit park/archive
• no architecture drift
• no fake recovery language
• no vague summary without actionability

---

Failure Modes To Avoid

• treating placeholder code as real code
• treating artifacts as source
• calling re-implementation recovery
• widening into redesign
• promoting sandbox code too early
• assuming runtime truth from repo files alone
• assuming repo truth from runtime success alone
• mixing two lanes into one
• skipping pre-read of AGENTS.yaml / CONTRACT.yaml

---

Good Example Outcomes

Example A — Recover

Runnable code is found in an old branch, restored into the intended source surface, and verified.

Example B — Re-Implement

Runnable source is gone, pseudo-code exists, minimum deterministic slice is rebuilt and proven.

Example C — Promote

A sandbox prototype has value and a correct stack position, so it is promoted through a bounded lane with proof.

Example D — Park

Work is real and useful but not the correct next lane, so it is preserved and explicitly parked.

Example E — Archive

No runnable source, no viable blueprint, and no clear value remain, so it is archived and removed from active consideration.

---

Short Operating Principle

Do not ask:

What should we build?

Ask:

What already exists, what class is it, and what is the smallest truthful next step?

End of Document