cgalo5758
19ca28745f
The org-type default change and each organization's enactment lived in the HTTP handlers. They are now entitlements.ChangeOrgTypeDefault and entitlements.EnactDefault, which the reorder handler also calls for each organization. ChangeOrgTypeDefault runs the same steps in the same order: it saves the default (autocommit, outside any lock beyond the row update), composes the actor with the reason "org-type default change (<type>)", lists the type's organizations, and enacts each one. EnactDefault is the old enactOrgDisposition: it finds the default pool, opens BeginMaterializing, locks the pool, reads and classifies its positions, and then initiates the default, counts the pool, or applies the disposition (grandfather through ConferGrantTx per incumbent, migrate through core.end_conferral, ReapplyDefaultsIfVacant and the materialization), each organization in its own transaction and a failure leaving the others alone. The statements, the locks, the rendezvous kind and the legacy grant's description and transition reason are unchanged. Failures come back as EnactFailure values naming the step (eight new steps, from saving the default to the grandfather conferral's outcome); internal/entitlements now imports internal/organization, which imports no console package. CommitOrgTypeDefaultChange keeps the reads, the reserved-type check, the form parse, the candidate's resolution and the gate. renderDefaultChangeFailure gives the two sentences for a failed save and a failed listing, enactFailureReason gives each organization's reason with the driver's text unchanged, orgTypeChangeResult converts the counts for the summary, and logEnactFailures writes the line each failing step wrote before: a warning for a missing pool, errors for the initiation, the grandfather and the migrate's end and restore. The reorder handler passes the new rank 0 as the candidate and logs each type's failures after that type's organizations, as the lines came before. No answer of the default change moves after a rollback: each organization's transaction ended inside the enactment before the card rendered, and still does. Docs: docs/database-locks.md renames enactOrgDisposition to EnactDefault in the pool-row line and the reorder entry, names the default change by entitlements.ChangeOrgTypeDefault and EnactDefault, and gains a correction that rides along: the migrate branch's list now includes ReapplyDefaultsIfVacant, which the migration runs before it materializes. The two model docs point at internal/entitlements/default_change.go, and the call-sites list in the package comment of internal/entitlements now names that file for the default change and the reorder's enactment, in place of the handler. The gocognit exception for enactOrgDisposition (pinned at 38) is deleted from .golangci.yml, with the step heading that only it carried. Measured: CommitOrgTypeDefaultChange 18 at the parent and 16 at this commit; enactOutgoingDefault, the largest new helper, 9; enactDefault 5, grandfatherIncumbents 5, initiateDefault 4, ChangeOrgTypeDefault 3, EnactDefault 1. No output changes. Names and results of ./internal/server, ./internal/entitlements and ./internal/testkit/... are equal at the parent and at this commit after a database reset on each side: 1779 results on each side, 1778 passing and the one existing skip. No test, golden or testdata file is edited and no test ran with -update, so every golden is byte-equal, the two pool-queue tests among them. The seeded operator walkthroughs, which drive the default change through TestOrgTypesWalkthrough, give equal names and results on both sides, and the screens of operator-plan-ladders, plan-ladder-detail (and its open and invalid states) and org-types, desktop and mobile, are byte-identical at the parent and at this commit except the masked operator-integration-stripe shots. Three stored texts leave the handler file: ": grandfathered as legacy", "Grandfathered on org-type default change: " and "org-type default change (%s)" are each found in internal/entitlements; every other literal of the plan-ladders and org-types handler files is still found in a non-test file of internal/server. 21 breaks (38 records), each caught by the old code and by the new code where its text exists on both sides: a grandfathered and an initiated pool are counted, the legacy grant's description and transition reason, a failed restoration's reason, a failed organization turns the toast into an error, an organization with no default pool fails and is logged as a warning, the grandfather conferral must supersede, a failed begin fails the organization, a failed initiation's reason and its log line with the pool, a failed save's sentence, a failed listing after the save, the reason names the type, the new default is saved, a migration to None materializes the pool, each organization's enactment waits on its pool, an organization in contention says a change is in progress, organizations are enacted against the new rank 0, and grandfather reissues the incumbents. None was dropped. Not probed: faults inside each organization's transaction (the position read, the endings, the materialization and the commit; no querier makes them fail), so their reasons and log lines are read but not seen; the undecided refusal, which needs an outgoing-default position that appears between the gate and the enactment; the enactment order among organizations with the same name; and the browser end-to-end plan-management tests, which were not run here.
title, audience, summary
| title | audience | summary | |||
|---|---|---|---|---|---|
| Documentation index |
|
Index of member-console documentation, grouped by audience, plus the front-matter convention every doc follows. |
Documentation
Every document in this directory carries YAML front matter declaring its audience, so readers can find what's for them and contributors know who they're writing for.
Front-matter convention
Start each doc with a front-matter block:
---
title: "Human-readable title"
audience: [admin, developer] # one or more of: developer, admin, user (primary first)
summary: "One sentence describing what the doc covers."
---
The three audiences:
- developer — contributing to or understanding the codebase: architecture, design decisions, dev setup, testing, UX research and conventions, the provider-extension contract.
- admin — hosting and operating an instance: installing, configuring an identity provider, building the image, generating secrets, running the service.
- user — the general public or a member using a running service. (None yet — the tag is reserved for member-facing docs.)
List the primary audience first; a doc may name more than one.
For administrators — hosting & operating
- Production Deployment — the sequenced path from a fresh host to a running instance; start here.
- Environment Reference — every configuration key with its default and
MC_*override. - Settings and Configuration — why software uses two words for what a program is told, and how this console applies the rule.
- Hosting member-console — build the image and generate secrets.
- Deployment Architecture — how the console fits alongside a public site and an identity provider.
- Identity Provider Setup — configure an OIDC IdP for login.
- Temporal Authorization Setup — emit the
permissionsclaim Temporal's JWT authorizer expects. - Plan Management — operator guide to plan ladders and grants.
- Stripe Integration — flags, secrets, webhooks, and purchasability.
For developers — contributing & internals
- Database Management — goose migrations and sqlc.
- Database Locks — every advisory and serializing row lock, how each key is built, and the order each path takes them in.
- Design System — UI conventions.
- Domain Model Cards — the model catalog: one card per domain model with invariants, dimensions, and traps.
- FedWiki Integration — provisioning via the FarmManager API.
- Go Conventions — which returned errors may go unchecked, and why.
- HTMX Setup — HTMX under a strict CSP.
- Identifiers — IDs, names, and keys: which entities carry a key, its grammar and scope, and how seeds and lookups use it.
- Operator Information Architecture — the operator panel's IA contract.
- Operator UX Conventions — form and action conventions.
- First-Contact UX Walk Process — the repeatable method for walking the console as a stranger.
- First-Contact UX Rubric — the instrument that method scores with: the A–G question bank, the walker protocol, and the screen coverage checklist.
- Agent Runner — how an agent from another model family reviews or ideates on the code inside a disposable copy: what contains it, how a task is shaped, and what a finding must carry before it counts.
- Operator UI Accessibility Baseline — what operator-UI changes are diffed against.
- Building an Integration — adding a new integration.
- Testing — the test taxonomy and how to run each kind, plus the gates:
make lint(page-anatomy rules and the Go static checks) andmake screens(contact sheets at two widths).
For users
No member-facing documentation yet.
Where things are not
Research, drafts, audits, walkthrough evidence, and other records of how a
decision was reached are not documentation; they stay in a local notebook
that git ignores, so a clone never carries them. When a decision lands,
whatever a reader still needs is written into this directory, which holds
the result without the history. The rule for every kind of file is in
status/MAINTAINING.md.