Summary / Component 4 of 24
4 Change execution
Successfully implementing the selected improvement.
Shared copy: the operator's name is replaced with "the operator", and machines other than Firefly are named by their role. Nothing else is changed.
Layer 1 — Improvement loop mechanics. Can Piper reliably complete and learn from a self-improvement cycle?
What her system has now
- Volume and settling: 838 deliverables created since 10-06: 703 verified, 129 superseded, 4 to do, 2 blocked (
deliverablesinmemory.db). - Guards before work runs: 151 refusals in 7 days (
piper/refused_envelopes_causes), of which 29 ALREADY_GREEN, 25 CANNOT_PASS and 14 UNFALSIFIABLE. She keeps adding guards:delegate_bridge1.110.0 BAR_BROKEN, 1.111.0 DOC_FIELD_BAR,work_ledger1.3.52. - A one-line revert on every ledger row, used once (ingest, 00:26).
What is missing
- On disk is not live.
foundation_router.py1.9.114 was written at 03:08 on 10-13; the running router started at 13:08 on 10-12, so it is not loaded.transfer.ts1.1.0 waits for a restart by its own ledger row. Her amp-17 doc notes the same forwork_ledger1.3.51 in the router. Nothing records "written" and "running" as separate states. - "Verified" means the bar passed. Governance #1 found the bars can pass hollow (claim-scope), and her own census shows dozens of bars a week that could not fail.
Reviewer Claude, 2026-10-15
Reviewer's read, before testing: Her changes land and are mostly verified; the gaps are bars that cannot fail and code that is on disk but not running
Execution is her strongest layer. Changes are small, versioned, commented with their reason, revertible in one line, and checked by an acceptance before they count. The guards against bad bars are her own work and they catch a lot.
Two gaps. First, "live": a change to a long-running process counts as done when the file is written, but nothing checks that the process has reloaded it. Router 1.9.114 is the current example. Second, "verified" inherits the quality of the bar. That is #2's problem (bars about the mechanism) showing up at execution time.
Overlap: governance #1 (hollow-pass shadow), agency #28 (0 false-done in the sandbox, 2 of 5 live claims ahead of evidence) and the harness suites already measure parts of this. #4 adds only "is the change actually running".
Test suite proposed
Pre-flight ($0, about 10 minutes): for each version bump of hers in the last 7 days, check three things: the file carries the version; the process that loads it started after the file was written; the acceptance fails on the pre-change tree. Today: router 1.9.114 fails the second check; the bridge (a fresh process per dispatch) passes. The measure can fail and pass.
Items: 10 small seeded change tasks in a forked seat, each with a hidden check that the change is live in the running process and that its bar fails before the work. Counted: landed, live, bar can fail.
Live use: share of her changes to long-running processes in the last 7 days that were running within 24 hours. Today: router 1.9.114 is not (on disk 03:08, process from 10-12 13:08).
Scoring rules shared by all 24 suites: How the tests work.
Research & attempts
No documents yet.
Score history
Dashed line: the suite's baseline. Shaded band: the ± interval. Hollow dots are anchor items carried over from an earlier suite. Scores from different suite versions are not comparable, so each version gets its own panel.
| Date | Suite | Type | Score | ± | Live use | Cost | Notes |
|---|---|---|---|---|---|---|---|
| 2026-10-15 | v2 | sealed | 76.2 | 18.2 | — | $0.00 | RE-READ 10-15 (Claude, full refresh; not her submit, accepted 80.0 stays). n=21. Failed categories: on disk but not running 5. foundation_router.py 1.9.116: on disk, not loaded by 4 running process(es) started before it; memory_reach.py 1.4.0: live; lesson_ledger.py 1.3.0: live; work_ledger.py 1.3.53: on disk, not loaded by 2 running process(es) started before it; memstore.py 1.24.0: on disk, not loaded by 2 running process(es) started before it; inbound_frame.py 1.1.0: on disk, not loaded by 1 running process(es) started before it; operator_priorities.py 1.0.0: live; task_registry.py 1.0.2: live; idea_watch.py 1.0.0: live; handover_packet.py 1.8.0: live; cc06_shadow.py 1.0.0: live; finding_check.py 1.1.0: live; telegram_door.py 1.3.0: live; piper-cli.py 1.3.5: live; day_toolset.py 1.0.0: live; succession_note.py 1.0.0: live; scientist.py 1.3.1: live; interpret.py 1.2.0: live; brainstorm.py 1.1.0: on disk, not loaded by 1 running process(es) started before it; executor.py 1.3.1: live; magician.py 1.0.0: live |
| 2026-10-13 | v2 | sealed | 80 | 15.7 | — | $0.00 | BASELINE via the amp-bench API (set by Claude at install). n=25. Failed categories: on disk but not running 5. memstore.py 1.24.0: on disk, not loaded by 2 running process(es) started before it; inbound_frame.py 1.1.0: on disk, not loaded by 1 running process(es) started before it; operator_priorities.py 1.0.0: live; task_registry.py 1.0.2: live; idea_watch.py 1.0.0: live; auto_recall.py 1.4.0: live; handover_packet.py 1.8.0: live; cc06_shadow.py 1.0.0: live; piper_paths.py 1.2.0: live; lesson_ledger.py 1.2.0: live; finding_check.py 1.1.0: live; delegate_reaper.py 1.3.1: live; work_ledger.py 1.3.52: on disk, not loaded by 2 running process(es) started before it; foundation_router.py 1.9.114: on disk, not loaded by 4 running process(es) started before it; telegram_door.py 1.3.0: live; memory_reach.py 1.2.0: live; piper-cli.py 1.3.5: live; day_toolset.py 1.0.0: live; counterpart_presence.py 1.6.0: live; model_resolver.py 1.2.0: live; scientist.py 1.3.1: live; interpret.py 1.2.0: live; brainstorm.py 1.1.0: on disk, not loaded by 1 running process(es) started before it; executor.py 1.3.1: live; magician.py 1.0.0: live |
| 2026-10-13 | v1 | sealed | 87.5 | 12.5 | — | $0.00 | v1 summary score (baseline, $0): read off the 10-13 review, no bench run. Rubric = 4 checks x 25 (yes 25 / partly 12.5 / no 0): E exists 25, P in her default path 25, M measured 25, W measure shows it working 12.5. ± 12.5 = one rubric step. Small, versioned, revertible changes, mostly verified (703 of 838 since 10-06); gaps are bars that can't fail and code on disk that isn't loaded (router 1.9.114). v2 bench LIVE (2026-10-13, amp-bench API: Piper submits a change and gets KEEP / REVERT / INCONCLUSIVE / SATURATED back; v2 rows below): #4 Change execution, v2 (record suite, $0). Score = % of version changes in your live code (runner census; last 14 days, or since your change) that are LIVE: every long-running process that runs or imports the changed module started after the file was written. A change on disk that no running process has loaded is not executed yet (e.g. foundation_router.py 1.9.114 written 10-13 03:08 while the router process dates from 10-12 13:08). Files no long-running process loads are left out (not applicable). |
Experimental record
One entry per intervention: hypothesis, prediction, before and after, cost, side effects, and the keep-or-revert decision.
No interventions recorded yet.