chore: bootstrap eqrm/ct-structure — adopt the real Equippers scaffold

[2000game]

Create eqrm/ct-structure — the private repo holding Equippers' actual desired-state config + state files, per the two-repo layout decided in #1 (tool ≠ infra, mirroring Terraform). Until this exists, ct-cli manages nothing real. Part of the Phase 6 epic.

Depends on (as of 2026-07-09): portable configs (#20) and Phase 5 are merged; still blocking are environments (#22), the grant scope-dimension bug (#49), and first-page-only pagination (#50). Adoption of ~48 resources has already begun; #52's blueprint rewrite (item E) lands here.

Scope

• Create the private repo: npm install dependency on ct-cli (or the released binary once feat: automated releases — install ct from the GitHub Releases page #9 lands), config/ TS entrypoint, ct-state.*.json, README with the operating model.
• Selective adoption of the real prod scaffold per the scoping principle (rights-bearing structure only, no operational teams): campuses; the shared group types / age groups / target groups / statuses actually used structurally; the per-campus lead/area groups + hierarchy; permission grants on the structural roles; existing auto-groups that belong to the scaffold.
• Express the per-campus part as a blueprint function (exercises feat: Phase 5 — Blueprints (parametrized campus blueprint, auto-groups) #7's deliverable on real data); leave adopted one-offs as plain declarations.
• Decide + implement the managed-marker open decision from epic: Campus Management tool — ChurchTools structure-as-code CLI #1 (config-only vs a visible CT marker like a name prefix/tag) — document the choice either way.
• .gitignore/secret hygiene: tokens never in the repo; state files (which contain no secrets, only ids + snapshots) committed.

Acceptance criteria

• ct plan --env prod in ct-structure is a clean no-op after adoption (proves the config faithfully describes reality).
• ct plan --env dev shows the create-set for a fresh instance (or dev is populated and also no-op — decide the dev baseline).
• A new campus instantiated from the blueprint produces a correct, ordered plan.
• README documents: how to propose a change (PR), how state is handled, what is deliberately unmanaged.

[2000game]

Status (autonomous wave, 2026-07-09): repo-side bootstrap is merged — eqrm/ct-structure#1: package.json (ct-cli git dep, now buildable on install via ct-cli PR #64), ct.envs.json (dev/prod, prod protected), ct-state.prod.json (+empty dev baseline), blueprint config (5 campuses, 0 numeric ids; fixed a real would-drift-forever bug: vestigial shortName → shorty), managed-marker decision (config-only, documented), operating-model README, .gitattributes state collapse, and scripts/verify-config-vs-state.ts — the offline equivalence gate currently passes (5/5 EQUIVALENT vs prod state).

Remaining (needs credentials — checklist also in eqrm/ct-structure#1):

1. ct plan --env prod → expect clean no-op for the 5 campuses.
2. Bulk-adopt the real scaffold (~40+ resources: shared group types/statuses, per-campus lead/area groups + hierarchy, structural grants, auto-groups) with the new ct adopt group --type/--children-of --with-dynamic --env prod (feat(adopt): bulk/filtered adoption + auto-capture dynamic rulesets + warn on unknown declaration fields #51) — snippets paste verbatim (feat(dx): human-authorable configs — idiomatic adopt output, dynamic sugar, located errors, machine-only state, blueprints by default #52) — then re-run verify + plan to no-op.
3. ct plan --env dev → create-set; rehearse an apply on dev.
   Then this closes.

[2000game]

Update: correction to the earlier comment — the ~48-resource adoption DID exist, as unpushed commits on the local checkout. eqrm/ct-structure PR #3 (merged) reconciles those actual commits with the environments/blueprint/GitOps layout: ct-state.prod.json now carries all 48 resources (byte-identical to the locally-verified state), the config is a blueprint rewrite proven equivalent offline 48/48, rulesets byte-identical, docs preserved, user's local main reconciles with a plain git pull. Remaining for close is now ONLY the live proof: ct plan --env prod no-op (the state was verified no-op at adoption time, so drift since then is the only risk), ct plan --env dev create-set, dev apply rehearsal, and the structural-grants adoption that #49's fix unblocked.

[2000game]

Live phase update (2026-07-10, user-granted access):

• ✅ ct plan --env prod = clean no-op on the 48-resource blueprint config (CT 3.134.1) — the core acceptance, live.
• ✅ Structural grants adopted + declared (ct-structure PR feat: Phase 3 — Declarative engine (config format, diff/plan, dependency graph) #5, logical groupType: domains): plan is a full no-op incl. permissions. En route this surfaced and fixed ct-cli bug(permissions): plan demands revokes for inherited rights (authId ≥ 10000) that cannot be declared — no-op impossible on role domains with inheritance #65 (inherited authIds ≥ 10000 wrongly demanded as revokes).
• ✅ New-campus-from-blueprint acceptance: scratch campus + 2 dependent groups → correct ordered plan (+ campus first, groups carrying <campus:… (created this apply)> pending refs). Read-only, reverted.
• ✅ Bonus finding: group statuses have NO REST catalog at all (memberstatus = member statuses) → ct-cli bug(refs): group-status sugar resolves against /group/memberstatus — the wrong dimension (member statuses, string ids); no REST group-status catalog exists #67 fixed (sugar removed), config comment updated (ct-structure PR feat: Phase 4 — Apply (idempotent CRUD in dependency order) + guardrails #6).

Remaining (needs eqrm-dev credentials — ct auth login --host https://eqrm-dev.church.tools --token <token>): ct plan --env dev create-set check + dev apply rehearsal. Then this closes.

[2000game]

Handoff state (2026-07-10): the bootstrap is functionally COMPLETE — both instances live at full no-op.

• ✅ ct plan --env prod = no-op (48 resources + permissions).
• ✅ Dev rehearsal executed end-to-end: eqrm-dev turned out to be a POPULATED prod-copy (549 groups), so the baseline decision was reversed to adopt-then-reconcile — 30 pre-existing resources adopted by config key, then 18 creates + 12 updates + 9 grants applied; ct plan --env dev = full no-op. The rehearsal found and fixed 5 tool bugs en route (bug(permissions): domain-by-reference to a not-yet-created group type aborts the entire plan — fresh-instance rehearsal impossible #69, bug(apply): per-item failure message drops HTTP status/body — mid-apply errors are undiagnosable #71, bug(engine): group-type CREATE omits required fields (namePlural, shorty, color, permissionDepth, isLeaderNecessary, availableForNewPerson) — fresh-instance creation impossible #73, feat(groups): same-name group creation needs CT's force flag — declarative opt-in (allowDuplicateName) #75, bug(dynamic): ruleset PUT sends bare object — CT expects the [RuleSet] array envelope (server 500/TypeException) #77 — all merged).
• ✅ Blueprint acceptance: scratch new-campus plan showed correct ordered creates with pending refs (reverted).
• To close: merge eqrm/ct-structure#7 (open, handoff) — it carries ct-state.dev.json (the dev id mapping; already live-verified) + the allowDuplicateName config touch + the dep pin. Pure bookkeeping of what's already applied.
• Small residuals noted: dev's dynamic rulesets currently carry prod-numeric query ids (tracked as feat(dynamic): rulesets embed instance-specific numeric ids — not portable across environments #76); catalog staleness warning clears via npm run regenerate:permission-catalog with a token.

[2000game]

Bootstrap complete — closed by merging eqrm/ct-structure#7 (dev rehearsal state) plus the GitOps go-live (#8, #4).

Live state now:

• ct plan --env prod = clean no-op (48 resources + permissions).
• ct plan --env dev reconciled: eqrm/ct-structure#8 made the loop live; the first apply-dev healed one drifted ruleset (a leftover ct-cli bug: dynamic ruleset round-trip assumption unverified — CT-recomputed fields would cause perpetual diffs #36 test probe on group #1698 → the config's real ruleset) and dev is consistent again.
• New-campus-from-blueprint acceptance proven at rehearsal (ordered create plan, reverted).
• README documents the operating model, state handling, and what's deliberately unmanaged.

Residual (tracked separately): dev's dynamic rulesets carry prod-numeric query ids — #76 (Stages 1–3 now landed via #86; Stage 4 live-dev verification remains).