disinto-admin/disinto-ops

Fork 0

architect: website observability wire-up #10

Merged

disinto-admin merged 2 commits from architect/website-observability-wire-up into main

2026-04-15 17:38:11 +00:00

architect-bot commented

2026-04-08 20:04:45 +00:00

Collaborator

What this sprint enables

After this sprint, disinto.ai becomes an observable addressable: the planner
reads daily engagement evidence and the factory can close the build→ship→learn loop.

This unlocks two blocked milestones:

Adoption: Landing page communicating value proposition (evidence confirms it's reaching people)
Ship (Fold 2): Engagement measurement baked into deploy pipelines (verify-observable becomes non-advisory)

What already exists

The design is done. site/collect-engagement.sh is complete and parses Caddy JSON
access logs into dated evidence JSON. run-publish-site.toml already has a
verify-observable step. The evidence architecture is documented. Only the wiring
is missing.

What this sprint adds (3 sub-issues)

Enable structured JSON access logging in Caddyfile template (lib/generators.sh)
and document the manual step for the existing production host Caddy.
Add a format-detection guard to collect-engagement.sh so it fails loudly
(not silently empty) if Caddy isn't writing JSON logs.
Create evidence/engagement/ directory in ops repo setup (lib/ops-setup.sh)
and register the collect-engagement cron job in factory setup.

Complexity

3 sub-issues, ~85% gluecode. No new services or agents. One cron entry on the production host.

Risks

Production Caddy is a separate host from the factory's edge container — manual step required for existing deployment.
Log format mismatch produces silent empty reports — mitigated by guard in sub-issue 2.

Reply ACCEPT to proceed with design questions, or REJECT: <reason> to decline.

## What this sprint enables After this sprint, disinto.ai becomes an **observable addressable**: the planner reads daily engagement evidence and the factory can close the build→ship→learn loop. This unlocks two blocked milestones: - **Adoption:** Landing page communicating value proposition (evidence confirms it's reaching people) - **Ship (Fold 2):** Engagement measurement baked into deploy pipelines (verify-observable becomes non-advisory) ## What already exists The design is done. `site/collect-engagement.sh` is complete and parses Caddy JSON access logs into dated evidence JSON. `run-publish-site.toml` already has a `verify-observable` step. The evidence architecture is documented. Only the wiring is missing. ## What this sprint adds (3 sub-issues) 1. Enable structured JSON access logging in Caddyfile template (`lib/generators.sh`) and document the manual step for the existing production host Caddy. 2. Add a format-detection guard to `collect-engagement.sh` so it fails loudly (not silently empty) if Caddy isn't writing JSON logs. 3. Create `evidence/engagement/` directory in ops repo setup (`lib/ops-setup.sh`) and register the collect-engagement cron job in factory setup. ## Complexity 3 sub-issues, ~85% gluecode. No new services or agents. One cron entry on the production host. ## Risks - Production Caddy is a separate host from the factory's edge container — manual step required for existing deployment. - Log format mismatch produces silent empty reports — mitigated by guard in sub-issue 2. --- Reply `ACCEPT` to proceed with design questions, or `REJECT: <reason>` to decline.

architect-bot added 1 commit 2026-04-08 20:04:46 +00:00

sprint: add website-observability-wire-up.md 326ebb867a

disinto-admin approved these changes 2026-04-09 05:07:22 +00:00

Dismissed

disinto-admin left a comment

Owner

absolutely necessary proposal. the caddy is on another host. it should be addressed by a dispatchable container with ssh key as secret, that container has a script or an agent that dials in and get's the logs/stats.

dev-bot commented

2026-04-11 23:20:44 +00:00

Collaborator

ACCEPT: PR is approved via formal review since 2026-04-09. Operator triggering manual architect run for end-to-end test of the questions-phase code path.

architect-bot added 1 commit 2026-04-12 00:58:09 +00:00

sprint: add design forks for website-observability-wire-up 75f06bd313

architect-bot dismissed disinto-admin's review 2026-04-12 00:58:09 +00:00

Reason:

New commits pushed, approval review dismissed automatically according to repository settings

architect-bot commented

2026-04-12 00:58:30 +00:00

Author

Collaborator

Design forks — 3 questions

Sprint spec updated with full analysis. Incorporating your feedback: dispatchable container with SSH key as secret that dials into the Caddy host.

Q1: What does the container fetch from the Caddy host?

A) Fetch raw log, process locally — SSH in, copy today's access log, run collect-engagement.sh inside the container. Caddy host stays dumb. (recommended)
B) Run script remotely — SSH in, execute the script on the Caddy host. Requires deploying the script there.
C) Pull Caddy metrics API — SSH tunnel to Caddy admin API (port 2019). Less data than full log analysis (no referrers, no per-page).

Q2: How is the daily collection triggered?

A) Direct cron in edge container — Like supervisor/planner. Simple, no vault overhead. (recommended)
B) Vault action with auto-dispatch — Vault-gated. Depends on PR #12 (blast-radius tiers) for auto-approval, otherwise needs daily human approval.
C) Supervisor-triggered — Supervisor detects stale evidence and dispatches. Reactive, not scheduled.

Q3: How is the SSH key provisioned?

A) Factory operator's SSH keys — mounts: ["ssh"]. Simple but broad access.
B) Dedicated purpose-limited key — New keypair, command= restriction on Caddy host (only allows log read). Stored in .env.vault.enc. Least privilege. (recommended)
C) Edge tunnel reverse path — Caddy host pushes logs in via reverse tunnel. Inverts direction, requires agent on Caddy host.

Reply with your choices, e.g.:

Q1: A
Q2: A
Q3: B

## Design forks — 3 questions Sprint spec updated with full analysis. Incorporating your feedback: **dispatchable container with SSH key as secret** that dials into the Caddy host. --- ### Q1: What does the container fetch from the Caddy host? - **A) Fetch raw log, process locally** — SSH in, copy today's access log, run `collect-engagement.sh` inside the container. Caddy host stays dumb. *(recommended)* - **B) Run script remotely** — SSH in, execute the script on the Caddy host. Requires deploying the script there. - **C) Pull Caddy metrics API** — SSH tunnel to Caddy admin API (port 2019). Less data than full log analysis (no referrers, no per-page). ### Q2: How is the daily collection triggered? - **A) Direct cron in edge container** — Like supervisor/planner. Simple, no vault overhead. *(recommended)* - **B) Vault action with auto-dispatch** — Vault-gated. Depends on PR #12 (blast-radius tiers) for auto-approval, otherwise needs daily human approval. - **C) Supervisor-triggered** — Supervisor detects stale evidence and dispatches. Reactive, not scheduled. ### Q3: How is the SSH key provisioned? - **A) Factory operator's SSH keys** — `mounts: ["ssh"]`. Simple but broad access. - **B) Dedicated purpose-limited key** — New keypair, `command=` restriction on Caddy host (only allows log read). Stored in `.env.vault.enc`. Least privilege. *(recommended)* - **C) Edge tunnel reverse path** — Caddy host pushes logs in via reverse tunnel. Inverts direction, requires agent on Caddy host. --- Reply with your choices, e.g.: ``` Q1: A Q2: A Q3: B ```

disinto-admin commented

2026-04-12 06:30:01 +00:00

Owner

Q1: A
Q2: A
Q3: B

Q1: A Q2: A Q3: B

architect-bot commented

2026-04-14 20:05:17 +00:00

Author

Collaborator

Sprint filed

Answers: Q1=A (fetch raw log, process locally), Q2=A (direct cron), Q3=B (dedicated purpose-limited key)

Sub-issues on disinto repo:

#745 — collect-engagement formula + container script
#746 — format-detection guard in collect-engagement.sh
#747 — evidence/engagement/ directory + ops-setup wiring
#748 — rent-a-human instructions for Caddy host SSH key setup

Merging sprint spec.

## Sprint filed Answers: Q1=A (fetch raw log, process locally), Q2=A (direct cron), Q3=B (dedicated purpose-limited key) Sub-issues on disinto repo: - #745 — collect-engagement formula + container script - #746 — format-detection guard in collect-engagement.sh - #747 — evidence/engagement/ directory + ops-setup wiring - #748 — rent-a-human instructions for Caddy host SSH key setup Merging sprint spec.

architect-bot commented

2026-04-14 20:06:01 +00:00

Author

Collaborator

Note: merge requires additional approvals beyond architect-bot permissions. Sub-issues are filed and ready on the disinto repo (#745-#748). Please merge when ready.

architect-bot commented

2026-04-15 02:08:25 +00:00

Author

Collaborator

Sprint is fully processed (sub-issues #745-#748 filed, 2/4 already closed). This PR just needs a human approval + merge to persist the sprint spec in sprints/.

Sprint is fully processed (sub-issues #745-#748 filed, 2/4 already closed). This PR just needs a human approval + merge to persist the sprint spec in `sprints/`.