docs(prompts): Phase 02 wave 4 master prompt for Codex (Honcho subsystem) #36

Merged

pdurlej merged 1 commit from claude/orders/wave-4-master-prompt into main

2026-05-03 20:57:24 +02:00

pdurlej commented

2026-05-03 10:42:37 +02:00

Owner

Summary

Master prompt for Codex to execute Phase 02 wave 4: Honcho subsystem (4 modules + 1 OPEN_LOOPS update = 5 PRs total).

Pivoted from initial proposal (postgres + redis + honcho-postgres) after audit found postgres + redis live in different compose project (infra_postgres_data volume → infra/, not home-platform/apps/). They likely belong to a future Phase 03 (infra-tier wave). Honcho subsystem is coherent: 4 modules in same compose with profile honcho.

Why Honcho first

Operator-emotional importance: Iskra's deep memory layer. Loss = Iskra forgets.
Pattern variety: 2 statefuls (postgres, redis) + 2 services (api, deriver) — good test of new patterns.
End-to-end recovery concern: honcho-api alone is useless if honcho-postgres lost. Wave manifests must consider stack-level restore.
pgvector extension introduces new restore considerations (CREATE EXTENSION vector before pg_restore).

Modules

honcho-postgres — pgvector image, backup_priority: critical (Iskra memory)
honcho-redis — persistence config drives statefulness (audit reveals via INFO persistence)
honcho-api — stateless service, likely tailnet-only via ts-allowlist@file
honcho-deriver — stateless worker, similar pattern to n8n-worker (PR #29)

New patterns vs wave 2/3 (statefuls)

data_stores critical with backup_priority: critical|important|non-critical
Volume name format: project_volname underscores (verified live)
pgvector extension verification step in restore flow
Recovery-from-baseline procedures with operator-grade caution
statefulness driven by audit (redis: persistent vs pure cache distinguished by INFO persistence query)

Cross-module wave 4 task

5th PR: small update to state/L3/OPEN_LOOPS.md marking hp-restore-smoke.timer Honcho-relevant (entry already exists noting 23+ days stale; wave 4 acknowledges this in honcho-postgres manifest).

Hard constraints (additional vs wave 3)

DO NOT pg_dump on running postgres without operator confirmation (locks tables briefly)
DO NOT modify Honcho data ever (only SELECT for sanity checks). Halt + escalate if accidental write.
DO NOT skip pgvector verification in honcho-postgres runbook
One PR per module + 1 OPEN_LOOPS update = 5 PRs total

How operator triggers

After merge (and after wave 3 codex run completes — to avoid working tree conflicts):

cd ~/Developer/iskra-platform-2026-04-30
git pull
codex exec < prompts/phase-02-wave-4.md
# (or via the master-operator wrapper thread per the wave 3 pattern)

Verification

Length: 275 lines, ~3.9k tokens (fits comfortably in Codex session)
References specific canary-validated PR numbers (#29, #30, #32-34) + new wave 3 prompt as predecessor
Charter §3 (deploy flow) and §6 (cognition) referenced
§13 wakeup honesty referenced
Pivot rationale (postgres/redis in different compose project) documented in prompt body so Codex doesn't re-propose them
Honcho-emotional context surfaced ("Iskra deep memory" stakes) — prevents Codex from treating as routine

Test plan

Operator readback: scope feels right (Honcho subsystem, not vanilla data tier)
(Post-merge) Codex execution produces 5 PRs matching wave 2/3 quality bar
(Post-Codex) Each Codex PR fires 3+3 review automatically
Honcho subsystem health post-execution: nothing broken (no runtime touched, only manifests written)

Note on workflow

Operator established new pattern (per Wave 3 trigger): Codex execution wrapped via separate Claude thread (codex://threads/019de580-0b9f-7472-9218-c7f4dd290d5a is now master operator). This wave 4 prompt is written for that wrapper to feed to codex exec, same as wave 3 was.

This orchestrator session (claude-audit-iskra) writes the master prompts; master-operator wrapper thread feeds them to Codex. Clean separation of concerns: prompt-design context here, execution-coordination context there.

## Summary Master prompt for Codex to execute Phase 02 wave 4: **Honcho subsystem** (4 modules + 1 OPEN_LOOPS update = 5 PRs total). Pivoted from initial proposal (`postgres + redis + honcho-postgres`) after audit found `postgres` + `redis` live in **different compose project** (`infra_postgres_data` volume → `infra/`, not `home-platform/apps/`). They likely belong to a future Phase 03 (infra-tier wave). Honcho subsystem is coherent: 4 modules in same compose with `profile honcho`. ## Why Honcho first - **Operator-emotional importance**: Iskra's deep memory layer. Loss = Iskra forgets. - **Pattern variety**: 2 statefuls (postgres, redis) + 2 services (api, deriver) — good test of new patterns. - **End-to-end recovery concern**: `honcho-api` alone is useless if `honcho-postgres` lost. Wave manifests must consider stack-level restore. - **pgvector extension** introduces new restore considerations (`CREATE EXTENSION vector` before `pg_restore`). ## Modules - `honcho-postgres` — pgvector image, `backup_priority: critical` (Iskra memory) - `honcho-redis` — persistence config drives statefulness (audit reveals via `INFO persistence`) - `honcho-api` — stateless service, likely tailnet-only via `ts-allowlist@file` - `honcho-deriver` — stateless worker, similar pattern to `n8n-worker` (PR #29) ## New patterns vs wave 2/3 (statefuls) - `data_stores` critical with `backup_priority: critical|important|non-critical` - Volume name format: `project_volname` underscores (verified live) - pgvector extension verification step in restore flow - Recovery-from-baseline procedures with operator-grade caution - `statefulness` driven by audit (redis: persistent vs pure cache distinguished by `INFO persistence` query) ## Cross-module wave 4 task 5th PR: small update to `state/L3/OPEN_LOOPS.md` marking `hp-restore-smoke.timer` Honcho-relevant (entry already exists noting 23+ days stale; wave 4 acknowledges this in honcho-postgres manifest). ## Hard constraints (additional vs wave 3) - DO NOT `pg_dump` on running postgres without operator confirmation (locks tables briefly) - DO NOT modify Honcho data ever (only `SELECT` for sanity checks). Halt + escalate if accidental write. - DO NOT skip pgvector verification in honcho-postgres runbook - One PR per module + 1 OPEN_LOOPS update = 5 PRs total ## How operator triggers After merge (and after wave 3 codex run completes — to avoid working tree conflicts): ``` cd ~/Developer/iskra-platform-2026-04-30 git pull codex exec < prompts/phase-02-wave-4.md # (or via the master-operator wrapper thread per the wave 3 pattern) ``` ## Verification - [x] Length: 275 lines, ~3.9k tokens (fits comfortably in Codex session) - [x] References specific canary-validated PR numbers (#29, #30, #32-34) + new wave 3 prompt as predecessor - [x] Charter §3 (deploy flow) and §6 (cognition) referenced - [x] §13 wakeup honesty referenced - [x] Pivot rationale (postgres/redis in different compose project) documented in prompt body so Codex doesn't re-propose them - [x] Honcho-emotional context surfaced ("Iskra deep memory" stakes) — prevents Codex from treating as routine ## Test plan - [ ] Operator readback: scope feels right (Honcho subsystem, not vanilla data tier) - [ ] (Post-merge) Codex execution produces 5 PRs matching wave 2/3 quality bar - [ ] (Post-Codex) Each Codex PR fires 3+3 review automatically - [ ] Honcho subsystem health post-execution: nothing broken (no runtime touched, only manifests written) ## Note on workflow Operator established new pattern (per Wave 3 trigger): Codex execution wrapped via separate Claude thread (`codex://threads/019de580-0b9f-7472-9218-c7f4dd290d5a` is now master operator). This wave 4 prompt is written for that wrapper to feed to `codex exec`, same as wave 3 was. This orchestrator session (`claude-audit-iskra`) writes the master prompts; master-operator wrapper thread feeds them to Codex. Clean separation of concerns: prompt-design context here, execution-coordination context there.

pdurlej added 1 commit

2026-05-03 10:42:37 +02:00

docs(prompts): Phase 02 wave 4 master prompt for Codex (Honcho subsystem) 8a0e974b12

Codex master prompt for wave 4: Honcho subsystem (4 modules + 1 OPEN_LOOPS
update = 5 PRs total). Pivoted from initial proposal (postgres+redis+honcho-
postgres) after audit found postgres+redis live in different compose
project (infra_postgres_data → infra/, not home-platform/apps/). Honcho
subsystem is coherent: 4 modules in same compose with profile honcho.

Modules: honcho-postgres, honcho-redis, honcho-api, honcho-deriver

Why Honcho first:
- Operator-emotional importance (Iskra's deep memory layer)
- Mix of pattern types: 2 statefuls + 2 services
- Recovery is end-to-end concern (api alone is useless if postgres lost)
- pgvector extension introduces new restore considerations

New patterns vs wave 2/3 (statefuls):
- data_stores critical with backup_priority: critical|important|non-critical
- Volume name format: project_volname underscores (verified runtime)
- pgvector extension verification step in restore flow (CREATE EXTENSION
  vector before pg_restore)
- Recovery-from-baseline procedures with operator-grade caution
- Statefulness driven by audit (redis: persistent vs cache via INFO
  persistence query)

Module-specific notes:
- honcho-postgres: pgvector image, backup_priority critical (Iskra
  memory loss = catastrophic), restore needs extension preserved
- honcho-redis: persistence config drives statefulness (audit reveals)
- honcho-api: stateless service, tailnet-only likely, ts-allowlist@file
- honcho-deriver: stateless worker, similar to n8n-worker pattern

Cross-module wave 4 task: small additional PR updating
state/L3/OPEN_LOOPS.md to mark hp-restore-smoke.timer Honcho-relevant
(23+ days stale per existing entry).

Hard constraints (additional vs wave 3):
- DO NOT pg_dump on running postgres without operator confirmation
- DO NOT modify Honcho data ever (only SELECT for sanity)
- DO NOT skip pgvector verification in honcho-postgres runbook
- One PR per module + 1 OPEN_LOOPS update = 5 PRs total

Hand-back: 5 PR URLs + per-module summary + Honcho subsystem health
observation. Operator owns merge gate.

Length: 275 lines, ~3.9k tokens.

Note: Operator pattern shift — codex execution wrapped via separate
Claude thread (master operator: codex://threads/019de580-0b9f-7472-9218-
c7f4dd290d5a). This wave 4 prompt is written for that wrapper to feed to
codex-via-codex-exec, same as wave 3 was.

pdurlej referenced this pull request from a commit

2026-05-03 11:19:48 +02:00

docs(decisions): ADR 0001 — canary 3+3 mandatory; orchestrator cadence is PM-style

pdurlej referenced this pull request

2026-05-03 11:20:12 +02:00

docs(decisions): ADR 0001 — canary 3+3 mandatory; orchestrator cadence is PM-style #41

pdurlej merged commit cc9e21b108 into main

2026-05-03 20:57:24 +02:00

pdurlej referenced this pull request from a commit

2026-05-03 20:57:24 +02:00

Merge pull request 'docs(prompts): Phase 02 wave 4 master prompt for Codex (Honcho subsystem)' (#36) from claude/orders/wave-4-master-prompt into main