cgalo5758
1f0c697387
internal/testkit/htmltest parses rendered HTML and selects from it with CSS selectors (Parse and ParseIn, One, All, Count, None, Text, Texts, Attr, HasClass, HTML, Before, InOrder), on golang.org/x/net/html and github.com/andybalholm/cascadia, which joins go.mod as a direct requirement (BSD-2-Clause, pure Go, depending only on x/net). A page, which opens with a doctype or an html element, parses as a whole document, so the attributes of its html and body elements are kept; any other body parses as a fragment, a table row under a tbody, an option under a select and anything else under a body. Both parse with scripting off, so what a noscript holds is elements that selectors reach, as a browser without JavaScript renders it. Its own tests: the fragment context for tr and option, the attributes of html and body, the content of noscript, One's failure message naming the selector, None, Text, selection by attribute and role, Before, and InOrder. The import guard gets a row for it, and scripts/deadcode-testonly.txt an entry. harness_test.go gains the shell assertions both surfaces share, exported for server_test: the top bar, the account menu, the Identity and Access handoff, the drawer and the rail's account block. member_nav_test.go and operator_sidebar_render_test.go select regions by landmark and ARIA (nav.navbar[aria-label=Account], aside#app-rail, the account group's aria-labelledby list) and controls by attribute ([data-form="shell.confirm"], the button posting to /logout) instead of regionBetween, topBarRegion, railRegion and sidebarRegion, read aria-current on each member rail entry and on both surface switches, check order through InOrder, and keep a class assertion only where the class is the fact. sidebarSections selects the entry list instead of slicing the rail string, and sidebarLinkActive reads the link node instead of matching a regular expression. The page subtests of TestShellAccountMenu and TestShellMemberRail call named functions (checkAccountMenuPage, checkMemberRail); every test and subtest name is unchanged. Each ban and each count keeps the region the old one covered, or a wider one; a check that an element is present looks where the element belongs, such as the trigger and the Get help order in the bar and the entries in the rail, which is narrower than the body the old strings searched and stricter. A bar, a rail or a page the old tests searched as a string is searched as markup (Node.HTML) where the old string covered the element's own tag, the html and body start tags, or an attribute: the rail's d-lg-none count, app-rail-signout, d-none d-lg-flex, the identity tooltip, the operator rail's nav-link count and its ps-4, group and /logout bans, text-danger, navbar-collapse, the handoff explanation, mt-2 pt-2 border-top, and the bar's bans over everything before the rail. Counts that were page-wide stay page-wide: the account menu (any tag), the Get help item, the Operator panel switch, the dismiss control, the hx-post="/logout" controls (counted as markup, so data-hx-post counts), the bans on href="/logout" (markup, so any attribute ending in href counts) and the account-console links; those inside the rail are counted over the whole rail before they are placed in the account group: the group's name and email spans, its list, the Identity and Access, Sign out and Get help entries. The Dashboard link count and the Operator link ban also run over the page's markup, the drawer's two lists are counted by class prefix as well, and nothing before the account group reads Sign out. Where the old tests pinned an element's class as an exact string, the new ones compare its class token set exactly (AssertClassSet), which ignores token order only; the checks that were prefixes or regular expressions stay HasClass or class selectors, and an active operator entry must still carry nav-link. aria-current appears on the active rail entry and nowhere else in the member rail, and on neither surface switch nor the account group's entries. Sign out, Get help and the account group's name and email stay plain text, the trigger's one child is its label span, the menu header's children are the line break and the email span, and the line break follows the name. The closing </main> check stays a text check, since a parser closes the element anyway. One weakening is general: a markup change that alters no asserted fact no longer fails, such as an attribute added to an element the old tests matched as a whole markup string (a data attribute on Sign out, say), a wrapper, or a decorative child the comments do not exclude. No specific fact is kept weaker. The four gocognit exclusions of TestShellAccountMenu, TestShellMemberRail, TestShellRailAccountBlock and TestOperatorShellTopBarAndDrawer are gone; the lint reports nothing in their place. 124 breaks: 118 failed the old and the new shell tests (the template and code changes that move, drop or mislabel each asserted element; an untitled Get help item in the bar, the drawer's header and the rail; a Log out title on the brand link; an extra class on Sign out, on the email span, on the switch's li and on the page title; a missing class on the rail or on an account entry's li; a button among the rail's entries; a surface label, a Get help link or a danger Dashboard link between the bar and the rail; a logout button in the drawer's header or a logout form among its entries; the tooltip on the li or on the account trigger; an Operator panel label for a member without the role; a noscript holding a second main, a Dashboard link or a Sign out link to /logout; a data-hx-post Sign out in the content or the menu, and a data-href to /logout; aria-current on a surface switch or on Identity and Access; an active Billing entry without nav-link; a second account-console link or Identity and Access item; an element inside Sign out, the trigger, the menu header or the group's name; a class on the rail's own tag, on the html or body tag, or a second element where the old string counted one: the account menu, Get help, the Operator panel switch, a plain Sign out, the group's name and email, its list; a Sign out button before the account group on either surface; a Dashboard or an Operator link with a decorative child in the content; a third nav list; a bar without its navbar class), and 6 on the helper's own tests have no old side. The names and results of internal/server equal the parent's; new tests: TestParseKeepsRowsAndOptionsThatABodyContextDrops, TestParseKeepsTheAttributesOfHtmlAndBody, TestParseSelectsInsideNoscript, TestOneFailureNamesTheSelector, TestNoneFailureNamesTheSelectorAndQuotesTheMatch, TestTextCollapsesWhitespaceAndSelectsInDocumentOrder, TestSelectionByAttributeAndRole, TestBeforeHoldsWhatPrecedesTheMatch and TestInOrder in htmltest, and the guard's htmltest subtest.
member-console
One system for memberships and the hosted services they pay for.
member-console is open-source software for offering hosted services on a paid membership. In one place it handles the pieces that otherwise get stitched together by hand — who each member is, what they're entitled to, what they pay — then turns that into the actual, metered services running on their behalf, kept in sync as members join, upgrade, and leave. New kinds of service attach through a shared contract instead of reshaping how membership or billing work, so the offering can grow on one foundation.
It has two sides: an operator panel where staff run the service, and a member panel where members sign in to manage their own plan and workspace.
Developed by the Wiki Cafe Multistakeholder Cooperative, and built for any organization to run.
The operator landing surface
Status: pre-production. The engine is feature-complete for its first service tiers, but this is not yet a hardened, turnkey deployment. Expect rough edges in first-run setup. docs/production-deployment.md sequences a real path to a running production instance, but it is a self-hoster's guide to follow and adapt, not a one-command install — the test stack remains the fastest way to see the console running. See
status/for the honest state of every milestone.
License: AGPL-3.0-only, with commercial licensing available — see LICENSE and COMMERCIAL.md.
What it does
- Governance spine — identity (via any OIDC provider) → organization → workspace, with auto-provisioning of a default workspace for new members.
- Entitlements — grants resolve to numeric limits (e.g. FedWiki site count and storage) materialized per resource pool; plan ladders model upgrade/downgrade paths with a generic transition primitive.
- Billing — Stripe is the billing execution engine. Products, prices, customers, subscriptions, and invoices are mirrored via a webhook pipeline; the console never holds card data.
- Integrations — an integration contract (manifest, namespaced resource keys, lifecycle verbs) lets a new hosted service conform without reshaping the operator panel or entitlement layer. FedWiki (wiki site provisioning) and Discourse (forum group membership) are the two conforming integrations today.
Architecture
- Go 1.23, server-rendered HTMX multi-page app — no SPA framework — under a
strict Content-Security-Policy (
script-src 'self',style-src 'self'; all JS and CSS is self-hosted, no inline<script>/style=). - PostgreSQL with a schema-ownership boundary between core and integrations:
the console's own data lives in a single
coreschema, and each integration owns its schema (fedwiki,discourse,stripe) and its own migration ledger — so adding one renumbers nothing (core-first is the only ordering rule). Queries are generated with sqlc; migrations run with goose. - Temporal for durable workflows (provisioning, integration sync, billing sweeps).
- OIDC for authentication — member-console is identity-provider-agnostic and works with any OIDC-compliant IDP (the test stack ships Keycloak).
Full documentation is indexed in docs/, grouped by audience
(developer / admin / user). Highlights:
deployment architecture,
hosting,
building an integration,
database management, and Stripe.
Running it
What you need:
- At least one conforming integration — FedWiki (wiki site provisioning) and Discourse (forum group membership) are the two available today (see "What it does" above); a deployment with neither has no product to actually deliver to a paying member. See fedwiki-setup.md and discourse-setup.md.
- An OIDC identity provider — any OIDC-compliant provider; the console authenticates members and operators against it and never stores passwords itself. See identity-provider-setup.md.
- PostgreSQL, Valkey, and Temporal — the console's own data store, session store, and durable-workflow engine (provisioning, integration sync, billing sweeps). See database-management.md and deployment-architecture.md.
- Stripe — optional, only needed to sell paid products; a deployment offering only free or unmetered products can skip it. See stripe.md.
First run, in order:
- Deploy the console and the dependencies above — see docs/production-deployment.md for the sequenced path from a built image to a running instance.
- Sign in as an operator (the account holding the
operator-memberrole configured on the identity provider). - Follow the in-app setup checklist at
/operator/setup, which walks through everything still needed to reach a deliverable product.
Quickstart (local development)
Prerequisites: Docker (with Compose), Go 1.23+, and make.
The test stack brings up Postgres, Valkey, Temporal, and Keycloak in
containers, then runs the console from source against them. All commands run
from the test/ directory:
cd test
./bootstrap-stack.sh # generate a per-worktree .env with collision-free ports
docker compose up -d # Postgres, Valkey, Temporal, Keycloak
set -a; . ./.env; set +a # load the generated host ports / secrets
go run .. start --config mc-config.yaml
Integrations are opt-in, not baked into the stack: a FedWiki farm or a live
Discourse forum is composed by adding its name to the COMPOSE_PROFILES knob
in the generated test/.env (and uncommenting that integration's MC_* block
in the same file). The console runs fine with neither.
bootstrap-stack.sh prints the URL table it allocated. With default ports the
console is at http://member-console.localhost:9481; sign in to the operator
panel as alice / password.
On a fresh stack the console rides out Temporal's cold-start with a bounded connect retry, so the first
startmay pause briefly before the server comes up — no re-run needed.
See test/AGENTS.md for the full stack contract (idempotency,
Stripe webhook constraints, teardown, running multiple worktrees concurrently).
Project status & roadmap
See status/ for the development roadmap, milestones, and notes.
Substantial changes are tracked as OpenSpec proposals
under openspec/.
Contributing
Contributions are welcome — see CONTRIBUTING.md for the development workflow, building and testing, and the project conventions.
Security
To report a vulnerability, see SECURITY.md. Please do not open a public issue for security reports.
License
member-console is free software, licensed under the GNU Affero General Public
License v3.0 (AGPL-3.0-only). See LICENSE for the full text.
AGPLv3 is and will remain the default license for this project. If you use, modify, or deploy member-console — including over a network — you must comply with the AGPLv3, which includes making the corresponding source available to users of the service.
If the AGPLv3 does not fit your needs — for example, you want to embed member-console in a proprietary product or run it as a hosted service without the AGPL's source-sharing obligations — a separate commercial license is available. See COMMERCIAL.md.
As the sole copyright holder, Christian Galo can offer member-console under both the AGPLv3 and separate commercial terms. Contributions are accepted under a Contributor License Agreement that preserves that ability (CLA.md; how to sign is in CONTRIBUTING.md), and commercial licenses fund continued development. Anything already published under the AGPLv3 stays under the AGPLv3; the public license is not withdrawn retroactively.
Third-party components redistributed in this repository keep their own licenses. See NOTICE.