Wincreator

WinCreator — Hierarchical Engineering Loops with Proof Gates

Why this skill exists

Every agent-assisted engineering session degrades the same three ways, and knowing them is the key to using this skill well:

1. Optimism leak — the same context that wrote the code grades its own work, and "it should work" quietly becomes "it works".
2. Context rot — constraints stated early get lost as the session grows; the agent drifts from the original need without noticing.
3. Stuck loops — a failing check gets re-attacked at the same level again and again, when the real defect lives one level up.

This skill counters each one mechanically, not aspirationally: optimism leak → Proof Ledger + Builder/Skeptic separation; context rot → the Loop Panel; stuck loops → the Two-Failure Rule. Everything else in this file exists to serve those three defenses.

Evidence > Assertion. Truth > Speed. Rigor > Improvisation.

A brainstorming loop diverges: ideas, no obligation of proof. An engineering loop converges: it only reports up after passing a verifiable truth gate — a test actually run, an output actually inspected, a measurement actually taken. Nothing unproven propagates upward. The rigor is structural and domain-agnostic: no language, framework or stack assumed — you translate each proof criterion into the concrete gesture of your domain.

Three tiers — pick one in the first line of the task

Ceremony must be proportional to stakes, or the skill becomes the problem it was built to solve. Announce the tier explicitly; escalate mid-task if the stakes turn out higher, never silently.

If you cannot name why the task needs Standard, it is a Lite task.

When NOT to apply the full hierarchy

Skip the level/gate/ledger ceremony entirely for a trivial single-step change (rename, typo, config value — just do it, with a quick check), a purely explanatory request (nothing is built, nothing needs execution proof), and pure exploration where nothing is decided yet (stay in Exploration mode below). The signal for the full machinery: the task builds, fixes, ships, or audits something whose reliability matters, with multiple steps or multiple plausible ways to go wrong.

Composition with other skills

This skill does not replace specialized skills (debugging, testing strategy, code review): it provides the temporal skeleton — which level, which gate, when to report up — inside which they operate. Use them for the execution; keep this one for the structure and the no-upward-propagation rule.

The 4 loop levels

Classify the task before starting. Never work "flat".

Loop weight: rigor proportional to stakes

Before choosing a gate, classify the weight:

• Exploration — still comparing options: list real options with their real trade-offs; no heavy gate, no frozen decision, no formal document.
• Decision — ready to commit and build on it. Only here does the full Macro gate apply.
• Construction — the implementation itself (Meso/Micro/Nano): a gate is always required, proportional to real criticality.

If ambiguous, one line: "still exploring, or building on a chosen direction?" — a sentence, not a form.

The Loop Panel (defense against context rot)

For any Meso+ task, maintain a compact state block and re-emit it at every gate event (gate announced, passed, failed, level change). Like a cockpit panel or a surgical checklist, its value is repetition: the current truth survives even when session memory degrades or context gets compacted.

[LOOP] level=Meso weight=Construction task="FM export module"
[GATE] full-dataset run + diff vs 3 reference cases
[LEDGER] 2 EVIDENCED / 1 PENDING / 0 CLAIMED / 0 DISPROVEN / 1 WAIVED
[NEXT] builder: implement error path for missing lots

Four lines, never more (a fifth [AUDIT] line appears only after a Two-Failure level audit — see below). WAIVED and DISPROVEN counts are mandatory: debt or a falsified claim that leaves the panel becomes invisible. If you notice the panel contradicting what you were about to do, the panel wins — that contradiction IS the context rot being caught.

Loop gates

Macro (Decision mode) — output: a short written decision, constraints, owned negative consequences, rollback criterion.

• Real alternatives listed, not one option disguised as a choice
• Negative consequences explicitly written, not only benefits
• Consistent with constraints already in place, or justified exception
• A concrete future checkpoint to revisit the decision

Meso — output: the feature integrated, tested end to end, no gap.

• Nominal path AND at least one error path actually executed
• No simulated data presented as final result
• Result matches the need re-read AFTER implementation, not only before
• Honest account of done vs. remaining
• Ledger required at this level and above.

Micro — PLAN (one sentence: what this unit must guarantee) → RED (write the check that must currently fail) → GREEN (minimal real implementation, no simulation) → VERIFY (execute the proof, quote the raw result) → REFACTOR (clean up, then re-verify).

• Proof executed in this session, not assumed
• Proof output inspected in detail, not just "it worked"
• At least one edge case explicitly considered

Nano — one targeted change; never silent, always one immediate real check (compile, lint, quick run).

The Proof Ledger (Meso+ tasks)

A plain markdown table (default PROOF_LEDGER.md) where every claim carries exactly one status:

A falsified claim is evidence too: never delete a DISPROVEN row and never downgrade it to PENDING. Fix the thing and re-prove it, or reformulate the claim in a new row and mark the old one SUPERSEDED.

scripts/ledger_check.py (stdlib-only) exits non-zero if any CLAIMED, DISPROVEN, or INSUFFICIENT row remains, or if a row's evidence does not carry what its status requires. Run it as the final mechanical gate of every Meso loop, and in CI if the project has one. Full spec: references/proof-ledger.md.

Waiting is not a freeze. Before closing a Meso+ loop, re-check every PENDING and BLOCKED row: if the named command can now run or the named blocker has lifted, re-run the gate. ledger_check exit 0 on those statuses means the wait is well-formed, not that the object is still blocked. Documentary claims (counts, versions, paths, surfaces) obey the same law: re-derive them from the object at read time.

Capture first, review second

A hand-written Evidence cell is still a story about a proof. Execute the gate through the capture layer:

python3 scripts/wincreator.py prove P-014 \
  --tier standard --builder builder-01 \
  -- pytest tests/test_export.py -q

Capture produces CAPTURED_PASS, CAPTURED_FAIL, or CAPTURE_ERROR. A pass remains PENDING in Standard/Regulated because exit 0 proves only that the command succeeded, not that the command proves the claim. Review the exact capture separately:

python3 scripts/wincreator.py review P-014 \
  --verdict evidenced --reviewer skeptic-01

Review may record EVIDENCED, INSUFFICIENT, or DISPROVEN. INSUFFICIENT is a first-class blocking ledger status; it cannot be mistaken for an ordinary waiting state. CAPTURED_FAIL can never become EVIDENCED; in Regulated mode the Builder cannot review their own capture. Pass --automatic for CI/tool review and obtain authenticated human sign-off outside the CLI when policy requires it. The capture binds the exact ID, level, claim text and gate, so changing any of them invalidates verify.

Use --file only for mandatory artifacts; a missing file aborts before the gate. Use --optional-file for optional inputs. Protect sensitive output with --redact, --redact-regex, --max-output-bytes, --no-output-body, or --private. The signing key is removed from the gate environment and applied only after the process exits. A Standard capture outside Git warns when it has no --file, because then no source snapshot is bound to the claim. Read references/attestation.md and validate the machine schema at schemas/attestation-v1.schema.json for Regulated work.

Builder/Skeptic separation (defense against optimism leak)

Whoever builds never grades their own gate — segregation of duties, borrowed from financial auditing and aviation.

• Builder — plans, implements. May add ledger rows only as CLAIMED.
• Skeptic — verifies. Receives ONLY the claim, the gate definition, and the raw evidence — never the Builder's reasoning, which contaminates judgment. Its job is to find why the claim is NOT proven. It alone writes ledger statuses.
• Scout (Exploration only) — surveys options without converging.

With subagents (Claude Code, Cowork): spawn the Skeptic as a real subagent using the role prompt in references/agents.md. Without subagents (plain chat): honest degradation — an explicit, labeled "Skeptic pass:" attacking your own claim before writing any status; prefer PENDING over a self-graded EVIDENCED whenever the proof was not directly observed. A Skeptic pass that names no concrete attack is void: "nothing to report" is the optimism leak wearing a Skeptic costume. If no attack can be named, write the strongest reason the evidence might not generalize — there is always one.

The Two-Failure Rule (defense against stuck loops)

If the same gate fails twice, a third identical attempt is forbidden. Stop and run a level audit before touching the code again:

1. Is this the right level? Most stuck Micro loops are misclassified Meso problems (the function can't be fixed because the interface around it is wrong), and stuck Meso loops are often Macro problems. Ask: "would this failure disappear if something one level up were different?"
2. Is the gate itself right? Sometimes the gate tests the wrong thing. Redefining a gate is legitimate ONLY if done openly, before the next attempt, with the reason stated — never retroactively to make a failure look like a pass.
3. Then either escalate to the parent level with what was learned, or retry once with a genuinely different approach — stated as such.
4. Record the audit in one panel line so it is checkable later: [AUDIT] 2 fails at Micro → cause was Meso interface; escalating.

Two failures is data. Six failures is a session wasted on the wrong level.

The no-upward-propagation rule (the heart of the system)

A loop transmits to its parent only what it has proven, never what it hopes.

Refuse actively:

• Declaring a Meso "done" because the Micros "seem" to work
• Over-architecting at Macro to avoid hard Meso work
• Iterating past the Two-Failure Rule without a level audit
• Imposing a full Decision gate during Exploration
• Writing EVIDENCED from the Builder role, or without a raw evidence reference

When proof cannot be executed directly

If the proof was not actually observed, it does not exist — no matter how solid the reasoning seems.

• Execution tool available: use it for real (wincreator prove if the result must survive the session), quote the raw output.
• No tool, or code runs on the developer's machine: give the exact command, ask for the pasted raw result, mark the row PENDING — never "passed" by deduction. If an external dependency makes the gate impossible, name it and mark BLOCKED. If the developer proceeds anyway, record WAIVED with their explicit words: visible debt, never a silent pass.

A skill that claims to enforce proof but lets the AI hallucinate an unobserved verification is worse than no skill: it manufactures false confidence.

The Retro Loop (the skill improves itself)

Every Skeptic INSUFFICIENT verdict is paid-for knowledge. Do not let it evaporate when the session ends:

1. Keep a SKEPTIC_CATCHES.md next to the ledger: one line per catch — what class of gap it was, why the Builder missed it, what question would have caught it earlier.
2. At the start of any Meso+ loop, re-read the catches file (if present) and fold recurring patterns into the gate definition — the gate of loop N+1 inherits the failures of loop N.
3. Periodically, fold stable patterns back into this skill: a recurring catch class becomes a checklist line in references/gate-checklist-generique.md. That is the recursive improvement path — mechanical, evidence-driven, never aspirational.

The skill's own tooling obeys the same law: python3 scripts/ledger_check.py --self-test, python3 scripts/wincreator.py --self-test and python3 scripts/package_check.py --self-test run the embedded adversarial suites that once broke earlier versions of each script. Run it before trusting the mechanical gate — a verifier that was never itself attacked is an unverified claim. --catches closes the loop one turn further: it fails if SKEPTIC_CATCHES.md holds no well-formed catch, making the retro-loop itself machine-checkable — no catches, no evolution, and now the gate can say so.

Protocol summary

1. Classify: level + weight, stated in one line.
2. Announce the truth gate before starting. Open the Loop Panel (Meso+).
3. Build (Builder role). Ledger rows enter as CLAIMED.
4. Capture the gate with wincreator prove, then review the capture from the Skeptic role with wincreator review. Only review writes EVIDENCED in Standard/Regulated.
5. Report the raw proof result, never an optimistic summary. Re-emit the Panel.
6. Gate failed once → iterate. Failed twice → Two-Failure level audit.
7. Gate captured pass + review EVIDENCED → report up explicitly with what was proven.
8. Proof not executable → PENDING, never assumed. Re-check PENDING/BLOCKED at Meso close: waiting is not a freeze.
9. End of Meso loop: python3 scripts/ledger_check.py as the final mechanical gate (--self-test first if the script is newly installed; --strict-attestation in the Regulated tier).
10. Skeptic catch occurred → one line in SKEPTIC_CATCHES.md before closing the loop. The next loop's gate inherits it.

References — read when the situation calls for them:

• references/worked-example.md — a real session transcript with a Skeptic catch that changed the outcome. Read first if the protocol feels abstract.
• references/proof-ledger.md — ledger format, statuses, template, limits
• references/attestation.md — attestations, signing, verify's limits
• references/agents.md — Builder/Skeptic/Scout role prompts, delegation
• references/gate-checklist-generique.md — domain-adaptable proof checklist
• references/loop-ticket-template.md — iteration traceability template