Repository navigation
Two stranded artifacts: self-hosted-stack.yaml (354 lines, deployed nowhere) and lambda/alert-handler (builds in CI, runs nowhere) #783
Description
Found while mapping the infra account for docs/infra-account.md. Two artifacts
that are built and maintained but reach nothing — and one of them is relevant to
#780 rather than merely unused.
deployment/cloudformation/self-hosted-stack.yaml — 354 lines, deployed nowhere
Declares the data layer for a self-hosted deployment:
4 AWS::Logs::LogGroup
4 AWS::DynamoDB::Table
2 AWS::S3::Bucket
1 AWS::IAM::Role
2 parameters
- No functions. It creates the stores a self-hosted spawn would need and
nothing that runs. - Referenced by nothing — no Makefile target, no script, no doc, no other
template. - Deployed in neither account (
list-stacksfor*self-host*: 0 in
966362334030 and 435415984226).
This is the most interesting part: it looks like an earlier attempt at exactly
what #780 describes — an institution standing up its own spore.host
infrastructure. Whoever picks up #780 should know it exists, either as prior art
worth resuming or as a dead end worth deleting. Leaving it unlabelled is the
worst of the three.
lambda/alert-handler/ — builds in CI, runs nowhere
- No live function in either account, under any name.
- It is mentioned by the stack above, but only as a log group
(/spawn/alert-handler) — the stack never declares the function. - It is in
.github/dependabot.yml, so its dependencies are maintained, and the
nested-module CI loop builds, vets and tests it on every PR.
So it consumes CI time and dependency churn on every change to the repo while
reaching nothing. spawn-alert-evaluator is live and does the alert evaluation,
which suggests this was either superseded or never finished.
Why this is worth a decision rather than a shrug
Both are the same shape as the findings in #653 and #654: not expensive, but
indistinguishable from working code to anyone reading the repo. Someone
modifying the alert path would reasonably assume alert-handler runs. The cost
is misleading a future reader, not dollars.
Suggested
- Decide what
self-hosted-stack.yamlis — prior art for Future: deploy your own spore.host infra account (the whole control plane, not just the reaper) #780, or delete.
If it is prior art, say so in a comment at the top of the file and link Future: deploy your own spore.host infra account (the whole control plane, not just the reaper) #780,
because an unreferenced template with no deploy path reads as abandoned. - Decide what
alert-handleris — finish, or delete. If it is a deliberate
placeholder for the self-hosted stack, the stack should declare the function
so the two agree. - Either way, record the answer in
docs/infra-account.md, which currently just
reports that neither is deployed.
Related: #780 (self-hosted deployment — the context that makes the stack
interesting), #653 (nothing reaps the control plane), the infra-account map in
#782.
Activity
scttfrdmn commentedon Oct 10, 2026
Evidence gathered before deciding, since both items turned on intent. Two of the
three framings in this issue change.
self-hosted-stack.yamlis initial-commit scaffolding, not iterated prior artOne commit, the first one. It has never been edited since the repo began. So
"prior art worth resuming" overstates it — nobody ever developed this; it was
sketched on day one and left. That lowers the cost of deleting it and lowers the
value of keeping it, but it is still a 354-line starting point for exactly what
#780 describes. The call is still yours; it is just a cheaper call than it looked.
alert-handlerwas not superseded — it is the missing half of a shipped featureThis is the part that changes.
alert-handleris not a duplicate of the livealert-evaluator:alert-evaluator(live, hourly)spawn-alert-preferences,spawn-cost-historyCOST_ALERTS_TOPIC_ARNalert-handler(deployed nowhere)spawn-alerts, writesspawn-alert-historyThe evaluator never reads
spawn-alerts. Andspawn alerts create <sweep-id>—a shipped CLI command — writes to
spawn-alertsand validates all five triggers.So
spawn alerts createsucceeds and no alert can ever fire, andspawn alerts historyis permanently empty.spawn validate --infrastructurealready reports the missing function as a hard error against the live account
today. Filed as #790 with the full trace, including two further defects in that
same command.
Its history matches: every commit touching
lambda/alert-handler/since theinitial one is mechanical — CVE bumps, Go version standardisation, a test
migration. No functional work, ever.
What this means for the decision
Deleting
alert-handleris no longer a tidy-up; it is removing a feature theCLI advertises. The options are now:
spawn alerts, and the self-hosted stack's/spawn/alert-handlerlog group starts making sense.spawn alertsCLI surface together — honest, and thecost path keeps working via
alert-evaluator.spawn alertsstops acceptingalerts it cannot deliver, which is spawn validate --infrastructure reports 2 errors against the real infra account; one is false, one means
spawn alertsis a dead surface, and the remediation names a command that does not exist #790's point 2 regardless.Option 3's caveat is a bug in its own right and does not need this decision made
first. 1 vs 2 is a product call.
fix(validate): stop reporting a deployed Lambda as missing, and point…
fix(alerts): refuse an alert that cannot be delivered (#790) (#793)
remove: the spawn alerts path and the stranded self-hosted stack (#783)…
remove: alert-evaluator and the dashboard's alert-preferences endpoin…