Proposal: rebuilding infra from scratch

[Zaba505]

Note

Revision 3 records that wave 0 is done, and wave 1 starts. Stories #971 to #977 landed the backlog loop's setup, the required Build check and the reset. Wave 1's proposals are the rebuild entry point, definitions, values and secrets, drills, infrastructure modules and platform topology. Definitions and drills also build on infrastructure modules and platform topology, and infrastructure modules owns a module's tests.

Note

Revision 2 answers the last open question: the engagement process between the operator and capability owners is out of scope. #750, #771, #778, #780 and #781 go with it. The charter has no open questions left, so the standalone stories and the reset can be written.

Note

Revision 1 answers open questions 1, 3, 4 and 5, and adds a sketch of the docs site's layout. Learning is a valid reason to build, and building includes self-hosting an open-source project. Personal media storage is a new feature proposed after this charter, so wave 7 is the canary tenant alone, and the charter is done once the base platform is designed and deployed. The Hugo site stays: the reset leaves a skeleton, and each proposal fills in its part as it's implemented. The license is MIT, with Zaba505 as the copyright holder. Question 2 is still open, and the revision restates it. The rest of this post is unchanged.

Note

This is the charter for rebuilding infra from scratch. It proposes what infra is, the rules every change is held to, what happens to everything in the repository today, and the order in which the proposals are discussed. Each part of the platform is proposed in its own discussion, and stories are written only from accepted proposals.

Summary

infra has spent six months producing decisions without a platform to show for them. Since April, 26 commits of capability docs have produced four accepted ADRs and 31 open issues for more. The last change to code was #638, on 2026-04-18.

This proposal stops that process and starts over, the way z5labs/humus#629 rebuilt humus and z5labs/bedrock#553 rebuilt bedrock:

• one story resets main to a tree with no platform code in it;
• the platform comes back one part at a time, each part proposed in a discussion of its own;
• accepted proposals become stories, and the backlog loop implements and merges them.

The four accepted ADRs aren't thrown away. Each one becomes the background of the wave-1 proposal that takes it over.

Why start over instead of porting

• The process produces documents, not a platform. Each decision goes through a capability, business requirements, technical requirements, a planned ADR and then the ADR itself, before any design or code. Four decisions have made it through in six months, and 31 are queued.
• The requirements describe more process than platform. Over a third of the 54 live technical requirements specify threads, issue types, rollouts, and eviction and retention rules between the operator and capability owners. Today the operator is the only capability owner.
• The code has no entry point. ADR-0004 decided that one orchestrator rebuilds the platform phase by phase, with drills. Nothing in cloud/ or services/ is built that way. The modules are applied from Zaba505/homelab one resource at a time, with a module ref typed into a workflow dispatch by hand (ADR-0003).
• Nothing deployed is kept. The operator is removing every existing cloud resource by hand, and Zaba505/homelab is out of scope. No definition in this repository has anything left to manage, so a port would keep code with nothing to run against.
• The tooling serves the old process. .claude/skills holds nine skills that implement the capability pipeline: 717 files, 659 of them eval workspaces. .github holds an agent and a prompt for the same process, and Copilot instructions for code the reset deletes. Discussions, stories and the backlog loop replace all of it.

What infra is

infra defines a self-hosted application platform: the place the operator's own capabilities run by default, so that none of them depends on a vendor's hosting product. This section condenses the platform capability:

• It's rebuilt, not repaired. The platform can be stood up from nothing, from this repository, in at most 60 minutes.
• It's self-hosted, not self-owned. It spans a public cloud and the home lab. "Self-hosted" means the operator controls it end to end, not that every part runs on hardware the operator owns.
• It's run by one operator, in at most 2 hours a week. A designated successor holds sealed credentials and uses them only if the operator can't.
• Its tenants are the operator's capabilities. Their end users reach the tenants, never the platform.

This replaces the capability, business-requirements, technical-requirements and user-experience pages. Proposals cite those pages by permalink when they need a detail.

Principles

1. One entry point. One command stands the platform up from nothing, on a workstation or in CI.
2. Definitions, not memory. Everything the platform is lives in this repository or in the values a rebuild is given. Nothing is set up by hand, and every tool a rebuild runs is pinned.
3. Drillable whole. Every phase runs against scratch targets before it runs against the live platform. Every proposal shows its drill, as every humus proposal shows a test of its whole App.
4. Public definitions, private values. This repository is public, and holds no secrets and no environment's real values.
5. Fail closed. A rebuild that finds state it can't explain, or a check that fails, stops. It never carries on with a guess.
6. One operator. Only the operator administers the platform, and every administrative interface rejects everyone else.
7. Within budget. A design that needs more than the 2-hour weekly budget is simplified, not adopted.

Engineering rules

These are enforced in CI rather than by review:

• One required check. A workflow named Build runs every check below, and the default ruleset requires it. The verify commands in .claude/backlog.json run the same checks.
• Infrastructure definitions are checked and tested. Every module passes its tool's format check, validation and a linter, and has tests that run without real credentials. The tool and the linter are chosen in Proposal: infrastructure modules.
• Go code is held to humus's rules. golangci-lint runs with bedrock's forbidigo list, on test code too. Tests assert with testify/require. CI fails when a library package drops below 80% statement coverage. A service the platform runs that is written in Go is a humus app.
• The docs site builds on every pull request that touches it.
• Every vendor and third-party component is justified in the proposal that adds it. The operator must control its configuration, be able to export its data, and be able to revoke its credentials.

Inventory

Today	Proposal	Discussed in
cloud/: 13 Terraform modules for GCP and Cloudflare	deleted; each module comes back with the phase that needs it, to conventions decided once	Proposal: infrastructure modules, and each phase proposal
services/machine and pkg/errorpb: a machine registry on Firestore, with problem details over protobuf	deleted; whether hosts need a registry is decided with network boot	Proposal: home-lab hosts
services/lb-sink: a stub that prints hello	deleted	(none)
ADR-0001, cross-environment topology, and ADR-0002, tenant placement	reaffirmed or revised	Proposal: platform topology
ADR-0003, the definitions repository	re-decided without Zaba505/homelab	Proposal: definitions, values and secrets
ADR-0004, the rebuild orchestrator and phase model	taken over	Proposal: the rebuild entry point
The platform capability, with its business requirements, technical requirements and seven user experiences	condensed into What infra is; cited by permalink	this charter
The personal media storage capability and its seven user experiences	the background for the first tenant	Proposal: personal media storage
r&d/analysis: network boot, Matchbox, server operating systems, the HP DL360, UDM Pro VLANs and WireGuard	deleted; cited by permalink	Proposal: home-lab hosts; Proposal: operations tunnel
r&d/services: API pages for the boot and machine services	deleted with the services	(none)
physical_infrastructure: the hardware	kept	Proposal: home-lab hosts updates it
.claude/skills, and .github's agents, prompts, instructions and copilot-instructions.md	deleted	(none)
34 open issues, milestones 00 to 08, and the project's Area field	closed or removed by the reset; each issue's topic goes to a proposal, below	the reset

Where today's open issues go

The reset closes them all. Their topics go here:

Proposal	Takes
the rebuild entry point	#758, preflight drift detection
operator access	#762, operator authentication; #770, sealed-successor credentials
tenant compute	#752, the compute runtime; #759, the packaging form; #772, one-shot jobs; #776, declaring a tenant's needs
tenant storage	#753, raw persistent storage; #757, object storage
tenant networking	#754, external reachability; #755, internal networking
end-user identity	#756, platform-provided identity; #761, bringing your own
tenant secrets	#763, the secret-management offering; #764, secret references
backup, restore and export	#760, backup and DR; #774, deletion; #779, the export tool
observability	#765, #766, #767, #768, #769, #773 and #775
canary tenant	#777
out of scope, if open question 2 agrees	#750, #771, #778, #780 and #781
none: their skills and pages are deleted	#728, #730 and #836

Reset strategy

Two standalone stories land first, outside the waves:

• The backlog loop's setup: .claude/backlog.json, the auto-merge workflow and its labels, and the backlog plugin enabled in .claude/settings.json.
• A required Build check. The default ruleset requires no status check today, so the merge label would land a pull request before anything had verified it.

Then comes the reset, as this charter's first story, written once its open questions are answered. It lands no code, so unlike humus's reset it doesn't wait for a wave-1 proposal. It leaves main with a tree that keeps only:

• a LICENSE (open question 5);
• README.md, rewritten to say what infra is and that it's being rebuilt, with a link to this charter;
• CLAUDE.md, rewritten for this workflow;
• renovate.json, .gitignore, .mcp.json and .vscode;
• .github/ISSUE_TEMPLATE/story.yaml;
• the Build, auto-merge, docs, docs-preview and CodeQL workflows;
• .claude/settings.json and .claude/backlog.json;
• the Hugo site's configuration, theme and go.mod, its home page, rewritten to link to this charter, and the physical infrastructure page.

It deletes everything else, terraform.yml included. Each part of the platform comes back through its own stories, at the path its proposal names.

Once the reset's pull request has merged:

• every open issue except Renovate's Dependency Dashboard (Dependency Dashboard #116) is closed as not planned, with a comment that links to this charter and says where its topic went;
• milestones 00 to 08 are closed;
• the Area field is removed from the infra project.

The reset is an ordinary squash merge. History stays, so every permalink in this charter keeps working.

From discussion to stories

1. Each proposal is a discussion in General titled "Proposal: …", with the sections Summary, Background, Proposed design, Design decisions, Drill, What it replaces, Open questions and Out of scope. It says where its files live in the repository.
2. Review happens in comments. A revised proposal is posted as a comment, and the body gets a note pointing to it.
3. An accepted proposal gets a milestone named Wave N: <proposal>, whose description links to the proposal and to this charter. A milestone groups one proposal's stories. Milestones no longer encode a delivery sequence: the waves do.
4. Stories are written from the accepted proposal, with the story label, in its milestone and on the infra project, and each links back to the discussion. A batch is created first and wired with native blocked by relationships in a second pass, so no story cites a sibling by number. Only then can the backlog loop pick them up.
5. At each wave boundary, this charter gets a revision that says which proposals are done, which stories landed them, and which wave starts.

Dependencies between the proposals

A proposal depends on another when its design builds on the other's. The waves follow from that:

• From wave 2 on, no proposal depends on another in its own wave, so each wave's proposals are discussed in parallel. In wave 1, definitions and drills build on the rebuild entry point while it's still being decided.
• A wave starts once every proposal it depends on is accepted.
• When a proposal moves to a later wave, every proposal that depends on it moves with it.
• There is no Later list. A proposal that defers something either names the wave it goes to, through a revision of this charter, or puts it out of scope.

Proposal	Wave	Depends on
the rebuild entry point	1	the charter
definitions, values and secrets	1	the rebuild entry point
drills	1	the rebuild entry point
infrastructure modules	1	the charter
platform topology	1	the charter
cloud anchor and edge	2	wave 1
operator access	2	wave 1
operations tunnel	3	cloud anchor and edge, whose network the tunnel ends in
home-lab hosts	3	cloud anchor and edge, whose endpoint hosts boot from
tenant compute	4	cloud anchor and edge, and home-lab hosts, since a tenant may be placed in either environment
tenant storage	5	tenant compute
tenant networking	5	tenant compute
end-user identity	5	tenant compute
tenant secrets	5	tenant compute
backup, restore and export	6	tenant storage
observability	6	tenant compute and tenant networking
canary tenant	7	every wave-5 and wave-6 proposal, whose offerings it exercises
personal media storage	7	the wave-5 and wave-6 proposals whose offerings it uses

Two points keep proposals in the same wave from depending on each other:

• Home-lab hosts doesn't decide how the operator reaches a host once it has booted. It names the seam the operations tunnel attaches to. If it finds that hosts need the tunnel to boot, it moves to wave 4.
• Each wave-5 offering is consumed by tenants through tenant compute's declaration, not through another offering. If one turns out to be hosted on another, such as identity keeping its data in tenant storage, it moves to wave 6.

The proposals and their order

• Wave 0: this charter.
• Wave 1, the foundations:
  • Proposal: the rebuild entry point. The one command that stands the platform up, starting from ADR-0004's Dagger module in Go. It decides the contract every phase meets (apply, verify and teardown), drill and live targets, the operator's checkpoints, the preflight drift check, and how a rebuild's duration is measured against the 60-minute target.
  • Proposal: definitions, values and secrets. Where each environment's values and the platform's own secrets live, how they reach a phase, and how the state backend bootstraps itself (phase 0). It takes over ADR-0003.
  • Proposal: drills. How a phase proves itself without touching the live platform: module tests without credentials, scratch cloud targets, virtual hosts on the home-lab LAN, and what runs in CI or only on a workstation.
  • Proposal: infrastructure modules. The IaC tool, and a module's shape, naming, provider pinning, versioning and tests.
  • Proposal: platform topology. Which environments the platform spans and how they connect: the edge, the public-cloud anchor, the home lab, the tunnel between them, the traffic each path carries, and where a tenant is placed. It reaffirms or revises ADR-0001 and ADR-0002.
• Wave 2, the cloud side, once wave 1 is accepted:
  • Proposal: cloud anchor and edge. Phase 1a: the public-cloud foundation, the edge in front of it, DNS, and the stable endpoint home-lab hosts boot from.
  • Proposal: operator access. How every administrative interface rejects anyone but the operator, and the sealed credentials a successor uses to take over.
• Wave 3, the home-lab side, once cloud anchor and edge is accepted:
  • Proposal: operations tunnel. Phase 1b: the tunnel the operator manages the home lab through.
  • Proposal: home-lab hosts. Phase 1c: network boot, the hosts' operating system, and how hosts are inventoried.
• Wave 4, the runtime:
  • Proposal: tenant compute. Phase 2's runtime: where a tenant's long-running components and one-shot jobs run, the one form a tenant is packaged in, and how a tenant declares what it needs.
• Wave 5, the tenant offerings, in parallel, once tenant compute is accepted:
  • Proposal: tenant storage. Persistent and object storage.
  • Proposal: tenant networking. Reaching a tenant from the internet through the edge, and tenants reaching each other.
  • Proposal: end-user identity. The identity offering, which must be able to refuse credential recovery, and how a tenant brings its own instead.
  • Proposal: tenant secrets. Where a tenant's secrets are kept and how its components refer to them.
• Wave 6, protecting and watching tenants:
  • Proposal: backup, restore and export. Phase 3's backup and recovery of tenant data, the export tool a tenant's users run without the operator, and deleting a departed tenant's data.
  • Proposal: observability. Phase 3's metrics, logs, traces, events, alerts and cost data, for the operator and for each tenant.
• Wave 7, tenants:
  • Proposal: canary tenant. Phase 4: the purpose-built tenant whose health is the rebuild's readiness signal, and its teardown.
  • Proposal: personal media storage. The first real tenant (open question 3).

Out of scope

• Zaba505/homelab. Nothing in this charter changes it or depends on it.
• Today's cloud resources. The operator removes them by hand, and no story touches them.
• The engagement process between the operator and capability owners, if open question 2 agrees: story(adr): engagement channel / tracker — self-hosted-application-platform #750, story(adr): post-eviction read-only enforcement — self-hosted-application-platform #771, story(adr): engagement-thread issue type catalog & schema — self-hosted-application-platform #778, story(adr): contract-change rollout dual-form & atomicity mechanism — self-hosted-application-platform #780 and story(adr): retention clock & pause-resume mechanism — self-hosted-application-platform #781.
• What the platform capability already excluded: hosting for anyone but the operator's own capabilities, an availability SLA, more than one operator, and self-service onboarding.
• AI tooling. The reset deletes it, and bringing any back is planned outside this charter.

Open questions

1. Is learning a valid reason to build? CLAUDE.md calls this repository "intentionally over-engineered for learning purposes". The platform capability says the opposite: skill development "must not influence buy-vs-build trade-offs", which are judged on convenience, resiliency and cost alone. Most phase proposals choose between building and buying, so the charter should say which rule they follow.
2. Is the engagement process out of scope? The issues listed under Out of scope would design threads, issue types, contract-change rollouts, and eviction and retention rules for capability owners. The proposal is to put them out of scope while the operator is the only capability owner.
3. Is the first tenant part of this charter? The proposal puts personal media storage in wave 7, because the platform capability ranks tenant adoption first: "a perfect platform with no tenants is a failure". The alternative is a new feature outside the waves, as humus treated Kubernetes controllers.
4. Does the Hugo site stay, documenting only what's built? The proposal is yes. Decisions live in the discussions, the site documents each part of the platform as it lands, and the MADR-format ADR pages don't come back.
5. Which license? The repository is public and has none. The proposal is MIT, like z5labs.

References

• Proposal: humus on the bedrock process model z5labs/humus#629, the charter this one follows
• story(repo): land the reset on main as a licensed, CI-green Go 1.27 module z5labs/bedrock#553, bedrock's reset, and Feature request: request-scoped failure injection (Netflix FIT) on OpenTelemetry baggage z5labs/bedrock#578, the discussion-first precedent
• The tree before the reset
• z5labs/devex, home of the backlog plugin that works the stories

[Zaba505]

Revision 1: answers to open questions 1, 3, 4 and 5

This revision applies the answers to four of the five open questions. Question 2 is still open, and is restated below with what it covers. Each section below replaces the section of the same name in the post, or says which part of it changes. Two sections are new: Building and buying, and Docs site. Everything else in the post is unchanged and still applies.

Decisions

#	Question	Decision
1	Is learning a valid reason to build?	Yes. Building doesn't only mean writing something from scratch. Self-hosting an open-source project, which takes learning and configuration, is building too.
2	Is the engagement process out of scope?	Still open, restated below.
3	Is the first tenant part of this charter?	No. Personal media storage is a new feature, proposed once the base platform is designed and deployed.
4	Does the Hugo site stay, documenting only what's built?	Yes. As in humus, the reset empties it, and each proposal documents its part while it's implemented. The layout is sketched up front, so pages don't pile up in the order they land.
5	Which license?	MIT, with Zaba505 as the copyright holder.

Building and buying

This section is new, and goes after Principles.

Every phase proposal chooses, part by part, whether to build or to buy:

• Buying is using a vendor's managed service.
• Building is running the part yourself, either by writing it or by self-hosting an existing open-source project.

Convenience, resiliency, cost and what the operator wants to learn are all valid reasons to build. This replaces the platform capability's rule that skill development "must not influence buy-vs-build trade-offs".

Whatever is built is still held to the principles. It's rebuilt from this repository within the 60-minute target, and run within the 2-hour weekly budget.

Inventory

Only these rows change. Every other row of the post's table stands.

Today	Proposal	Discussed in
The personal media storage capability and its seven user experiences	deleted; the background for personal media storage, a new feature proposed once this charter is done	(none in this charter)
physical_infrastructure: the hardware	moved by the reset to the Hardware page of The platform	Proposal: home-lab hosts updates it

Reset strategy

Two items in the list of what the reset keeps change. Everything else in the section stands.

• The license: a LICENSE with the MIT License, with Zaba505 as the copyright holder.
• The docs site: the Hugo site's configuration, theme and go.mod, and the skeleton described under Docs site. The skeleton is a home page and one landing page per section, with today's physical infrastructure page as the Hardware page of The platform.

Docs site

This section is new, and goes after Reset strategy.

humus's docs had to be restructured after its charter (z5labs/humus#1303):

• pages were added in the order their packages landed, so that's the order the sidebar read in;
• no page led to the next one;
• the home page was a log of the rebuild;
• pages ended with sections on migrating from code the reset had deleted.

This charter plans the layout up front instead, with these rules:

• The reset lands a skeleton. It has the sections below, in this order, and each has a landing page that says what its pages will cover and in what order. The order comes from the skeleton, never from the order pages land in.
• Each proposal documents its own part. A proposal's Documentation section names the pages it adds or changes and where they sit. It fills in its part of the sketch. It may change the sketch when its design calls for it, and the charter's next revision records the change.
• Pages are written while implementing. Each story writes or updates the pages for what it lands, so a story isn't done until its pages are.
• The site reads in order. Each page links to the next one in the reading order, and the last page of a section links to the first page of the next. A page's URL follows its place in the sidebar.
• Pages document the platform as it is. The home page is an overview of the platform, not a log of the rebuild. No page describes the tree before the reset, or how to move off it. While this charter is open, the home page has one line saying the platform is being rebuilt, with a link to this charter. The charter's last revision removes it.

The sketch reads in the order its readers need it. The operator comes first, then a successor who has to take over, then a capability owner bringing a tenant.

#	Section	Pages	Written by
1	Overview, the home page	what the platform is, its environments, and the reading order	the reset; platform topology adds the environments
2	Getting started	standing the platform up from nothing, first as a drill and then live	the rebuild entry point, with definitions, values and secrets, and drills
3	Fundamentals	Topology; The rebuild and its phases; Values and secrets; Drills; Infrastructure modules	each wave-1 proposal, one page each
4	The platform	one page per part, in rebuild order: Cloud anchor and edge; Operations tunnel; Home-lab hosts, with Hardware; Tenant compute; Backup and restore; Observability; Canary tenant	the proposal for each part
5	Operating	Access and succession; Routine maintenance; Running a drill; Restoring from backup	operator access, drills, and backup, restore and export; each phase proposal adds its routine work to Routine maintenance
6	Hosting a tenant	Packaging and declaring a tenant; Storage; Networking; Identity; Secrets; Exporting your data; Watching your tenant	tenant compute, each wave-5 proposal, backup, restore and export, and observability

From discussion to stories

Only the first item changes:

1. Each proposal is a discussion in General titled "Proposal: …", with the sections Summary, Background, Proposed design, Design decisions, Drill, Documentation, What it replaces, Open questions and Out of scope. It says where its files live in the repository, and Documentation says where its pages sit in the docs site.

Dependencies between the proposals

The personal media storage row is removed. Every other row and both points stand.

The proposals and their order

Only wave 7 changes, and the list gets an end:

• Wave 7, the readiness signal:
  • Proposal: canary tenant. Phase 4: the purpose-built tenant whose health is the rebuild's readiness signal, and its teardown.

This charter is done when the base platform is designed and deployed. That means every proposal in waves 1 to 7 is accepted and its stories have landed, and a live rebuild from nothing ends with the canary tenant reporting the platform ready. Personal media storage, like any other tenant, is then proposed as a new feature and gets no wave.

Out of scope

One item is added:

• Personal media storage, and every other real tenant. Each is a new feature, proposed once this charter is done.

Open questions

Questions 1, 3, 4 and 5 are answered. Question 2 is the only one left, restated:

2. Are the operator's workflows with capability owners out of scope? "The engagement process" means the paperwork around a tenant, not anything the platform runs. The platform capability's user experiences specify it, and over a third of the technical requirements derive from it:

   • every exchange happens on one append-only thread per event, with a typed issue for each of onboarding, modification, migration, forced update, contract change and eviction (TR-19, TR-20);
   • a forced update records the outside pressure behind it and the deadline that pressure sets, in one issue per event per tenant (TR-22);
   • a contract change is an umbrella issue that tracks each tenant's acknowledgement. At the deadline it removes the old offering, files an eviction issue for each tenant that didn't move, and closes itself, all at once (TR-24, TR-27);
   • an evicted tenant's data stays readable for 30 days, on a countdown the operator can pause, and is then deleted from every tier (TR-31, TR-33, TR-34);
   • a migration is rejected if its peak is over twice the tenant's steady state (TR-40), and onboarding can close as "lost to operator silence" (TR-51).

   story(adr): engagement channel / tracker — self-hosted-application-platform #750, story(adr): post-eviction read-only enforcement — self-hosted-application-platform #771, story(adr): engagement-thread issue type catalog & schema — self-hosted-application-platform #778, story(adr): contract-change rollout dual-form & atomicity mechanism — self-hosted-application-platform #780 and story(adr): retention clock & pause-resume mechanism — self-hosted-application-platform #781 would design it. With no real tenant in this charter, and the operator as the only capability owner, nobody would be on the other end of these threads. So the proposal is to put it out of scope.

   What the platform itself must do stays in its proposals. Backup, restore and export still owns exporting a tenant's data and deleting a departed tenant's data. If personal media storage needs any of the workflow, that feature proposes it.

[Zaba505]

Revision 2: the engagement process is out of scope

This revision applies the answer to open question 2, the last one left. Each section below replaces the section of the same name, as amended by revision 1, or says which part of it changes. Everything else is unchanged and still applies.

The charter has no open questions left. So the two standalone stories in Reset strategy, and then the reset itself, can be written.

Decisions

#	Question	Decision
2	Are the operator's workflows with capability owners out of scope?	Yes.

Where today's open issues go

Only one row changes. Every other row stands.

Proposal	Takes
out of scope	#750, #771, #778, #780 and #781

Out of scope

Only the item on the engagement process changes:

• The engagement process between the operator and capability owners. That covers:

  • the thread and typed issue for each event;
  • forced updates and contract-change rollouts;
  • eviction and the 30-day retention countdown that follows it;
  • the rules for approving a migration;
  • how an onboarding closes.

  story(adr): engagement channel / tracker — self-hosted-application-platform #750, story(adr): post-eviction read-only enforcement — self-hosted-application-platform #771, story(adr): engagement-thread issue type catalog & schema — self-hosted-application-platform #778, story(adr): contract-change rollout dual-form & atomicity mechanism — self-hosted-application-platform #780 and story(adr): retention clock & pause-resume mechanism — self-hosted-application-platform #781 would have designed it. What the platform itself must do stays in its proposals: backup, restore and export still owns exporting a tenant's data and deleting a departed tenant's data. If personal media storage needs any of the workflow, that feature proposes it.

Open questions

None. Revisions 1 and 2 answer all five.

[Zaba505]

Revision 3: wave 0 is done, and wave 1 starts

Wave 0 is done. The two standalone stories and the reset have landed on main:

Story	Landed in
#971, the backlog loop's setup	#978
#972, the required Build check	#981
#973, main licensed and holding no platform code	#982
#974, #975 and #976, the capability pipeline's skills deleted	#983, #984 and #985
#977, the docs skeleton, the new README and CLAUDE.md, and the old issues closed	#986

After #986 merged, every open issue except #116 was closed as not planned, with a comment saying where its topic went. Milestones 00 to 08 are closed, and the Area field is gone from the infra project.

So wave 1 starts, with its five proposals:

• Proposal: the rebuild entry point
• Proposal: definitions, values and secrets
• Proposal: drills
• Proposal: infrastructure modules
• Proposal: platform topology

This revision also corrects wave 1's dependencies, which the post left incomplete, and says which proposal owns a module's tests. Each section below replaces the section of the same name, as amended by revisions 1 and 2, or says which part of it changes. Everything else is unchanged and still applies.

Dependencies between the proposals

Only the wave-1 rows and the first point change. Every other row, and both points at the end of the section, stand.

Proposal	Wave	Depends on
the rebuild entry point	1	the charter
definitions, values and secrets	1	the rebuild entry point, infrastructure modules and platform topology
drills	1	the rebuild entry point, infrastructure modules and platform topology
infrastructure modules	1	the charter
platform topology	1	the charter

• From wave 2 on, no proposal depends on another in its own wave, so each wave's proposals are discussed in parallel. In wave 1, definitions and drills build on the other three while they're still being decided:

  • definitions' phase 0 bootstraps the state backend with the tool that infrastructure modules picks, in the public cloud that platform topology names;
  • drills' scratch targets copy the environments that platform topology names, and drills run the module tests that infrastructure modules defines.

  If topology's environments or the modules' tool change, definitions and drills change with them.

The proposals and their order

Only wave 1's entries for drills and infrastructure modules change:

• Proposal: drills. How a phase proves itself without touching the live platform: scratch cloud targets, virtual hosts on the home-lab LAN, where the module tests that infrastructure modules defines fit in, and what runs in CI or only on a workstation.
• Proposal: infrastructure modules. The IaC tool, and a module's shape, naming, provider pinning, versioning and tests, including how a test runs without real credentials.

The post gave module tests to both. Infrastructure modules owns them, because the engineering rules already have it choose the tool and the linter. Drills decides what runs after them.