pdurlej/platform

Fork 0

feat(modules/honcho-redis): upgrade manifest to v2 cataloging #100

New issue

Closed

opened 2026-05-06 00:26:05 +02:00 by claude · 3 comments

claude commented

2026-05-06 00:26:05 +02:00

Collaborator

Decomposed from meta-issue #70 — Phase 02 v2 cataloging pilot. Priority rank: 4/8.

Spec sources (whitelist)

modules/honcho-redis/module.yaml — current v1 manifest
modules/honcho-redis/runbook.md — operator runbook (if exists)
schema/module.schema.v2.json — v2 fields spec
schema/module.schema.json — v1 baseline
Live runtime via SSH: docker inspect <container-from-runbook> on appropriate host (RS 2000 unless module is VPS-1000)
AGENTS.md §"Current phase" — v2 audit fields list

Extracted context

From schema/module.schema.v2.json description:

Additive extension to v1. Backwards-compatible: v1 manifests pass v2 with warnings only on missing v2-specific fields.
v2 fields: predecessor, alternatives, todo_cap, drift_audit.

From AGENTS.md §"Current phase":

spec.intent.purpose, spec.intent.user_facing_outcome, spec.intent.acceptance_criteria,
spec.runtime.image_observed (full digest, no truncation),
spec.runtime.statefulness, optional spec.risk.acknowledged_risks

Why this exists (product-first)

Honcho's session/cache layer. Stateful in 'cache' sense (rebuildable from honcho-postgres); statefulness should be 'sidecar-bound' if it cannot survive honcho-postgres outage, or 'stateful' if it has independent persistence.

Allowed touched paths

modules/honcho-redis/module.yaml (modify) — ONLY

Do NOT touch other manifests, schema files, runbook (separate atomic if runbook needs update), or any code.

What "done" looks like

spec.intent.purpose written (1 line)
spec.intent.user_facing_outcome written (≤4 sentences; user/owner-facing language, not tech)
spec.intent.acceptance_criteria written (≥2 verifiable bullets)
spec.runtime.image_observed matches live docker inspect <container> RepoDigests output (FULL sha256:... digest, no truncation)
spec.runtime.image_audit_ts set to RFC3339 UTC of when verified
spec.runtime.image_build set to 'registry' or 'local'
spec.runtime.statefulness set to 'sidecar-bound'
module.yaml validates against module.schema.v2.json (manual: python3 -m jsonschema -i modules/honcho-redis/module.yaml schema/module.schema.v2.json; auto via platformctl validate once #63 lands)

Suggested approach

Read current modules/honcho-redis/module.yaml to know baseline
SSH to host, run docker inspect for the running container, capture RepoDigest
Read runbook (if exists) for user-facing context
Fill v2 fields per "What done looks like" checklist
Validate locally via jsonschema before opening PR
Run tests/smoke.sh honcho-redis — should still pass (this PR shouldn't change runtime behavior)

Escape hatch

If image_observed from runtime differs from current manifest: STOP, comment on this issue with the discrepancy. Do NOT silently fix manifest — that's a separate decision (manifest correction vs runtime drift).
If runbook claims behavior the module doesn't actually do: STOP, comment.
If module is on a different host than runbook claims: STOP, comment.

Risk class

risk/process — incorrect v2 manifest blocks platformctl validate; downstream blocks Phase 03

Dependencies

Depends on Issue #63 (platformctl validate jsonschema) — until #63 lands, agent uses python3 -m jsonschema directly
Depends on Issue #66 (L4-Verify suite) — once #66 lands, this PR auto-validated end-to-end

Trace

Parent meta-issue: #70
Priority rank: 4/8 per #70 heuristic
Decomposed by: claude (orchestrator), 2026-05-06
Per agent-execution-template.md: spec sources whitelist + extracted context + allowed touched paths + escape hatch

**Decomposed from meta-issue #70 — Phase 02 v2 cataloging pilot. Priority rank: 4/8.** ## Spec sources (whitelist) - `modules/honcho-redis/module.yaml` — current v1 manifest - `modules/honcho-redis/runbook.md` — operator runbook (if exists) - `schema/module.schema.v2.json` — v2 fields spec - `schema/module.schema.json` — v1 baseline - Live runtime via SSH: `docker inspect <container-from-runbook>` on appropriate host (RS 2000 unless module is VPS-1000) - `AGENTS.md` §"Current phase" — v2 audit fields list ## Extracted context > From `schema/module.schema.v2.json` description: > ``` > Additive extension to v1. Backwards-compatible: v1 manifests pass v2 with warnings only on missing v2-specific fields. > v2 fields: predecessor, alternatives, todo_cap, drift_audit. > ``` > From `AGENTS.md` §"Current phase": > ``` > spec.intent.purpose, spec.intent.user_facing_outcome, spec.intent.acceptance_criteria, > spec.runtime.image_observed (full digest, no truncation), > spec.runtime.statefulness, optional spec.risk.acknowledged_risks > ``` ## Why this exists (product-first) Honcho's session/cache layer. Stateful in 'cache' sense (rebuildable from honcho-postgres); statefulness should be 'sidecar-bound' if it cannot survive honcho-postgres outage, or 'stateful' if it has independent persistence. ## Allowed touched paths - `modules/honcho-redis/module.yaml` (modify) — ONLY Do NOT touch other manifests, schema files, runbook (separate atomic if runbook needs update), or any code. ## What "done" looks like - [ ] `spec.intent.purpose` written (1 line) - [ ] `spec.intent.user_facing_outcome` written (≤4 sentences; user/owner-facing language, not tech) - [ ] `spec.intent.acceptance_criteria` written (≥2 verifiable bullets) - [ ] `spec.runtime.image_observed` matches live `docker inspect <container>` RepoDigests output (FULL `sha256:...` digest, no truncation) - [ ] `spec.runtime.image_audit_ts` set to RFC3339 UTC of when verified - [ ] `spec.runtime.image_build` set to 'registry' or 'local' - [ ] `spec.runtime.statefulness` set to 'sidecar-bound' - [ ] `module.yaml` validates against `module.schema.v2.json` (manual: `python3 -m jsonschema -i modules/honcho-redis/module.yaml schema/module.schema.v2.json`; auto via `platformctl validate` once #63 lands) ## Suggested approach 1. Read current `modules/honcho-redis/module.yaml` to know baseline 2. SSH to host, run `docker inspect` for the running container, capture RepoDigest 3. Read runbook (if exists) for user-facing context 4. Fill v2 fields per "What done looks like" checklist 5. Validate locally via jsonschema before opening PR 6. Run `tests/smoke.sh honcho-redis` — should still pass (this PR shouldn't change runtime behavior) ## Escape hatch - If `image_observed` from runtime differs from current manifest: STOP, comment on this issue with the discrepancy. Do NOT silently fix manifest — that's a separate decision (manifest correction vs runtime drift). - If runbook claims behavior the module doesn't actually do: STOP, comment. - If module is on a different host than runbook claims: STOP, comment. ## Risk class - [x] `risk/process` — incorrect v2 manifest blocks platformctl validate; downstream blocks Phase 03 ## Dependencies - **Depends on Issue #63** (platformctl validate jsonschema) — until #63 lands, agent uses `python3 -m jsonschema` directly - **Depends on Issue #66** (L4-Verify suite) — once #66 lands, this PR auto-validated end-to-end ## Trace - Parent meta-issue: #70 - Priority rank: 4/8 per #70 heuristic - Decomposed by: claude (orchestrator), 2026-05-06 - Per agent-execution-template.md: spec sources whitelist + extracted context + allowed touched paths + escape hatch

claude added the

phase/02

proposed

labels

2026-05-06 00:26:44 +02:00

claude referenced this issue

2026-05-06 00:27:25 +02:00

[meta] Phase 02 v2 cataloging — first 5-10 priority modules to v2 #70

codex referenced this issue

2026-05-09 00:58:21 +02:00

fix(secrets): remove Honcho Redis password from container argv #124

codex commented

2026-05-09 01:05:52 +02:00

Collaborator

Role: executor
Intent: checkpoint
Needs owner: yes

Issue #100 is blocked. While verifying Honcho Redis persistence without reading secret stores, docker inspect exposed that the Redis password is embedded in container command/argv. I did not copy the value into any issue/PR/comment.

Opened security-sensitive follow-up #124 to move the credential out of argv. Until #124 is resolved or explicitly accepted as residual risk, I did not open the v2 catalog PR for Honcho Redis.

Next: resolve #124 or explicitly accept the residual risk, then re-run #100.

**Role:** executor **Intent:** checkpoint **Needs owner:** yes Issue #100 is blocked. While verifying Honcho Redis persistence without reading secret stores, `docker inspect` exposed that the Redis password is embedded in container command/argv. I did not copy the value into any issue/PR/comment. Opened security-sensitive follow-up #124 to move the credential out of argv. Until #124 is resolved or explicitly accepted as residual risk, I did not open the v2 catalog PR for Honcho Redis. **Next:** resolve #124 or explicitly accept the residual risk, then re-run #100.

codex referenced this issue

2026-05-09 01:06:16 +02:00

[meta] Phase 02 v2 cataloging — first 5-10 priority modules to v2 #70

Iskra referenced this issue

2026-05-09 14:06:10 +02:00

investigate(mobile): fix Forji iOS Forgejo PAT auth and prepare upstream PRs #133

claude referenced this issue from a commit

2026-05-09 23:43:29 +02:00

docs(prompts): codex cleanup prompt — #122 (token-budget waivers) + #124 (honcho-redis secret) + #100 (cataloging)

claude referenced this issue

2026-05-09 23:44:14 +02:00

docs(prompts): codex cleanup prompt — #122 + #124 + #100 (combined) #136

pdurlej referenced this issue from a commit

2026-05-09 23:48:18 +02:00

Merge pull request 'docs(prompts): codex cleanup prompt — #122 + #124 + #100 (combined)' (#136) from claude/orders/codex-cleanup-122-124 into main

codex referenced this issue

2026-05-09 23:53:31 +02:00

fix(secrets): remove Honcho Redis password from container argv #124

claude referenced this issue

2026-05-09 23:54:00 +02:00

test(verify): cherry-pick L4-Verify suite to main (fix #123 base_ref oversight) #137

codex referenced this issue

2026-05-10 00:14:39 +02:00

test(verify): add l4 prompt waivers #139

codex commented

2026-05-10 00:19:00 +02:00

Collaborator

Role: executor
Intent: execute
Needs owner: no

Picking up as codex per operator Packet O retry after honcho-redis redeploy. Scope: #100 only, edit modules/honcho-redis/module.yaml only, with runtime sanity check that Config.Cmd no longer carries the Redis password before cataloging.

Next: verify runtime image/persistence, update manifest, run validation, open PR as codex.

**Role:** executor **Intent:** execute **Needs owner:** no Picking up as codex per operator Packet O retry after honcho-redis redeploy. Scope: #100 only, edit `modules/honcho-redis/module.yaml` only, with runtime sanity check that `Config.Cmd` no longer carries the Redis password before cataloging. **Next:** verify runtime image/persistence, update manifest, run validation, open PR as codex.

codex commented

2026-05-10 00:20:19 +02:00

Collaborator

Role: executor
Intent: checkpoint
Needs owner: yes

Packet O stopped before manifest edits.

Sanity evidence from RS 2000, sanitized:

Config.Cmd still contains requirepass.
The requirepass argument has length 48, has no $, no slash/path, no shell substitution, and is alnum-ish. I did not print the value.
unauth PING returns NOAUTH, so Redis auth is active.
The redacted command shape includes --appendonly yes --save 60 1, so the original sidecar-bound assumption is not safe; this runtime appears persistent/stateful unless operator decides otherwise.

Per Packet O stop conditions, I did not edit modules/honcho-redis/module.yaml and did not open a PR.

Next: operator/orchestrator should decide whether to rework the RS 2000 compose hotfix so requirepass is not a raw argv argument, and whether #100 should catalog honcho-redis as stateful instead of sidecar-bound after a proper authenticated persistence check.

**Role:** executor **Intent:** checkpoint **Needs owner:** yes Packet O stopped before manifest edits. Sanity evidence from RS 2000, sanitized: - `Config.Cmd` still contains `requirepass`. - The `requirepass` argument has length 48, has no `$`, no slash/path, no shell substitution, and is alnum-ish. I did not print the value. - `unauth PING` returns `NOAUTH`, so Redis auth is active. - The redacted command shape includes `--appendonly yes --save 60 1`, so the original `sidecar-bound` assumption is not safe; this runtime appears persistent/stateful unless operator decides otherwise. Per Packet O stop conditions, I did not edit `modules/honcho-redis/module.yaml` and did not open a PR. **Next:** operator/orchestrator should decide whether to rework the RS 2000 compose hotfix so `requirepass` is not a raw argv argument, and whether #100 should catalog `honcho-redis` as `stateful` instead of `sidecar-bound` after a proper authenticated persistence check.

codex referenced this issue from a pull request that will close it,

2026-05-10 00:29:11 +02:00

feat(modules): catalog honcho-redis v2 #140

pdurlej closed this issue

2026-05-10 00:47:53 +02:00

codex referenced this issue

2026-05-24 19:50:32 +02:00

docs(secrets): record Honcho Redis argv leak closure #441

codex referenced this issue

2026-05-24 19:50:47 +02:00

fix(secrets): remove Honcho Redis password from container argv #124