tegwick
660c429838
Assistant: codex Assistant-Model: gpt-6-astra Assistant-Session: 01a0e782-9f45-7382-afff-77ad665b88ec
94 lines
6 KiB
Markdown
94 lines
6 KiB
Markdown
# 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](assignments.csv): sortable review table.
|
|
- [assignments.json](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 | 59 |
|
|
| binky | Company-specific coordination and finance integration | 3 |
|
|
| coulomb | Explicit Coulomb product/engagement and estate/personal continuity | 4 |
|
|
| Unresolved | Insufficient evidence to choose a steward | 35 |
|
|
|
|
The 118 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, disaster-control, guide-board, ops-hub | 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, whynot-control, whynot-design | Accountable research/product steward; `whynot` is an existing responsibility candidate outside the seed taxonomy |
|
|
|
|
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.
|