ic1558/blueprint-specialist

blueprint-specialist

Purpose

Use this skill when runnable source code is missing or unusable, but enough grounded blueprint material exists to re-implement a bounded executable slice safely.

This skill is for truthful reconstruction from:

• pseudo-code
• plans
• action notes
• formulas
• artifacts
• preserved behavior clues

This skill is not for pretending recovery happened when source is gone.

---

Core Goal

Produce a bounded, executable, non-placeholder rebuild from grounded blueprint materials.

The only valid end states are:

1. rebuild proved
2. rebuild partial
3. rebuild blocked

---

Mandatory Pre-Read

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

Do not begin execution planning before these are read.

---

When To Use

Use this skill when one or more are true:

• real source code is missing
• current source is placeholder-only
• artifacts show the system once existed
• pseudo-code or implementation plans remain
• deterministic behavior needs to be rebuilt from notes
• recovery from git/history/local source has failed
• bounded re-implementation is possible from grounded blueprint

---

When Not To Use

Do not use this skill when:

• runnable source still exists and can simply be recovered
• the task is broad greenfield design
• the blueprint is too vague for bounded reconstruction
• the task is unrelated to reconstruction from blueprint
• the request is really an integration or architecture-expansion lane

---

Non-Negotiable Language Rule

If runnable source is gone and the implementation is recreated from notes, pseudo-code, plans, or artifacts:

• call it re-implementation
• do not call it recovery

Recovery is only valid if real runnable source is actually restored.

---

Required Inputs

At least one grounded source must exist:

• pseudo-code
• implementation plan
• formulas/specs
• prior output artifacts
• design notes
• file map
• execution traces
• deterministic expected behavior

If none exist, return:

• FAIL / blueprint insufficient

---

Operating Mindset

Think like a forensic rebuilder.

That means:

• derive from grounded blueprint
• preserve the intended deterministic behavior
• rebuild the smallest useful executable slice first
• do not widen into redesign
• state uncertainty explicitly
• prove non-placeholder behavior

---

Primary Workflow

Step 1 — Confirm rebuild precondition

Verify all of the following:

1. real source is missing or unusable
2. blueprint material exists
3. bounded rebuild is possible
4. there is a meaningful target surface for rebuilt code

Return exact evidence for each.

Step 2 — Inventory blueprint sources

List all grounded reconstruction inputs.

Classify each as:

• primary_blueprint
• secondary_support
• artifact_evidence
• context_only

Prefer direct pseudo-code over loose surrounding notes.

Step 3 — Define the minimum rebuild slice

Choose the smallest slice that proves the system is no longer placeholder-only.

This slice must be:

• executable
• bounded
• meaningful
• architecture-safe

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

Step 4 — Map blueprint to target files

For each intended target file, state:

• why the file is needed
• which blueprint source drives it
• what logic will be implemented there
• what is explicitly not included yet

This mapping step is mandatory.

Step 5 — Re-implement

Write real bounded code only for the chosen slice.

Rules:

• deterministic first
• no LLM logic inside the core
• no speculative add-ons
• no architecture fusion
• no placeholder substitution that merely looks cleaner

Step 6 — Prove non-placeholder behavior

Proof must show actual input -> output behavior.

At minimum prove:

• the code runs
• it performs meaningful blueprint-derived logic
• it does not exit as a stub/placeholder
• output is reproducible for bounded test input

Step 7 — State what remains unreimplemented

Be explicit about:

• what this rebuild covers
• what remains missing
• what next lane would be needed if expansion is desired

Do not imply full restoration if only a bounded slice was rebuilt.

---

Reconstruction Source Hierarchy

Prefer blueprint sources in this order:

1. exact pseudo-code for target logic
2. implementation plan naming functions/components
3. artifacts showing prior behavior
4. surrounding design/context notes
5. related but non-authoritative references

If sources conflict:

• prefer the most direct blueprint for the bounded slice
• report the conflict explicitly
• do not silently blend contradictory versions

---

Determinism Rules

If the original intent is deterministic, the rebuild must preserve that.

For deterministic rebuilds:

• inputs must be explicit
• formulas/logic must be explicit
• outputs must be reproducible
• opaque inference must not enter the core

If uncertainty exists:

• report it
• do not improvise silently

---

Boundedness Rules

Allowed:

• one minimum executable slice
• one clear proof path
• minimal supporting test or verifier

Not allowed:

• whole-system redesign
• unrelated feature expansion
• UI/report/dashboard buildout
• external reference merge
• cloud/control-plane additions
• “while we are here” scope growth

---

Output Format

Return only:

1. blueprint files used
2. exact target files rebuilt
3. exact files changed
4. what bounded slice was rebuilt
5. exact deterministic proof
6. what remains unrebuilt
7. verdict = PASS / PARTIAL / FAIL
8. blocker if any

---

Definition of Done

This skill is done only when:

• exact blueprint sources are identified
• a bounded executable slice is rebuilt
• runnable code exists in the intended target surface
• proof demonstrates non-placeholder behavior
• the work is honestly described as re-implementation
• remaining unreimplemented scope is explicit
• no architecture drift occurred

---

Failure Modes To Avoid

• calling blueprint rebuild recovery
• rebuilding too much at once
• inventing missing logic beyond grounded sources
• replacing one placeholder with another
• proving only compile/import, not behavior
• omitting what remains missing
• merging unrelated systems into the rebuild

---

Good Example Outcomes

Example A — Bounded deterministic rebuild

Pseudo-code exists, source is gone, minimum engine slice is rebuilt and proven with explicit inputs/outputs.

Example B — Artifact-backed rebuild

Old outputs exist, formulas survive in notes, rebuild reproduces the bounded expected behavior.

Example C — Honest partial

Core slice is rebuilt, but scanner/runner/integration layers remain unrebuilt and are explicitly listed as next-lane work.

Example D — Blueprint insufficient

Notes are too vague, no trustworthy formulas remain, so the skill returns FAIL instead of hallucinating a rebuild.

---

Short Operating Principle

Do not ask:

How do I recreate the whole missing system?

Ask:

What is the smallest truthful executable slice I can rebuild from the blueprint and prove now?

End of Document