prj-forgejo-org-refactor/SCOPE.md
tegwick 4a690f9e27 Finish local collector preparation and block remaining coordination work
Assistant: codex
Assistant-Model: gpt-6.1-sol
Assistant-Session: 01a11beb-4eef-7fc1-94a7-597130a01ae9
2026-10-09 00:38:03 +02:00

4.5 KiB
Raw Blame History

SCOPE

Lightweight orientation: what this project repo is for, and when it is not the right place to work.


One-liner

Temporary coordination repo for splitting the single coulomb/ Forgejo organization into stewardship organizations without breaking GitOps, image pulls, or clones, and coordinating private forge access under ORGREF-WP-0002.


Project authority

This repo coordinates. It owns the inventory, the org taxonomy, the sequencing, the rollback plan, and the evidence. It does not own the repos being moved, and it hosts no production implementation.

Changes land in the repos that own them. This project links their work records by ID; it does not duplicate their tasks.


In Scope

  • Inventory of every coulomb/ reference across the fleet
  • Target org taxonomy and the assignment criteria behind it
  • Verification of Forgejo rename / transfer / redirect behavior, including the package registry
  • Migration sequencing, rollback plan, and cutover evidence
  • Promotion of the durable org-assignment convention to a permanent home
  • Forge access-consumer inventory, identity-owner coordination and visibility sequencing under the accepted ORGREF-WP-0002 policy

Out of Scope

  • Rapp context grouping — a separate dimension by ratified decision (d07ee5f9); see railiance-platform/docs/rapp-platform-service-pattern.md
  • State Hub domain taxonomy — a separate dimension, owned by the-custodian
  • Legal-entity structure and IP attribution — handled by LICENSE, copyright headers, and contribution-convention_v0.1
  • Renaming the forgejo.coulomb.social host (open question, may become scope only if the org split forces it)
  • Forge product migration (Gitea/Forgejo)
  • Any repo's internal structure or content beyond coordinated migration references

Participating repos

Repo Role
railiance-forge Historical forge-owner records; re-confirm ownership before org/transfer operations
key-cape / net-kingdom OIDC contract and KnownSecurityCase client registration
railiance-platform ArgoCD Application sources, OpenBao lanes referencing repo URLs
railiance-apps Current Forgejo Helm/runtime and runner owner; chart image paths and metadata
railiance-master Durable home candidate for the org-assignment convention
the-custodian Canon home candidate; repo-classification alignment
Current server-backed coulomb/ repo inventory Subjects of the migration; 112 was the seed count
railiance-enablement Reusable CI/CD references and developer checkout paths
Source/rapp owners Release manifests, package consumers, workload declarations

Relevant When

  • Planning or executing the Forgejo org split
  • Deciding which org a new repo should be created in (until G7 promotes that convention to a permanent home)

Not Relevant When

  • Deciding which rapp a workload belongs to (different dimension)
  • Deciding which State Hub domain work belongs to (different dimension)
  • Executing T03 onward before all four entry conditions in ORGREF-WP-0001 hold; read-only T01/T02 preparation remains relevant and permitted

Work-record rule

Workplan files live in workplans/ with prefix ORGREF-WP-NNNN. Child work in participating repos keeps its own prefix and is linked by stable ID from this project's workplans, never copied.


Current State

  • Status: preparation drafted; production execution deliberately deferred

  • Seeded 2026-08-11 with the finding, blast radius, and entry gate

  • Reviewed 2026-09-28: local family validator green; fresh deployable coverage, stable full reference inventory and transfer rollback evidence still needed

  • T01/T02 preparation produced inventory/code and a 153-row taxonomy draft; both tasks wait on explicit evidence and acceptance gaps. Execution requires the unchanged ORGREF-WP-0001 entry gate and resolution of its circular rollback dependency

  • Evidence and next sequence: readiness review

  • October 8–9: WP-0002 policy and inventories accepted; identity integration waits on KEY-WP-0038 / NK-WP-0048 and RAPPS-WP-0016. Private forge access is independent of the unchanged WP-0001 org-transfer gate.

  • Loose-end closure October 9: both workplans are blocked. The collector's authenticated read option is implemented and Telegram image upload delivery is linked as owner-complete. Eleven remaining tasks retain their existing evidence, owner and human gates; three WP-0002 tasks remain done. No new tasks or workplans were opened.