steid

docs: point at steid-control-plane, and name the constraint it imposes

The managed-hosting vision is deliberately kept out of this repo — the
tenancy decision (instance per tenant, recorded in that repo's 0001) means
Steid never learns it is managed. What belongs here is only the constraint
that decision imposes on this codebase: stay single-tenant, keep operator
actions headlessly drivable.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01JZwc7URWKVhkAuRTWiDmjA

JamesPatrickGill authored 20 hours agoparent607da17Browse files64831abc54ea8ac6a908fbb5945ae32dfa56c44f

1 file changed+5 −0

plans/ROADMAP.md+5 −0View file

		@@ -13,6 +13,11 @@ showcases, and anything else a dev or org wants to present lives here too.
13	13
14	14	Personal-first, but organizations can collaborate on it.
15	15
	16	+A managed offering — Steid instances hosted for companies and individuals — is
	17	+planned, but lives entirely in its own repo (`../steid-control-plane`, decision 0001
	18	+there). The constraint it places here: Steid stays single-tenant, never learns it is
	19	+managed, and everything an operator does must eventually be drivable headlessly.
	20	+
16	21	What makes it different from Gitea/Forgejo: those are GitHub clones scaled down.
17	22	Steid is portfolio-first — the profile page is the product, and repos are one kind of
18	23	thing that appears on it. That framing should win any tie-break.