Publish factory efficiency return and point to canonical project
This commit is contained in:
codex
parent
389f7e7f1d
commit
c1298bd476
8 changed files with 63 additions and 584 deletions
|
|
@ -23,20 +23,29 @@ utility; Railiance Fabric’s hosted authority still adds prerequisite work.
|
|||
flags still require source/residual disposition; none was cleared by counting
|
||||
it as completed. [Correction evidence](2026-09-08-helixforge-factory/human-flag-corrections.json).
|
||||
|
||||
The dedicated local project is
|
||||
[/home/worsch/prj-helixforge-factory](/home/worsch/prj-helixforge-factory/README.md).
|
||||
The dedicated private project is published at
|
||||
[prj-helixforge-factory](https://forgejo.coulomb.social/coulomb/prj-helixforge-factory),
|
||||
with [local source](/home/worsch/prj-helixforge-factory/README.md).
|
||||
It contains the accepted source-backed decision HFACT-DEC-2026-001, current
|
||||
workplan, ten exact owner-return records, delivery evidence and an empty
|
||||
measurement ledger. Hub decision receipt: `21159693-04b7-485e-bbab-1ed8f65aab43`.
|
||||
The original staged packet is frozen pending project publication.
|
||||
The original staged packet has been replaced with a pointer, preserving its Git
|
||||
history. State Hub registration returned repository UUID
|
||||
`99cc4689-9f73-42a2-9cca-d2e235393014` under the helix-forge topic.
|
||||
|
||||
## Remaining gates
|
||||
|
||||
Project creation needs the routed Forgejo admin API credential, which currently
|
||||
has no caller OpenBao login. Organization push-to-create is disabled. The same
|
||||
login can record both already-integrated PRs as manually merged; the PR metadata
|
||||
still says open, although the tested source is on main. There is no secret-value
|
||||
request or additional token provision in this handoff.
|
||||
The routed OpenBao login completed. Both already-integrated PRs now report
|
||||
closed/merged with the exact reviewed commit. Forgejo initially refused the
|
||||
disabled manual-merge style; it was enabled only for each metadata operation and
|
||||
restored to disabled. Current main ancestry was verified before the operations.
|
||||
Non-secret [publication receipts](https://forgejo.coulomb.social/coulomb/prj-helixforge-factory/src/branch/main/evidence/pr-merge-receipts.json)
|
||||
are retained in the project.
|
||||
|
||||
The credential proxy reported flex-auth unavailable and its configured
|
||||
unknown-zone fail-open behavior during this attended publication. HFACT-WP-0001-T03
|
||||
retains live policy availability and authorization-negative verification before
|
||||
governed execution acceptance. Login success is not that enforcement proof.
|
||||
|
||||
The workplan retains exact native credential/approval/audit receipts through
|
||||
GLAS-WP-0015, protected runtime placement, natural worker claim/heartbeat/close,
|
||||
|
|
@ -48,3 +57,43 @@ has no consistency failures; historical warnings remain. Reuse-surface has three
|
|||
archived null-ID failures (REUSE-WP-0017/0018/0019), separate from the successfully
|
||||
registered new plan. HFACT-WP-0001-T02 retains their disposition; CUST-IN-0017
|
||||
continues to own the pre-existing Custodian historical consistency issues.
|
||||
|
||||
## Efficiency gains already evidenced
|
||||
|
||||
| Change | Evidence and practical effect |
|
||||
| --- | --- |
|
||||
| Reuse before implementation | vergabe-teilnahme consumed the existing hosted registry with 65 capabilities and a dated, hashed snapshot. Source freshness and completeness checks prevent an unavailable registry from silently authorizing new work. No second registry was built. |
|
||||
| Repeatable release checks | 208 provider tests and 82 customer application tests passed; application tests and migration checks now run before customer image publication. Two actual release defects were found and fixed: missing source templates and missing runner BuildKit support. |
|
||||
| Less duplicate CI | Application checks run for PR updates and main, without an additional feature-branch push trigger duplicating the PR run. Main release validation remains explicit. |
|
||||
| Less review-queue noise | Four completed tasks with explicit published `needs_human: false` were corrected in the Hub. The flagged queue fell from 19 to 15 (21%); the two nonterminal flagged tasks were unchanged. A fresh query after login still returned 15: 12 done, 1 cancelled, 1 todo, 1 wait. The other 13 terminal flags need source/residual review. |
|
||||
| Clearer coordination | One published project owns factory integration; implementation stays in the two product repositories. Ten dependency-return records name the supplying task, source revision, next action and required evidence. Existing GLAS-WP-0015 coordination is reused. |
|
||||
| Fewer stale open records | REUSE-WP-0022 is finished, customer source/release tasks are done, and both PRs now show merged. Customer deployment remains an explicit waiting task instead of being mixed with completed source work. |
|
||||
|
||||
These are observed improvements in discovery, validation and coordination.
|
||||
Hours saved, monetary savings and autonomous throughput have not been measured.
|
||||
The original 94-plan/264-task portfolio baseline is dated; no later fleet-wide
|
||||
count is implied by these changes. The governed-attempt ledger remains empty and
|
||||
the fourteen-day acceptance window has not started.
|
||||
|
||||
## Next execution sequence
|
||||
|
||||
1. Prepare and accept the exact G0 tenant/actor/project/profile, repository
|
||||
grants, operating owners and enforceable time/spend contract. Project
|
||||
adoption and publication are complete; unattended operating admission is open.
|
||||
2. Close the existing GLAS-WP-0015 chain: KeyCape service-client custody and
|
||||
registration, audit sender admission, deployed approval claim/consume and
|
||||
native Secrets Engine delivery. Obtain current policy allow/deny evidence.
|
||||
Protected runtime installation can advance alongside that chain.
|
||||
3. Prove the current Railiance worker's natural claim, immediate heartbeat,
|
||||
execution and accepted terminal close, including lease-loss refusal and
|
||||
durable close replay. Retain one integrated delivery item plus two prerequisite
|
||||
closures as the project's WIP limit.
|
||||
4. Use that worker for a useful accepted change; admit and deploy the tested
|
||||
vergabe-teilnahme image through its exact tenant, database, storage, access
|
||||
and rollback contract (VERGABE-WP-0018-T03). Keep Railiance Fabric in its
|
||||
existing medium-term placement work until its additional utility is needed.
|
||||
5. Complete recovery/limit drills, then measure fourteen days: at least five
|
||||
useful accepted changes across two repositories, at least 80% without
|
||||
operator repair, median handling at most 30 minutes per accepted change and
|
||||
routine operation at most 30 minutes per day. Preserve every attempt,
|
||||
failure, retry, cost and operator intervention.
|
||||
|
|
|
|||
|
|
@ -1,38 +0,0 @@
|
|||
# Proposed project agent instructions
|
||||
|
||||
This packet is staged in the Custodian. Until project adoption, changes here
|
||||
prepare the proposal only; do not register it as an unrelated Custodian workplan
|
||||
or claim it is an active project.
|
||||
|
||||
After adoption, repo slug is `prj-helixforge-factory`; proposed workplan prefix
|
||||
`HFACT-WP-` must be checked with the authoritative registrar before first index.
|
||||
|
||||
Orient with `GOAL.md`, `SCOPE.md`, genesis, source workplans and `dependency-map.md`.
|
||||
Read the generated `.custodian-brief.md` when available. Use State Hub HTTP at
|
||||
`http://127.0.0.1:8000` locally, `http://10.43.68.154:8000` on railiance01;
|
||||
use an enabled edge relay only with its explicit configuration. Direct requests
|
||||
carry `X-StateHub-Component: prj-helixforge-factory` and canonical `/workplans/`
|
||||
and `/tasks/?workplan_id=...` routes.
|
||||
|
||||
Check this project's unread inbox and mark reviewed messages read. Do not send
|
||||
messages to other owners without user authorization. Refer to existing
|
||||
GLAS-WP-0015 threads and receipts to avoid repeated requests.
|
||||
|
||||
Implementation remains in participating repos under their instructions.
|
||||
Advance only within existing grants and session authorization. Do not infer
|
||||
permission for secrets, publication, deployment or paid execution from this
|
||||
proposed programme. Before any credential need, run `warden route find` and
|
||||
`warden route show`; ops-warden issues SSH certificates, while OpenBao/platform,
|
||||
KeyCape and the relevant policy/approval owners retain other responsibilities.
|
||||
Never place secret values in work records or logs.
|
||||
|
||||
Update source task statuses as work progresses. Record significant decisions
|
||||
as source-backed decision records and the supported Hub decision projection.
|
||||
At session close log a concise `POST /progress/` event and run
|
||||
`statehub fix-consistency` after workplan edits. If the CLI/API is unavailable,
|
||||
retain evidence of the failed sync and request operator recovery; do not claim
|
||||
queued or failed writes are central success.
|
||||
|
||||
Before finishing or archiving, create live owner records for actionable
|
||||
residuals, name their IDs in the completion record, and verify synchronization.
|
||||
No production implementation belongs in this coordination repository.
|
||||
|
|
@ -1,90 +0,0 @@
|
|||
---
|
||||
repo: prj-helixforge-factory
|
||||
repo_flavor: project
|
||||
project_status: draft
|
||||
started: "2026-09-08"
|
||||
reviewed: "2026-09-08"
|
||||
---
|
||||
|
||||
# Goal
|
||||
|
||||
## Outcome
|
||||
|
||||
Establish an internal HelixForge software factory that repeatedly turns bounded
|
||||
Coulomb demands into validated, reusable capabilities, with agent execution and
|
||||
at least one resulting software service running on Railiance. Humans retain
|
||||
capability acceptance and the release decisions required by existing policy.
|
||||
|
||||
The first factory serves one explicitly admitted internal tenant. A second
|
||||
repository demonstrates reuse; it does not introduce a second tenant. The
|
||||
existing Glas proof's `tenant:platform`, `actor: agt`, `project: glas-local-proof`
|
||||
remain scoped to that proof. The pilot gets its own reviewed binding where
|
||||
needed; no identity or authorization transfers merely by copying a profile.
|
||||
|
||||
## Invariants
|
||||
|
||||
1. Source files and their published revisions own work. Existing owners retain
|
||||
code, deployment and policy authority. The project links their records.
|
||||
2. An admitted task states capability intent, scope, tests, allowed repository
|
||||
effects, actor/tenant, runtime/profile pins, timeout, spend envelope and review
|
||||
disposition before execution. Repo instructions/prompts cannot expand grants.
|
||||
3. Repository-changing agents execute inside the demonstrated isolation and
|
||||
repository transaction boundary. The first pilot permits one active mutator.
|
||||
4. Source tests, deployed operation and accepted usefulness are separate claims.
|
||||
A local stub, startup probe or historical profile does not prove the current
|
||||
production route. The localhost proof is not Railiance admission.
|
||||
5. Credential custody, policy decisions, approval consumption, audit delivery
|
||||
and publication use existing admitted owner paths. No secret material goes
|
||||
into Git, messages or progress evidence.
|
||||
6. Build/test workers and release authority remain separated by their existing
|
||||
credential and trust boundaries. An accepted commit grants no implicit push,
|
||||
package publication or deployment authority.
|
||||
7. Preserve working coordination and recovery services during migrations.
|
||||
Source deletion, public exposure changes and broader tenant admission retain
|
||||
their existing independent gates.
|
||||
8. No new permanent service or generic framework is established in this project
|
||||
or in the retiring State Hub. Product implementations remain with owners.
|
||||
|
||||
## Success gates
|
||||
|
||||
Targets below are proposed for T01 acceptance; they are not measured baselines
|
||||
or spending approval. Any revision must be decided before its observation window.
|
||||
|
||||
| Gate | Required evidence |
|
||||
| --- | --- |
|
||||
| G0 — A bounded operating contract | Named capability acceptance owner, operational owner, internal tenant, pilot service, two participating repos, exact grants, budget, allowed release lane, test oracle and source-backed owner dependencies. All pilot dependencies have an owner, return evidence and next review/action. |
|
||||
| G1 — Real governed model execution | Current GLAS-WP-0012 candidate produces its real artifact with protected owner credentials, correct attribution, declared egress, denial and teardown proof. Only the demonstrated profile becomes ready. |
|
||||
| G2 — Railiance execution | Admitted installed runtime and worker on railiance01 execute through Activity Core with a current versioned profile and repository grant. Natural claim/heartbeat/close, accepted changed paths, clean source baseline, durable evidence/replay and controlled lease-loss refusal are demonstrated. |
|
||||
| G3 — Useful delivered capability | One bounded real service/library change has intent and contract, relevant OAS structural/semantic checks, independent tests, accepted review, immutable Forgejo artifact identity, authorized Railiance release, service smoke and rollback proof. A second repo consumes or reuses the capability. Documentation-only or smoke-only output is insufficient for this gate. |
|
||||
| G4 — Controlled operation | Budget/timeout and grant violations stop work; worker crash, Hub/queue outage, terminal-close replay and sandbox cleanup are exercised without duplicate accepted mutations. Backup and recovery evidence covers the actual worker state, source/artifact path and pilot workload. No stale evidence claim is presented as current. |
|
||||
| G5 — Repeatability and founder load | Over 14 consecutive calendar days, at least five useful accepted changes across two repos, at least one service release, ≥80% of admitted delivery attempts accepted without operator repair, median human handling ≤30 minutes per accepted change, routine operation ≤30 minutes/day. All attempts, retries, rejects, costs and interventions retained. Report setup and attended security/recovery time separately and in total founder load. |
|
||||
|
||||
Suggested initial hard limits for T01: one mutating run; 30 minutes wall clock
|
||||
per run; EUR 5 equivalent maximum model spend per run; EUR 25 equivalent per
|
||||
day and EUR 150 total pilot model spend. The admitted provider/runtime must be
|
||||
able to enforce the selected envelope; token counts alone do not establish a
|
||||
currency cap. If enforcement is unavailable, adopt and prove an enforceable
|
||||
conservative limit before admitting paid execution. Infrastructure costs are
|
||||
measured separately; adding capacity requires an owner decision.
|
||||
|
||||
G5 counts one admitted capability-change request as one delivery attempt;
|
||||
retries consume the same attempt's cost and handling time and must not inflate
|
||||
the denominator. Cancellation/refusal after admission remains an unsuccessful
|
||||
attempt with a reason. A human's planned review/release approval is expected;
|
||||
manual repair, re-prompting to rescue output, or bypassing a failed gate prevents
|
||||
that attempt from counting as accepted without repair. Five clean trivial runs
|
||||
cannot stand in for five useful changes with predeclared acceptance criteria.
|
||||
|
||||
## Project retirement
|
||||
|
||||
Archive only when G0–G5 have accepted evidence, the permanent owners have
|
||||
accepted operating responsibility, and every actionable residual has a live
|
||||
owner record outside the closing narrative. Update HelixForge's durable
|
||||
capability/operating documentation and owning repos' runbooks; retain links to
|
||||
merged/published revisions, deployment evidence, decisions and residual IDs in
|
||||
a completion record. Do not archive or shut down any participating service as
|
||||
part of retiring this coordination repository.
|
||||
|
||||
External tenant onboarding, autonomous production release, additional rein/model
|
||||
families, full HA and commercial-company success are outside these gates.
|
||||
`UPC-WP-0003` retains its separate ≥30-day company-load objective.
|
||||
|
|
@ -4,12 +4,13 @@ The user authorized implementation on 2026-09-08. The dedicated Git project now
|
|||
lives at [/home/worsch/prj-helixforge-factory](/home/worsch/prj-helixforge-factory/README.md).
|
||||
Its [current workplan](/home/worsch/prj-helixforge-factory/workplans/HFACT-WP-0001-establish-internal-factory.md)
|
||||
and [delivery evidence](/home/worsch/prj-helixforge-factory/evidence/2026-09-08-delivery.md)
|
||||
own ongoing coordination. Forgejo repository creation and central registration
|
||||
await the routed OpenBao caller login.
|
||||
own ongoing coordination. The private
|
||||
[canonical Forgejo project](https://forgejo.coulomb.social/coulomb/prj-helixforge-factory)
|
||||
is published and registered with State Hub under the helix-forge topic.
|
||||
|
||||
The other files in this directory are the **frozen original proposal**, retained
|
||||
until canonical project publication succeeds. Do not update them as a second
|
||||
programme. HFACT-WP-0001 in the dedicated project is the current source.
|
||||
The original proposal files were removed after canonical publication; their
|
||||
history remains in Git. HFACT-WP-0001 in the dedicated project is the current
|
||||
source. This directory is only a pointer.
|
||||
|
||||
Internal capability: **reuse-surface** (REUSE-WP-0022, completed and published).
|
||||
Customer service/UI product: **vergabe-teilnahme** (VERGABE-WP-0018; source and
|
||||
|
|
|
|||
|
|
@ -1,55 +0,0 @@
|
|||
# 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.
|
||||
|
|
@ -1,44 +0,0 @@
|
|||
# Proposed factory dependency map
|
||||
|
||||
Date: 2026-09-08. This is a source proposal for acceptance sequencing. Actual
|
||||
owner task statuses remain in their repositories and the derived Hub.
|
||||
Stage/receipt is not inferred from the existence of a message or package.
|
||||
|
||||
| Project gate | Supplying record(s) | Current return / next evidence | Factory effect |
|
||||
| --- | --- | --- | --- |
|
||||
| T03 identity admission | KEY-WP-0013-T02; platform custody record to be resolved through the existing Glas request | Two service clients and protected consumer delivery remain unproven. Tenant choice is resolved. Identify the exact admitted custody record; do not substitute a generic database lane. | Blocks approval service acceptance |
|
||||
| T03 audit admission | AUDIT-WP-0009-T03/T09; APPROVAL-WP-0002-T01 | Evidence kind is implemented; sender scope/secret policy and credential admission need owner returns. T09 is already high priority/progress. | Blocks approval startup |
|
||||
| T03 approval | APPROVAL-WP-0002-T01/T03/T05 | Published image is pinned. Latest recorded production review found no deployed service. Need identity, audit, rollout, claim/consume and restart/restore receipts. | Blocks native credential action |
|
||||
| T03 credentials | SECRETS-WP-0009-T03; SECRETS-WP-0007-T04 and SECRETS-WP-0008-T02/T06 as applicable | September 7 decision-path proof resolved digest normalization; remaining external dependency is the approval claim endpoint. Need real scoped activation/delivery evidence. | Blocks paid real-model proof |
|
||||
| T04 runtime/profile | SAND-WP-0015-T04; GLAS-WP-0012-T02–T06 | Pinned startup candidate and synthetic transport exist. Need protected placement, native credentials, real model, exact binding, teardown and negative evidence. | Blocks current local profile readiness |
|
||||
| T05 worker | REINAH-WP-0003-T05/T06; ACTIVITY-WP-0032-T05, ACTIVITY-WP-0035-T08, ACTIVITY-WP-0036-T04 | Queue and repository boundaries exist; current source heartbeat correction needs deployed natural trace and controlled late-close evidence. | Blocks governed production lane |
|
||||
| T05 placement | railiance-master admission contracts; concrete runtime/reef owner record selected in T01 | Existing user-service worker on railiance01 is the starting point. Require explicit ownership and admitted profile/credential/recovery contract for this host. | Blocks claim that the local proof operates on Railiance |
|
||||
| T06 delivery | Chosen source repo record and consuming repo record selected in T01; existing forge/enablement contracts | No existing end-to-end HelixForge factory acceptance owner was found. Adopt bounded useful-change/release work, with independent tests and actual consumer. | Blocks useful factory result |
|
||||
| T07 recovery | REINAH-WP-0003-T05; RPF-WP-0038-T04 and actual pilot workload/package owner | Restore demonstrations exist; scheduled caller, inventory/retention and current worker/pilot recovery still need exact coverage. | Bounds operating readiness |
|
||||
| T08 value/load | HelixForge acceptance; UPC-WP-0003 as receiving context | No current fourteen-day factory delivery/load evidence was established by this assessment. | Blocks repeatability claim |
|
||||
|
||||
GLAS-WP-0015 is the existing owner-handoff coordinator for T03/T04. The factory
|
||||
project consumes its results and adds the software-delivery/operating acceptance
|
||||
that it does not own. Do not create parallel identity/audit/runtime coordination.
|
||||
|
||||
When adopting the map, record canonical task IDs, accountable contact, required
|
||||
receipt, source revision and next review condition in each owner handoff. Set
|
||||
structured dependency fields/edges only with the supported source/projection
|
||||
semantics; do not invent an API convention or overwrite source UUIDs.
|
||||
|
||||
Separate lanes retained outside the factory critical path:
|
||||
|
||||
- `NK-WP-0033/0034` and `RPF-WP-0027`: known incident/verification closure.
|
||||
Resolve impact on the proposed privilege boundary before expansion; ordinary
|
||||
incident priority is not displaced by factory WIP limits.
|
||||
- `RMASTER-WP-0020-T08`: retained CoulombCore cleanup, with recovery and explicit
|
||||
destructive-approval gates. It is not a prerequisite to installing the factory.
|
||||
- `RMASTER-WP-0020-T09`, `RPF-WP-0025`, `RAPP-OPENBAO-WP-0002`, `NK-WP-0032`:
|
||||
public listener/private login migration. Preserve existing requirements; do not
|
||||
merge it into native service delivery unless an owner demonstrates dependency.
|
||||
- `STATE-WP-0079`, `CORE-WP-0010`, relevant `HUB-*` and `RAPPCOREHUB-*` work:
|
||||
staged hub migration, with receiver and quiet-window gates. Keep existing
|
||||
coordination operational while the factory consumes stable contracts.
|
||||
- `CUST-WP-0038`, ThreePhoenix HA, enterprise federation, broad repository
|
||||
renames, extra rein/model profiles and publication campaigns: separate benefit
|
||||
decisions; no blanket factory dependency.
|
||||
|
|
@ -1,24 +0,0 @@
|
|||
# Genesis — 2026-09-08
|
||||
|
||||
The operator asked the Custodian to assess the Coulomb, HelixForge and Railiance
|
||||
ecosystem, especially blocked/open workplan load, and provide a plan for an
|
||||
agentic software factory.
|
||||
|
||||
The pre-proposal Hub snapshot contained 98 open workplan rows. Four explicitly
|
||||
retired identities reduced the canonical baseline to 94 plans, 27 blocked,
|
||||
containing 264 open tasks. All 94 matched local source workplan status. The
|
||||
direct execution cohort contained nine plans and fifteen open tasks; much of
|
||||
the remaining dependency load concerned identity/custody/audit and Railiance.
|
||||
|
||||
The proposal consumes existing GLAS-WP-0015 coordination and implementation
|
||||
work. Its distinct deliverable is a useful, repeatable capability delivery loop
|
||||
on Railiance with operating evidence and measurable human load. This avoids
|
||||
mistaking either source-complete components or the HelixForge publication
|
||||
programme for a functioning software factory.
|
||||
|
||||
Source assessment:
|
||||
`the-custodian/docs/assessments/2026-09-08-helixforge-factory.md`.
|
||||
Captured baseline and provenance live beside that report. This packet remains a
|
||||
draft in the Custodian until HFACT-WP-0001-T01 establishes its dedicated project
|
||||
source and verifies the prefix with the registrar. No factory work was activated
|
||||
and no owner was contacted by this assessment.
|
||||
|
|
@ -1,320 +0,0 @@
|
|||
---
|
||||
id: HFACT-WP-0001
|
||||
type: workplan
|
||||
title: "Establish the internal HelixForge software factory on Railiance"
|
||||
domain: infotech
|
||||
repo: prj-helixforge-factory
|
||||
status: proposed
|
||||
owner: the-custodian
|
||||
topic_slug: infotech
|
||||
created: "2026-09-08"
|
||||
updated: "2026-09-08"
|
||||
related:
|
||||
- GLAS-WP-0012
|
||||
- GLAS-WP-0015
|
||||
- SAND-WP-0015
|
||||
- REINAH-WP-0003
|
||||
- ACTIVITY-WP-0032
|
||||
- ACTIVITY-WP-0035
|
||||
- ACTIVITY-WP-0036
|
||||
- KEY-WP-0013
|
||||
- APPROVAL-WP-0002
|
||||
- SECRETS-WP-0009
|
||||
- AUDIT-WP-0009
|
||||
- RPF-WP-0038
|
||||
- UPC-WP-0003
|
||||
---
|
||||
|
||||
# Establish the internal factory
|
||||
|
||||
**Proposal only.** Prepared in the Custodian on 2026-09-08; not yet a registered
|
||||
project or an execution authorization. Prefix allocation and adoption are T01.
|
||||
The assessment is complete; the eight tasks below are future factory work.
|
||||
|
||||
The [goal](../GOAL.md) defines success. The [dependency map](../dependency-map.md)
|
||||
identifies existing work to consume. This workplan owns integration acceptance
|
||||
and handoff; it neither replaces nor copies child implementation plans.
|
||||
|
||||
Recommended sequence:
|
||||
|
||||
```text
|
||||
T01 → T02
|
||||
T01 → T03 ─┐
|
||||
T01 → T04 ─┴→ T05 → T06 → T08
|
||||
T01 → T07 ───────────────→ T08
|
||||
```
|
||||
|
||||
T04 runtime preparation can advance before T03 finishes; real model acceptance
|
||||
cannot. T07 recovery preparation can advance early; its live proof depends on
|
||||
the deployed T05/T06 configuration. T02 is complete before regular scheduling.
|
||||
|
||||
## T01 — Adopt the project and select the first valuable capability
|
||||
|
||||
```task
|
||||
id: HFACT-WP-0001-T01
|
||||
status: todo
|
||||
priority: high
|
||||
assignee: the-custodian
|
||||
```
|
||||
|
||||
Coordinator: the-custodian. Acceptance: the HelixForge product owner and the
|
||||
operator responsible for Railiance. Estimated effort: 1–2 engineering days.
|
||||
|
||||
Review this packet against current published owner revisions, confirm a unique
|
||||
prefix, establish the dedicated project repo under ADR-005, publish/register it
|
||||
through the authorized path, and sync its source records. Retain a pointer from
|
||||
the Custodian rather than two editable copies of the programme.
|
||||
|
||||
Select a **small, useful software service or library capability** with a
|
||||
repeatable independent test, a known release path and a second consuming repo.
|
||||
Prefer an existing internal workload and existing CI. Avoid beginning with
|
||||
identity, credential or production-control code as the agent's pilot target.
|
||||
HelixForge owns the demand/contract; the actual source and consumer owners
|
||||
accept the bounded implementation records. Record why this capability matters
|
||||
and the expected reuse before selecting a convenient task from the queue.
|
||||
|
||||
Confirm one internal tenant, exact actor/project/repository/profile tuple,
|
||||
human acceptance and operating owners, allowed branch/push/release effects,
|
||||
the proposed G0–G5 targets, capacity allocation and an enforceable spend/time
|
||||
envelope. Assess the outstanding NK-WP-0033/0034 verification incident against
|
||||
the proposed privilege path; require applicable closure or an explicit scoped
|
||||
owner disposition before expanding it.
|
||||
|
||||
Done when G0 is accepted in a source-backed decision, the project and concrete
|
||||
pilot work are registered, and a future operator can determine who may run,
|
||||
review and release it without reconstructing this assessment. Recording a
|
||||
proposal does not grant execution or spending rights.
|
||||
|
||||
## T02 — Make the selected backlog actionable
|
||||
|
||||
```task
|
||||
id: HFACT-WP-0001-T02
|
||||
status: wait
|
||||
priority: high
|
||||
assignee: the-custodian
|
||||
depends_on: [HFACT-WP-0001-T01]
|
||||
blocking_reason: "Await project adoption and selection of the pilot dependency chain in T01."
|
||||
```
|
||||
|
||||
Dependency: T01. Coordinator: the-custodian with source/projection owners.
|
||||
Estimated effort: 1 engineering day, plus genuinely necessary projection fixes.
|
||||
|
||||
Use the 94-plan/264-task baseline as the dated starting point. Review the four
|
||||
retired open identities, seventeen terminal human flags, terminal-parent tasks
|
||||
and the unmatched local KG-WP-0005 through their existing owning paths. Do not
|
||||
bulk-delete history or set statuses to improve a dashboard total.
|
||||
Existing CUST-IN-0017 owns the thirteen Custodian historical consistency
|
||||
failures and prefix conflict; reuse it rather than duplicate its triage.
|
||||
|
||||
For the pilot chain, ensure every waiting task has a supplying task/record,
|
||||
accountable contact, precise return evidence, actual next action and review
|
||||
condition; set human-needed only for real human dependencies. Capture published
|
||||
source revision and freshness. Check projections without making the retiring
|
||||
State Hub a new permanent owner. Refer off-path cleanup to existing owners;
|
||||
it does not hold up the factory after its own records are trustworthy.
|
||||
|
||||
Adopt a factory WIP limit of one integrated delivery item plus two prerequisite
|
||||
closures, with a named incident exception. Any wider portfolio reprioritization
|
||||
remains a recommendation until owners accept it.
|
||||
|
||||
Done when the selected chain has complete actionable dependencies, a short
|
||||
prepared human queue and a repeatable next-pick view; retired/terminal evidence
|
||||
is excluded from current demand without losing residual ownership.
|
||||
|
||||
## T03 — Accept the existing identity, audit, approval and credential chain
|
||||
|
||||
```task
|
||||
id: HFACT-WP-0001-T03
|
||||
status: wait
|
||||
priority: high
|
||||
assignee: the-custodian
|
||||
depends_on: [HFACT-WP-0001-T01]
|
||||
blocking_reason: "Await T01 adoption; live returns are owed by KEY-WP-0013-T02, AUDIT-WP-0009-T09, APPROVAL-WP-0002 and SECRETS-WP-0009-T03."
|
||||
```
|
||||
|
||||
Dependency: T01. Existing coordinator: GLAS-WP-0015. Supplying owners:
|
||||
KEY-WP-0013-T02, AUDIT-WP-0009-T09, APPROVAL-WP-0002-T01/T03/T05,
|
||||
SECRETS-WP-0009-T03 and exact linked custody/authorization records.
|
||||
Rough shared effort with T04: 4–8 engineering days plus owner waiting.
|
||||
|
||||
Consume the existing seven-owner handoff packet. Identify the exact custody
|
||||
record for both service clients and the audit sender; first-provision authority
|
||||
cannot depend on the unprovisioned service. Keep the accepted tenant spelling
|
||||
and proved policy/digest behavior pinned. Distinguish service-only admission
|
||||
from a human callback requirement with owner evidence, not assumption.
|
||||
|
||||
Accept the real identity/custody, audit admission, deployed approval claim and
|
||||
consume, and native credential delivery receipts from the owners. Evidence must
|
||||
include successful binding and relevant wrong-tenant/scope, denied/reused action
|
||||
and out-of-scope read rejection, plus revocation/expiry and non-secret audit
|
||||
references. An image digest or a delivered message alone closes no live gate.
|
||||
|
||||
Done when native credential delivery for the exact proof tuple is verified
|
||||
through the current owner contracts, with no bypass and no outstanding startup
|
||||
prerequisite. Record later audit freshness/detection obligations separately;
|
||||
admission success is not a completeness or tamper-evidence claim.
|
||||
|
||||
## T04 — Accept the real profile and prepare its Railiance placement
|
||||
|
||||
```task
|
||||
id: HFACT-WP-0001-T04
|
||||
status: wait
|
||||
priority: high
|
||||
assignee: the-custodian
|
||||
depends_on: [HFACT-WP-0001-T01]
|
||||
blocking_reason: "Await T01 adoption for preparation; the real-model portion also requires T03 native credential acceptance."
|
||||
```
|
||||
|
||||
Dependency: T01; real model execution also requires T03. Supplying owners:
|
||||
SAND-WP-0015-T04, GLAS-WP-0012-T02–T06 and concrete Railiance admission owners.
|
||||
|
||||
Accept protected installation of the already pinned runtime candidate and its
|
||||
owner configuration. Reuse the existing real-rein acceptance contract: exact
|
||||
profile/actor/project, provider path, model-created artifact, declared effects,
|
||||
denial, cleanup and rollback to the retained blocked selection on failure.
|
||||
Review changed pins as a new compatibility set. Do not re-prove resolved
|
||||
candidate startup unless the artifact, environment or contract changed.
|
||||
|
||||
Then define the production-specific railiance01 placement, runtime owner,
|
||||
profile/grant, credential path, service restart behavior and recovery inventory.
|
||||
Start from the evidenced host user-service worker. Satisfy the owning
|
||||
Railiance rail/rapp/reef admission contract; if the current host service needs
|
||||
an ownership/admission record, create it in that owner rather than assuming
|
||||
Kubernetes packaging is the production process. A localhost-only profile needs
|
||||
explicit target-specific acceptance.
|
||||
|
||||
Done when G1 passes, the local result has acknowledged owner receipts, and the
|
||||
Railiance configuration is concrete and admissible for T05. G2 is not closed
|
||||
by this task's local proof.
|
||||
|
||||
## T05 — Close the current worker and queue loop on Railiance
|
||||
|
||||
```task
|
||||
id: HFACT-WP-0001-T05
|
||||
status: wait
|
||||
priority: high
|
||||
assignee: the-custodian
|
||||
depends_on: [HFACT-WP-0001-T02, HFACT-WP-0001-T03, HFACT-WP-0001-T04]
|
||||
blocking_reason: "Await actionable admission records, owner credential chain and accepted profile/placement from T02-T04."
|
||||
```
|
||||
|
||||
Dependencies: T02–T04. Supplying work: REINAH-WP-0003-T05/T06,
|
||||
ACTIVITY-WP-0032-T05, ACTIVITY-WP-0035-T08, ACTIVITY-WP-0036-T04.
|
||||
Estimated effort: 2–3 engineering days excluding upstream changes.
|
||||
|
||||
Join the admitted task to the existing ActivityDefinition / ops_run intake and
|
||||
current versioned profile/repository-grant contract. If a small intake adapter
|
||||
is missing, record it in the proper owner and implement only that bounded gap;
|
||||
the retired workplan launch endpoint is not a shortcut. Keep the definition
|
||||
disabled until the owner's live readiness gates are accepted.
|
||||
|
||||
Accept the deployed pin and a natural claim → immediate heartbeat → execution
|
||||
→ accepted terminal close trace. Require a controlled late-close/lease-loss
|
||||
negative case, correct changed paths and commit ancestry, external metrics,
|
||||
clean source state and sandbox teardown. Exercise the current durable close
|
||||
outbox without duplicate mutation. A healthy API poll is not an executed task.
|
||||
|
||||
Done when G2 passes under the exact Railiance artifact/configuration and the
|
||||
Activity Core, rein and Glas owners accept the same run evidence. Return it to
|
||||
their existing tasks rather than leaving source-complete/live-wait tails open.
|
||||
|
||||
## T06 — Deliver and reuse a useful capability through the existing release path
|
||||
|
||||
```task
|
||||
id: HFACT-WP-0001-T06
|
||||
status: wait
|
||||
priority: high
|
||||
assignee: the-custodian
|
||||
depends_on: [HFACT-WP-0001-T05]
|
||||
blocking_reason: "Await the current governed Railiance worker proof in T05."
|
||||
```
|
||||
|
||||
Dependency: T05; capability and owning implementation records selected in T01.
|
||||
Acceptance: HelixForge product owner, source/consumer maintainers and workload
|
||||
operator. Estimated effort: 3–5 engineering days.
|
||||
|
||||
Drive the selected human demand through capability intent, contract and relevant
|
||||
OAS structural/semantic validation. The bounded agent change must satisfy an
|
||||
independent predeclared test oracle and normal maintainer review. Record reuse
|
||||
search and why an existing capability is extended or a new one is justified.
|
||||
|
||||
Use the source repo's current Forgejo workflow, or adopt the existing
|
||||
railiance-enablement template where needed. Join source commit, CI evidence,
|
||||
artifact digest/package version and release configuration revision. Apply only
|
||||
the separately authorized release through the actual workload owner. Validate
|
||||
the service behavior on Railiance and exercise the agreed rollback. Have the
|
||||
second repo consume/reuse the capability and retain its acceptance evidence.
|
||||
|
||||
Done when G3 passes and the evidence chain links demand → contract → task/run
|
||||
→ accepted change → CI → immutable artifact → authorized release → operational
|
||||
result → reuse. Update the durable HelixForge capability/operating entry. A
|
||||
generated document, empty commit or deterministic smoke alone is insufficient.
|
||||
|
||||
## T07 — Establish recoverable, measurable operation
|
||||
|
||||
```task
|
||||
id: HFACT-WP-0001-T07
|
||||
status: wait
|
||||
priority: high
|
||||
assignee: the-custodian
|
||||
depends_on: [HFACT-WP-0001-T01]
|
||||
blocking_reason: "Await T01 adoption for design; final live recovery proof requires the deployed T05/T06 configuration."
|
||||
```
|
||||
|
||||
Dependency: T01 for design; T05/T06 for final deployed proof. Supplying owners:
|
||||
REINAH-WP-0003-T05, the selected workload/package/reef owner and applicable
|
||||
RPF-WP-0038-T04 recovery/custody coverage. Estimated effort: 2–3 engineering days.
|
||||
|
||||
Consolidate existing receipts for timeout/spend enforcement, worker death,
|
||||
lease conflict, pending terminal-close replay, credential failure and sandbox
|
||||
cleanup. Use disposable work and the current deployed configuration. Include
|
||||
proof that a queue/Hub outage cannot produce duplicate accepted changes and
|
||||
that restarting restores the right pending evidence. Bind backups and recovery
|
||||
inventory to the actual host service, forge/artifacts and pilot workload.
|
||||
|
||||
Record per attempt queue wait, execution time, accepted/rejected result,
|
||||
retries, failure class, human handling, model cost, relevant infrastructure cost
|
||||
and release result. Include refused/admitted failures in denominators. Use
|
||||
existing evidence and cost owners; start with a small generated scorecard if
|
||||
automated aggregation is absent. Monitoring must distinguish a stale receipt
|
||||
from a healthy current worker and alert the responsible operator through an
|
||||
already authorized channel.
|
||||
|
||||
Done when G4 passes, rollback/recovery is executable by the named owner, costs
|
||||
are bounded, and the measurement process can sustain G5 without reconstructing
|
||||
individual agent sessions. Required audit claims are either freshly proved or
|
||||
accurately degraded; unresolved detection work retains live owner records.
|
||||
|
||||
## T08 — Accept repeated delivery, transfer ownership and retire the project
|
||||
|
||||
```task
|
||||
id: HFACT-WP-0001-T08
|
||||
status: wait
|
||||
priority: high
|
||||
assignee: the-custodian
|
||||
depends_on: [HFACT-WP-0001-T06, HFACT-WP-0001-T07]
|
||||
blocking_reason: "Await useful delivery and operational controls from T06/T07, then the complete fourteen-day observation window."
|
||||
```
|
||||
|
||||
Dependencies: T06 and T07. Reviewers: HelixForge acceptance owner, Railiance
|
||||
operating owner and the-custodian. Effort: 1–2 engineering days for review and
|
||||
handoff plus fourteen calendar days of observation.
|
||||
|
||||
Run the accepted fourteen-day G5 window. Admit at least five useful changes
|
||||
across two repositories and preserve all attempts, costs, failure/repair events
|
||||
and human time. If a target is missed, classify the limiting defect, create or
|
||||
update its owner work record, and repeat the affected acceptance window after
|
||||
correction. Do not redefine the metrics retrospectively to mark the project done.
|
||||
|
||||
Publish the operating runbook and capability/contract references in permanent
|
||||
homes, including correction of HelixForge's stale Inter-Hub/nested State Hub
|
||||
orientation where relevant. Hand the measured factory evidence to the company
|
||||
project's UPC-WP-0003 acceptance context without claiming its longer window or
|
||||
commercial goals complete. Additional tenants, model families, HA or unattended
|
||||
release receive new benefit/authority decisions, not automatic activation.
|
||||
|
||||
Done when G0–G5 are accepted, durable owners acknowledge handoff, all actionable
|
||||
residuals are live records, and the completion record lists owning repos,
|
||||
merged/published revisions, deployment/rollback evidence and residual IDs.
|
||||
Only then finish this workplan, synchronize it and archive the project as
|
||||
read-only provenance. Participant services continue under their owners.
|
||||
Loading…
Add table
Add a link
Reference in a new issue