tegwick
3bd576990b
Assistant: codex Assistant-Model: gpt-6-astra Assistant-Session: 01a0e782-9f45-7382-afff-77ad665b88ec
115 lines
7.2 KiB
Markdown
115 lines
7.2 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 | 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.
|