55 lines
3.3 KiB
Markdown
55 lines
3.3 KiB
Markdown
# Scope
|
|
|
|
## Project authority
|
|
|
|
This proposed project owns factory success gates, sequencing, integration
|
|
acceptance, the dependency map and consolidated evidence. The Custodian
|
|
coordinates; `helix-forge` owns the durable product and capability acceptance.
|
|
Accountable people/agents and allocated capacity are confirmed in T01, not
|
|
assigned to other repositories by writing this proposal.
|
|
|
|
## Participating repositories
|
|
|
|
| Owner | Responsibility retained |
|
|
| --- | --- |
|
|
| helix-forge | Human intent, reusable capability contract, architecture fit and value acceptance |
|
|
| the-custodian | Governance, source-record conventions, portfolio assessment and project oversight |
|
|
| repo-manager / current State Hub projection | Canonical repository/work identity, files, registration and derived coordination views |
|
|
| activity-core | Admitted definitions, ops_run queue, worker identity and leases |
|
|
| rein-aharness | Claim worker, repository transaction/acceptance, terminal-close delivery |
|
|
| glas-harness | Versioned profile selection and real-profile acceptance; existing owner coordination GLAS-WP-0015 |
|
|
| sand-boxer | Runtime provisioning, isolated execution, constrained egress, private state and teardown |
|
|
| key-cape, flex-auth (access-engine), approval-engine, secrets-engine, audit-core | Identity, decision, approval, native credential delivery and evidence contracts respectively |
|
|
| railiance-platform | Admitted credential custody and shared-service dependencies |
|
|
| railiance-master and concrete rail/rapp/reef owners | Execution/workload admission, placement, package deployment and recoverability |
|
|
| railiance-forge / railiance-enablement | Runner/artifact operations and existing reusable CI/release paths |
|
|
| Chosen source and workload repositories | Pilot code, meaningful tests, release, consumer integration and operating evidence |
|
|
| kaizen-agentic / coulomb-loop | Existing improvement definitions and demand/feedback context where appropriate |
|
|
| prj-unattended-progress-company | Receives relevant factory-load evidence; retains independent company/revenue gates |
|
|
|
|
Names above are current checkout identities. This project does not rename
|
|
`flex-auth`, replace `coordination-engine`, or create a parallel ownership model.
|
|
|
|
## In scope
|
|
|
|
- One internal factory lane and its exact prerequisite closures.
|
|
- Two-repository capability delivery and reuse, including a Railiance service release.
|
|
- Minimal work-record hygiene needed for dispatch and accountability.
|
|
- Fresh operating evidence, recovery, cost and founder-load measurement.
|
|
|
|
## Out of scope
|
|
|
|
- Production code or credential material in this repository.
|
|
- Clearing the entire estate backlog as an entry gate.
|
|
- Full HA, wholesale hub retirement, broad renaming or global schema redesign.
|
|
- External tenant onboarding, community campaign expansion or revenue operations.
|
|
- Any implicit authorization from a proposed workplan or from another owner's
|
|
historic session authorization.
|
|
|
|
## Work-record rule
|
|
|
|
The project workplan contains acceptance/handoff tasks and references existing
|
|
owner work. It does not duplicate child implementation task lists. A newly
|
|
discovered implementation gap receives an owning source-backed task or intake
|
|
before it is counted as assigned. Dependencies are current records, not just
|
|
messages; an acknowledgement is not a completion receipt.
|