The four contract pages describe a target state. Substantial parts of it are not built. This page is the sequenced backlog: what is missing, which repository owns it, what it blocks, and how you know it is done. Without this, the contracts read as descriptions of a system that exists — which would be false, and would waste the time of any agent that went looking for the pieces.
Reading rule: a contract page states the rule; this page states whether the rule currently has an implementation behind it. Where they disagree, the contract is the intent and this page is the truth.
v1.0.0 and the live plane)| Capability | State |
|---|---|
| Fleet telemetry, log aggregation, alerting, dashboards | Built: 46 alert rules, 18 dashboards, and an agent plus container-meta sidecar on all six hosts. Per-container and per-service resource attribution was added 2026-10-11. |
| External capture (Google/Bing/Yandex, Cloudflare, IndexNow, URL Inspection) | Built |
| One push feed (search visibility → Wikantik) | Built — idempotent, backfillable, scoped credential |
| One full product loop (Content Intelligence) | Built — sense → signal → decide → act → measure |
| Conformance checking | Phase 0 — script landed; not yet run in continuous integration |
| Structured JSON logs | Partial. ECS is the stack logging standard (SA-6, 2026-10-12). Wikantik already emits ECS JSON, but it lacks service.name and trace.id and uses non-ECS MDC key names. Roller is plain text. See the telemetry contract. |
| Alert → runbook binding | Built. All 46 alerts carry runbook: Incident<AlertName>, enforced by jakemon's commit gate. All 42 pages exist on this wiki, tagged incident-runbook with an alert: field, and bin/runbook-check.sh verifies each label resolves. |
| Deployment identity on metrics and logs | Partial. deployment (one value per stack) and host are on every agent-shipped series and stream. Built for the running products: service and service_instance="<product>-<env>" (SA-5). Live since 2026-10-12: wiki-prod (docker1, metrics and logs), crafter-prod (docker2, metrics and logs), roller-prod (docker2, logs only, because Roller has no /metrics yet), and wiki-dev and crafter-dev (minisforum, logs). |
| Customer outreach on Roller | In Progress. Roller v0.2.0 live on docker2 with agent accounts and API tokens. Reselling weblog configured. Blogger-agent migration to native Roller publisher in flight (SA-INIT-01, SA-7). |
| Cross-repo agent coordination | Built. SimpleAgilityAgentCoordination live with Active Initiatives Ledger; standard repo headers defined (SA-9). |
| Project-scoped session briefings | Built 2026-10-24 (SA-13). get_briefing(clusters=["<project cluster>"]) returns the project's pages, then the contracts the project cites, then out-of-project pointers; Stockroom gained its own cluster and hub. |
| Stockroom-to-Roller customer spotlight flow | Queued. Operator-assisted "Feature on Blog" flag in Stockroom intake and pricing (SA-INIT-02, SA-8). |
| Small business accounting component | Queued. Decoupled from WealthView; scheduled for post-inventory/posting phase (SA-INIT-04, SA-10). |
| Generic aggregate-and-ship (a second feed without bespoke code) | Not built |
| Plane agent read surface (MCP) | Not built. Unblocked: it belongs in jakemon (SA-4). |
| Agent runtime (ledger, breakers, blast radius, identities) | Not built |
| Operational Data Store + SLO/SLA KPIs | Not built |
| Roller loop | Not built — blocked on the two feed items |
Cheap, unblocks argument-free conformance, and every later phase leans on it.
| Item | Owner | Acceptance |
|---|---|---|
| Conformance script | Wikantik repo — bin/simple-agility-conformance.sh | Exits 0 against a live Wikantik for health + metrics; log checks SKIP without a source and FAIL on plain text |
| Run it in continuous integration | Wikantik repo | A telemetry regression fails a build rather than being noticed months later |
| Incident-runbook convention documented | wiki | Convention published on SimpleAgilityOnCallAutomation — done |
The log standard is ECS (SA-6). The step-by-step work for each team, with checkboxes, is on SimpleAgilityTelemetryAdoption; this table tracks state. Wikantik's lines are already ECS JSON, but they carry no trace.id. Until this lands, cross-product tracing is a promise, and the on-call agent would be diagnosing from prose log lines.
| Item | Owner | Notes | Acceptance |
|---|---|---|---|
| Wikantik → full ECS | Wikantik repo | Appender and filter configuration, not an application rewrite. It needs three changes: emit service.name=wikantik (replacing application); rename the request filter's MDC keys to ECS (requestId to transaction.id, plus http.request.method, url.path, client.ip, user_agent.original); add trace.id. | Conformance script's log checks PASS against prod logs |
Honor inbound traceparent, then X-Correlation-Id; propagate both | Wikantik repo | Wikantik mints a request identifier today but does not accept one | A request carrying traceparent produces log lines whose trace.id is that trace-id |
| Product-instance identity on metrics and logs | jakemon | Done 2026-10-12. Live since 2026-10-12: wiki-prod (docker1, metrics and logs), crafter-prod (docker2, metrics and logs), roller-prod (docker2, logs only, because Roller has no /metrics yet), and wiki-dev and crafter-dev (minisforum, logs). Earlier state: deployment (the whole stack) and host have been attached by every agent since 2026-08-18. The product-instance label is service_instance="<product>-<env>", alongside service (SA-5). The labels are set per target in apps.alloy, and on log streams through its discovery.relabel "products" hook. Roller gains them on metrics when it exposes /metrics. | {service_instance="wiki-prod"} selects exactly production Wikantik's series and log streams |
| Settle the log key names | this wiki | Done 2026-10-12. ECS is the standard, and the old envelope is retired (SA-6). | The contract specifies ECS fields |
| Conformance script checks ECS | Wikantik repo | Its log checks still test ts, level, service and msg | Log checks PASS on an ECS line carrying the four required fields, and FAIL on plain text |
| Roller emits ECS from day one | Roller repo | log4j2 JsonTemplateLayout with the bundled EcsLayout.json template. Greenfield, so no migration. | Conformance script exits 0 |
Deliberately deferred: ingest-time stage.json in Alloy. Query-time | json works now; add ingest-time extraction only when query volume justifies it, and never promote per-request fields to Loki labels.
Roller is the canonical customer communication platform (SA-7). This phase transitions the agent publishing system off third-party Google Blogger and onto Roller's native agent interfaces.
| Item | Owner | Notes | Acceptance |
|---|---|---|---|
| Roller reselling weblog created | Roller (roller-prod) | Weblog dedicated to reselling spotlights, collector guides, and estate finds. | Weblog resolves and accepts drafts under the reselling handle |
Roller publisher client in blogger-agent | blogger-agent | Python client using Roller API tokens over REST / /api/mcp (RollerMcp). | A sample post drafts, stages, and verifies via Roller API tokens without Google OAuth |
| Blog skills refactored to Roller | blogger-agent | publish_to_blogger refactored to publish_to_roller with metadata, tags, and summary. | Publishing skill executes end-to-end to Roller |
Notable inventory items from Stockroom are promoted to customer-facing blog posts through an operator-assisted workflow (SA-8).
| Item | Owner | Notes | Acceptance |
|---|---|---|---|
| "Feature on Blog" operator flag in Stockroom | stockroom | Flag or action button on intake and pricing screens for notable collectibles or high-value books. | Stockroom item payload includes photos, description, and eBay URL |
| Spotlight staging bridge | blogger-agent / stockroom | Reads flagged items and stages drafted spotlight articles in Roller draft queue. | Flagging an item creates a staged draft in Roller awaiting final operator approval |
The jakemon side of this phase is done: every alert is labelled, every label resolves to a page, and since 2026-10-24 every alert carries deployment.
| Item | Owner | Acceptance | |
|---|---|---|---|
runbook label on every alert rule | jakemon | Done. bin/validate.sh rejects a rule without one; all 46 are labelled. | |
| Incident runbooks for the failure modes those alerts cover | jakemon (docs/runbooks/, published here) | Done. 42 pages, one per alert name. Written 2026-09-20 to 10-08; incident-runbook and alert: were added 2026-10-11. bin/runbook-check.sh passes. | |
service / service_instance labels on alerts | jakemon | Done 2026-10-24. Alerts on agent-shipped series carry host, deployment and job. Alerts on product series (up{job="wikantik"}, crafter_*) inherit service and service_instance from the series. Alerts on the central stack's own scrapes now carry deployment too: central Prometheus sets it as an external label, from the same JAKEMON_DEPLOYMENT the agents use. Alerts that are not about a product (host, fleet, central) carry no service, by design. | An alert identifies which product instance it concerns |
Write the runbooks with the labels — a label pointing at a page that does not exist is worse than no label, because it reads as a working binding.
The agent must be able to ask the plane things, not scrape HTTP by hand.
| Item | Owner | Acceptance |
|---|---|---|
| jakemon MCP server — alert state, PromQL, LogQL, dashboard links, read-only | jakemon | An agent answers "is this firing, and what do the logs for this trace.id say?" through tools |
| Alertmanager webhook receiver aimed at the runtime | jakemon | A firing alert reaches an endpoint with labels and annotations intact |
Resolved 2026-10-12 (SA-4). jakemon's rule of no application code has one exception: an application that serves the whole stack and belongs with the plane. The read-only query server is that application, so it lives in the jakemon repository. The agent runtime (phase 4) is not covered, and it stays a separate stack-level component.
The stack-level component that hosts every acting agent. It is the safety layer, so it lands before autonomous action, not after.
| Item | Acceptance |
|---|---|
| Scheduling + action ledger | Every agent action is attributable, with rationale and outcome |
| Circuit breakers + blast-radius limits | "N actions per hour per service"; "one page per run" enforced, not documented |
| Per-role agent identities with scoped grants | On-call and SEO actuator hold different accounts; neither holds AllPermission |
| Human-oversight policy switch per escalation rung | Rung 3 pages a human concurrently; wait-for-acknowledgment is configurable |
| On-call agent v0 — diagnose and report only, no actions | It reaches a correct diagnosis on a real alert before it is allowed to act |
The SEO actuator (sub-project B of the older jakemon SEO-loop design) belongs here too, and its measurement rails already exist in Wikantik's EffectEvaluator.
| Item | Owner | Acceptance |
|---|---|---|
Generalize aggregate-and-ship out of ship_visibility.py | jakemon | A new feed is configuration plus a row-shape, not a new hand-written shipper |
feed / feed_version envelope on the wire | jakemon + consuming products | An additive plane change deploys without a lock-step product release |
| Roller engagement feed | jakemon | Per-post/per-send opens, bounces, replies land in a Roller table |
Availability, latency and error budgets per service and per tenant, computed once by the plane. Needs Phase 1 (trustworthy inputs) and Phase 5 (a way to ship the results). No product computes an SLO in the meantime — it waits.
The second product loop, following SimpleAgilityFeedbackLoopPattern: tables for the shipped feeds, the joins, ranked opportunities with a suppression list, a scoped write surface, prediction-and-effect measurement.
simple-agility. Permanently out of scope.traceparent (Phase 1) is the on-ramp; adopting the full stack is not planned and should not be assumed.