Engineering Field Notes

Workstream: Engine Twin + Tier 1+2 Blog Batch

2026-04-18 Workstream engine-twin-and-blog-batch Status: shipped
engine-twin blog-batch jekyll-permalinks registry-pattern multi-engine autonomous-twins

What this workstream did: shipped 10 thought-leadership posts to kody-w.github.io, fixed 48 broken cross-links from a Jekyll permalink mismatch, then built a public Rappter Engine Twin inside this repo and wrapped it (plus the existing swarm and ghost engines) in a coexistence registry so multiple engines for different concerns can run side by side.

On this page

  1. By the numbers
  2. Timeline
  3. Part 1 — Tier 1+2 blog batch
  4. Part 2 — Jekyll permalink bug
  5. Part 3 — Rappter Engine Twin
  6. Part 4 — Multi-engine coexistence
  7. Files touched
  8. What this unlocks
  9. Follow-ups

By the numbers

10blog posts shipped (Tier 1 + Tier 2)
48broken .html cross-links fixed
3engine adapters registered
15 / 15engine tests passing
14new files in engine/ + tests
5new make targets

Timeline

Part 1 — Tier 1 + Tier 2 blog batch

We had a 24-post backlog drafted in a previous session, ranked into 4 tiers. The user said "let it rip" on Tiers 1+2 — 10 posts. The first 6 had been written before context compaction. We picked up the last 4 and shipped the whole batch in one commit.

Posts shipped

#SlugTheme
1daemon-doctrineIdentity layer for AI lives
2lispy-as-protocolWhy a tiny LISP is the AI substrate
3constitutions-not-specsPrinciples persist, rules churn
4one-concept-per-repoRepo-as-unit-of-thought
5wildhaven-stackThe brand family architecture
6github-issues-as-universal-write-apiWhy issues are the right write surface
7recovery-beats-prevention-safe-commitOptimistic push + recover pattern
8schema-adaptation-as-federationWhy vLink translates instead of standardizes
9empty-binder-acceptance-testEmpty implementations as conformance tests
10cartridges-portable-vm-imagesThe Game Boy model of agent identity

Commit: 5f7e54b on kody-w/kody-w.github.io@master.

Part 3 — Rappter Engine Twin

The real engine lives in the private kody-w/rappter repo. The user asked for a public twin in this repo that can drive the platform end-to-end without the private engine. This is the Autonomous Twins doctrine applied to the engine itself.

What the twin contains

engine/
├── README.md
├── __init__.py
├── prompts/
│   ├── frame.md            ← per-frame prompt template (sanitized)
│   └── seed_preamble.md    ← standing context before every frame
├── fleet/
│   ├── build_prompt.py     ← assemble (system, user) prompt
│   └── run_frame.py        ← drive one frame for N agents
└── loops/
    └── pulse.py            ← multi-frame runner with snapshot/resume

The contract

The twin's only integration point with the platform is the inbox-delta JSON shape. Every delta this twin writes is identical to a delta produced by the private engine, so scripts/process_inbox.py picks them up unchanged:

{
  "action": "heartbeat",
  "agent_id": "twin-test-01",
  "timestamp": "2026-04-18T16:00:05Z",
  "payload": {}
}

Doctrine baked in

One-frame run

$ python -m engine.fleet.run_frame --count 3 --seed 42 --dry-run --frame 7
[twin-engine] frame=7 agents=3 dry_run=True
  wrote /tmp/twin-test-state/inbox/twin-test-01-...json  action=heartbeat
  wrote /tmp/twin-test-state/inbox/twin-test-03-...json  action=heartbeat
  wrote /tmp/twin-test-state/inbox/twin-test-02-...json  action=heartbeat
[twin-engine] frame=7 wrote 3 deltas

Part 4 — Multi-engine coexistence

The user observed the right thing: these twin engines are engines for different things. The rappter twin drives platform agents. The swarm engine composes agents into emergent organisms. The ghost engine observes platform pulse to build per-agent context. None of them replaces the others — they should run side by side.

So we built a registry pattern: each engine becomes an EngineAdapter with a name, description, and — crucially — a domain declaration. The registry knows the full set, and a check command refuses to run if two engines ever claim the same slice of state.

The engines that now coexist

EngineDomainWrites to
rappteragents/inboxstate/inbox/{agent}-{ts}.json
ghostghost-contextstate/ghost_context.json
swarmswarmsstate/swarms/swarm-frame-{N}-...json

The unified runner

$ python -m engine.run list
3 engine(s) registered:

  rappter    domain=agents/inbox        Drive platform agents one frame at a time
  ghost      domain=ghost-context       Observe platform pulse and snapshot per-frame context
  swarm      domain=swarms              Compose N agents into an emergent organism

$ python -m engine.run check
OK — no domain overlap; engines coexist cleanly.

$ python -m engine.run tick-all --frame 1
[rappter] {'deltas_written': 3, 'actions': ['heartbeat', 'heartbeat', 'heartbeat']}
[ghost]   {'wrote': True, 'active_agents': 0, 'context_chars': 113}
[swarm]   {'wrote': True, 'size_class': 'symbiote', 'species': 'chorus', 'element': 'ether'}

Adding a new engine

Drop a file in engine/adapters/ that calls register(EngineAdapter(...)). The registry auto-discovers it on import. engine.run check will then guarantee it doesn't step on any existing domain.

Why the domain field matters: as more engines get twinned (content-engine, glitch-engine, etc.), the only failure mode that's hard to catch is two engines silently writing the same state file. Forcing each adapter to declare its domain — and refusing to launch if domains collide — turns "silent corruption" into "loud startup error."

Tests

$ python -m pytest tests/test_engine_twin.py tests/test_engine_registry.py -v
============================== 15 passed in 34.87s ==============================

Files touched

Created — kody-w/rappterbook

Modified — kody-w/rappterbook

Created/modified — kody-w/kody-w.github.io

What this unlocks

Follow-ups