prj-forgejo-org-refactor/taxonomy/README.md

Stewardship proposal — 2026-09-28

This is a review draft, not a transfer authorization. The matrix contains all 141 anonymously visible server repositories plus 12 additional paths observed in local remotes. It is not a complete private-server census.

• assignments.csv: sortable review table.
• assignments.json: stable IDs where available, purpose, source evidence, target proposal, visibility and unresolved access decisions.

Assignment rule

Choose the group accountable for maintaining the repository's own capability: who accepts changes, maintains its contracts and responds when it fails. A consumer, hosting platform, legal owner, State Hub domain, programming language, repository prefix or lifecycle stage alone does not establish stewardship.

Candidate org	Responsibility	Proposed repos
railiance	Infrastructure, delivery, platform operations and managed workload packaging	32
netkingdom	Security, identity, authority, policy and security evidence	20
helixforge	Software factory, development tooling, capability/knowledge/interface frameworks	60
binky	Company-specific coordination and finance integration	3
coulomb	Explicit Coulomb product/engagement and estate/personal continuity	5
whynot (new candidate)	Prototype exploration, market signals and its design system	2
Unresolved	Insufficient evidence to choose a steward	31

The 122 assignments are recommendations derived from current descriptions and scope documents, not evidence that their proposed maintainers have accepted responsibility. JSON open_items flags cross-cutting cases requiring particular attention. Every row still needs named maintainers and access reconciliation. The 12 non-publicly-listed paths have no verified numeric forge ID or visibility; State Hub UUIDs are included where known, but do not substitute for forge IDs.

Examples that preserve the independent dimensions:

• canned-prompts → helixforge; rapp-canned-prompts → railiance. The latter's SCOPE explicitly owns packaging/operations rather than the product.
• user-engine → netkingdom; rapp-user-engine → railiance. Their code and operational contracts have distinct responsibilities.
• qonto-assistant → binky; rapp-qonto → railiance. The financial policy and runtime binding remain separate.
• coulomb-social stays coulomb despite consuming all three platform stacks.
• rapp-secrets-engine provisionally remains with netkingdom: it is a CLI declaration, so the rapp- prefix alone does not establish Railiance ownership.

Experimental and standalone products

Recommend no lifecycle-only experimental org. Experiments live with their steward and carry maturity/visibility metadata. A real shared incubator could justify an org only after naming its accountable steward, access model and exit policy. No such organization is established by this preparation.

Do not force standalone products into helixforge because they use its tooling, or into binky because of legal ownership. These review groups remain unassigned:

Review group	Repositories	Decision needed
Document/evidence products	binect-chrome, binect-js, citation-engine, citation-evidence, citation-work, direkt-vermittlung-de, evidence-anchor, evidence-binder, evidence-source, vergabe-teilnahme	Product steward; keep each product/component family coherent where responsibility is shared
Shared data/communication facilities	artifact-store, doc-store-pg, email-connect, plenty-gobble	Reusable framework steward versus infrastructure-service steward
Commercial and company tooling	adaptive-pricing, fin-hub, human-resources, target-revenue	Generic product responsibility versus Binky-specific operational ownership
Cross-estate canon/governance	commerce-canon, info-tech-canon, interface-canon, prj-canon-federation, guide-board	Cross-estate continuity versus HelixForge/NetKingdom responsibility
Research, prototypes and independent products	clay-borg, freedom-intelligence, ground-game, inter-hub-haskell, polycode-sim, python-snake, soul-frame, timeline-svg	Accountable research/product steward; the prototype stage alone does not identify the steward

Their current paths stay unchanged pending a decision; that is not permanent approval to retain them in coulomb. Do not infer public/private treatment from whether a project is experimental. Binky's evolving company branding also needs review before making its proposed org name durable.

Permissions and visibility proposal

1. Preserve current visibility, direct collaborators, protected-branch behavior, deploy keys, machine access and necessary package access during each transfer. Current public visibility is observed, not a recommendation to publicize anything currently private.
2. Propose separate named org administrators and repository maintainer teams. Maintainer membership grants write only for accepted repositories; ordinary org membership must not silently grant fleet-wide write.
3. Model cross-org CI, GitOps and registry readers explicitly. Owning a repository does not imply ownership of its package namespace or a credential grant.
4. Populate actual people/service identities, existing grants, proposed team membership and before/after effective access from an authorized forge export. The anonymous API cannot supply this; no grants are invented in the matrix.
5. Accept G2 only after every row has an agreed target and accountable steward, resolved access/visibility review, and verified immutable server identity.

Durable home

Propose the-custodian as the permanent convention owner because this rule spans all stewardship groups. railiance-master keeps authority over family schemas and can link to the convention. This is an owner-acceptance proposal, not a cross-repo edit or a new assignment of authority.

The convention should include a new-repo checklist: accountable steward, org, visibility, team grants, package publication owner and cross-org consumers.

Deeper evidence review

Four formerly unresolved rows now have concrete proposals: disaster-control → coulomb (explicit Coulomb continuity intent); ops-hub → helixforge (framework extension handoff HF-WP-0001, 48d91935-197e-4ad4-be07-7bbcd535847c); whynot-control and whynot-design → proposed whynot (their existing intents explicitly name that organization). Source paths, hashes and revisions are in each matrix row. These are recommendations, not newly accepted ownership or grants.

The proposed whynot addition is subject to the requested naming preference. No organization has been created. It does not make all experiments whynot-owned. Vergabe Teilnahme remains unresolved: its selection as a HelixForge factory customer (HFACT-WP-0001, ed4fe524-036f-5221-8deb-00e24e944de1) establishes delivery integration, not necessarily product stewardship. Likewise a shared canon's semantic authority does not establish its organization or maintainer team.

No verified named-maintainer/Forgejo-team roster was found in the inspected purpose records. Role placeholders therefore remain proposals; no human or service identity is assigned by inference from repository names or task owners.