conductor/rune
1
2 Fork 1
Code Issues 38 Pull Requests 32 Actions Packages Projects Releases 565 Wiki Activity

REMOVAL TRANCHE (program, queued after REBASE-COMPLETION + REBASE-PROOF): delete soaked Python bodies per the port→integrate→remove law #2592

New Issue
Open
opened 2026-10-24 22:35:07 +01:00 by conductor · 0 comments
conductor commented 2026-10-24 22:35:07 +01:00
Owner
Copy link
Copy source

In plain English:

OWNER DIRECTIVE: queue the removal tranche as the next program after the wiring wave lands. The rebase has port+integrate for a handful of rows but removal was never scheduled — src/rune is a museum (296 modules: oracle bodies, wired facades, dark dual-side modules being wired now, never-ported remainder).\n\nTHE PROGRAM (only after REBASE-COMPLETION wires all 11 dark modules AND REBASE-PROOF earns wired-in status):\n1. SOAK AUDIT: for every wired row, verify the soak clock (integrated-since date in its receipt) — all clocks must be satisfied; unsatisfied rows wait, no exceptions.\n2. REMOVAL BATCHES by confidence: (a) oracle bodies whose facade has served the whole soak with zero python-engine invocations in the hot journal — delete the python body, keep the facade shell; (b) full Python modules whose every caller is gone — delete module + tests move to the Go side's battery; (c) escape hatches: KEEP (owner's explicit law — RUNE*_ENGINE=python is the retreat road, never removed).\n3. THE INVENTORY GOVERNS: every deletion cites its receipt; anything without a receipt or with an unsatisfied clock is untouchable.\n4. WITNESS THE SHRINK: module/line count before/after per batch, committed in the batch message — the dichotomy becomes visibly true in the tree.\n5. ZERO DELETION SILENTLY: each batch names what was deleted, why its clock was satisfied, and what its Go replacement is.\n\nPRE-WORK THIS WAVE ALSO DOES: classify the never-ported remainder (~270 modules) — legit-Python (test/tooling/UI boundary) vs needs-a-Go-side vs dead — so the program's end-state is a known list, not a vibe.

What is this about:

Why do we need it: <the itch — what happens today that shouldn't, or what becomes possible>

Why is it still open: <"not started yet" | "part done, X remains" | "deliberately parked as a future idea">

Example

What would let us close this

  • <condition 1 — observable>
  • <condition 2>

Version impact (declared at submission — verified at merge)

  • major — breaking: changes a contract, schema, or interface others depend on
  • minor — new capability: something becomes possible that wasn't
  • patch — repair: same behaviour, done correctly
  • none — touches no released artifact (docs, memory, process notes)

Technical details

WHAT:
WHY:
FILES:
ACCEPTANCE:
DEPENDENCIES:

Pipeline requirements

  • TDD: frozen tests written first, red → green (N passed)
  • ruff check and ruff format --check clean
  • Spec-compliance review gate: PASS
  • Code-quality review gate: Approved
  • Full orchestration suite regression green (suite total)
  • Canary passes (name)
  • Closed with a properly formatted closing comment + commit/PR references

Cognitive invariants (memory/cognition issues — both handoffs)

  • Owner — which existing subsystem owns this (audit before creating modules)
  • Trigger — what event activates it
  • Read/write authority — which canonical state it reads/changes
  • Provenance — derived state traceable to evidence
  • Verification — how we know the change helped
  • Failure visibility — how failure surfaces
  • Reversibility — bad learned state can be superseded/replayed/rolled back
  • Dormant cost — what it costs when irrelevant
  • Benchmark + ablation — what measurable behaviour improves; what happens when disabled
  • No duplicate authority — why extend vs create

Hard invariants: derived cognition preserves evidentiary ancestry · epistemic confidence ≠ attentional utility ≠ current applicability · retrieval never increases utility · self-model-induced behaviour is not independent evidence · historical truth survives present-state change · raw evidence is never destroyed by promotion.

Related umbrella

  • Memory
  • Governance
  • Identity
  • Growth
  • Perception
  • Infrastructure
  • Life (Nick's)
  • Custodian
  • Orchestration

Priority (REQUIRED — the priority gate)

  • P0 — critical — breaks the spine / core correctness, or blocks other work
  • P1 — high — material user value or a real defect (money, correctness bugs, next-stage dependency)
  • P2 — medium — quality/consolidation improvement (check the fold-into mapping first)
  • P3 — low — measurement / benchmark / deferred policy
## In plain English: <restate the issue title here in everyday words> <!-- The heading ITSELF must carry the summary — a scan of issue headings alone should tell the whole story of the board. TOP PRIORITY: if a technical detail below contradicts this section, the issue is buggy — fix the issue. A non-technical reader must be able to retell this section. 3-6 sentences, no jargon. --> OWNER DIRECTIVE: queue the removal tranche as the next program after the wiring wave lands. The rebase has port+integrate for a handful of rows but removal was never scheduled — src/rune is a museum (296 modules: oracle bodies, wired facades, dark dual-side modules being wired now, never-ported remainder).\n\nTHE PROGRAM (only after REBASE-COMPLETION wires all 11 dark modules AND REBASE-PROOF earns wired-in status):\n1. SOAK AUDIT: for every wired row, verify the soak clock (integrated-since date in its receipt) — all clocks must be satisfied; unsatisfied rows wait, no exceptions.\n2. REMOVAL BATCHES by confidence: (a) oracle bodies whose facade has served the whole soak with zero python-engine invocations in the hot journal — delete the _python body, keep the facade shell; (b) full Python modules whose every caller is gone — delete module + tests move to the Go side's battery; (c) escape hatches: KEEP (owner's explicit law — RUNE_*_ENGINE=python is the retreat road, never removed).\n3. THE INVENTORY GOVERNS: every deletion cites its receipt; anything without a receipt or with an unsatisfied clock is untouchable.\n4. WITNESS THE SHRINK: module/line count before/after per batch, committed in the batch message — the dichotomy becomes visibly true in the tree.\n5. ZERO DELETION SILENTLY: each batch names what was deleted, why its clock was satisfied, and what its Go replacement is.\n\nPRE-WORK THIS WAVE ALSO DOES: classify the never-ported remainder (~270 modules) — legit-Python (test/tooling/UI boundary) vs needs-a-Go-side vs dead — so the program's end-state is a known list, not a vibe. What is this about: <what> Why do we need it: <the itch — what happens today that shouldn't, or what becomes possible> Why is it still open: <"not started yet" | "part done, X remains" | "deliberately parked as a future idea"> ## Example <!-- A concrete before/after in plain terms: "If X happens, the system will Y instead of Z." --> ## What would let us close this <!-- Checkable statements, verifiable by looking at something that EXISTS — a file, a log line, a passing test. Not "when appropriate". --> - [ ] <condition 1 — observable> - [ ] <condition 2> ## Version impact (declared at submission — verified at merge) <!-- The pipeline derives the real bump from merged conventional commits and compares against this declaration. A mismatch is flagged, not fatal: either the declaration was wrong or the work grew. Both facts matter. --> - [ ] major — breaking: changes a contract, schema, or interface others depend on - [ ] minor — new capability: something becomes possible that wasn't - [ ] patch — repair: same behaviour, done correctly - [ ] none — touches no released artifact (docs, memory, process notes) ## Technical details <!-- WHAT — one-line objective. WHY — design-spec reference (S#) or reason. FILES — affected components. ACCEPTANCE — frozen-test file + test count + canary name. DEPENDENCIES — parent epic + preceding stage/plan refs. --> **WHAT:** **WHY:** **FILES:** **ACCEPTANCE:** **DEPENDENCIES:** ## Pipeline requirements <!-- Every stage must clear these before the issue closes. --> - [ ] TDD: frozen tests written first, red → green (N passed) - [ ] `ruff check` and `ruff format --check` clean - [ ] Spec-compliance review gate: PASS - [ ] Code-quality review gate: Approved - [ ] Full orchestration suite regression green (suite total) - [ ] Canary passes (name) - [ ] Closed with a properly formatted closing comment + commit/PR references ## Cognitive invariants (memory/cognition issues — both handoffs) <!-- Complete ONLY if this issue touches memory, learning, or self-model state. --> - [ ] **Owner** — which existing subsystem owns this (audit before creating modules) - [ ] **Trigger** — what event activates it - [ ] **Read/write authority** — which canonical state it reads/changes - [ ] **Provenance** — derived state traceable to evidence - [ ] **Verification** — how we know the change helped - [ ] **Failure visibility** — how failure surfaces - [ ] **Reversibility** — bad learned state can be superseded/replayed/rolled back - [ ] **Dormant cost** — what it costs when irrelevant - [ ] **Benchmark + ablation** — what measurable behaviour improves; what happens when disabled - [ ] **No duplicate authority** — why extend vs create Hard invariants: derived cognition preserves evidentiary ancestry · epistemic confidence ≠ attentional utility ≠ current applicability · retrieval never increases utility · self-model-induced behaviour is not independent evidence · historical truth survives present-state change · raw evidence is never destroyed by promotion. ## Related umbrella - [ ] Memory - [ ] Governance - [ ] Identity - [ ] Growth - [ ] Perception - [ ] Infrastructure - [ ] Life (Nick's) - [ ] Custodian - [ ] Orchestration ## Priority (REQUIRED — the priority gate) <!-- Pick exactly one. An issue without a priority is not filed. --> - [ ] **P0 — critical** — breaks the spine / core correctness, or blocks other work - [ ] **P1 — high** — material user value or a real defect (money, correctness bugs, next-stage dependency) - [ ] **P2 — medium** — quality/consolidation improvement (check the fold-into mapping first) - [ ] **P3 — low** — measurement / benchmark / deferred policy
conductor added the featureP2 — medium labels 2026-10-24 22:35:08 +01:00
Sign in to join this conversation.
No Branch/Tag Specified
Labels
Clear labels
P0 — critical
Spine/core correctness or blocks other work — do first
 P1 — high
Material user value or real defect (money, bugs, next-stage dep)
 P2 — medium
Quality/consolidation improvement
 P3 — low
Measurement / benchmark / deferred policy
 blocked
Dependencies open
 bug
Confirmed defect or regression
 custodian
epic
Rune v1 course-correction issue graph
 feature
New capability or improvement
 governance
growth
identity
in-progress
Currently being worked on by Rune
 incomplete
Incomplete work — draft PR with ledger, awaiting resume
 infrastructure
life
memory
memory-atlas
Memory Research Atlas child domain
 needs-testing
Needs manual testing with dumbed-down steps before close
 perception
ready
Order satisfied - Rune may start
 release-drift
research
Research jobs — spikes, watchlists, evidence work
 rune
rune
 scaffolding
scaffolding
 spine,correction
spine,correction
 spine,deferred
spine,deferred
 spine,resolved
spine,resolved
 strangler,burn,endgame,deferred
strangler,burn,endgame,deferred
 strangler,burn,endgame,inventory,epic
strangler,burn,endgame,inventory,epic
 tui
tui
 tui,epic
tui,epic
 tui,openspec
tui,openspec
 v1-course-correction
Rune v1 course-correction issue graph
No labels P0 — critical bug custodian governance growth identity infrastructure life memory perception
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
conductor
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: conductor/rune#2592