diff --git a/ArchitectureBlueprint.md b/ArchitectureBlueprint.md index 0dfbb98..79da04b 100644 --- a/ArchitectureBlueprint.md +++ b/ArchitectureBlueprint.md @@ -74,7 +74,7 @@ stack rather than inside it. | evidence plane | `railiance-telemetry` | metrics, logs, traces, alerting — the substrate other layers emit into (**OPEN** placement, §5.1) | | architecture | `railiance-master` | repo taxonomy, framework ADRs, boundary rules, vocabulary | | ecosystem graph | `railiance-fabric` | repo → service → capability → interface → dependency model | -| forge | `railiance-forge` | source hosting, registries, automation runners (**OPEN** placement, §5.2) | +| forge | `railiance-forge` | source hosting, registries, automation runners — **being placed** (§5.2): workload → `rapp-forgejo`, layer responsibility → S4 | ### The layering contract @@ -156,12 +156,23 @@ by all of them. Is it an S3 platform capability (it runs stateful services and is consumed by others), or a Quality-dimension concern outside the Stack dimension? Stated explicitly at seeding so it does not drift into §5.2's state. -### 5.2 Where does `railiance-forge` sit? → `railiance-master` +### 5.2 Where does `railiance-forge` sit? → **DECIDED 2026-08-11** -It calls itself "the forge layer", but the stack has five levels and forge is -not one. Options: part of S4, a sixth level, or cross-cutting. +**Place it, do not retire it.** Operator decision: -Note the retirement hypothesis was **tested and rejected**: `railiance-forge` +- the Forgejo **workload** becomes `rapp-forgejo` (a managed workload package) +- the **layer responsibility** — runner placement and labels, registry + retention, artifact lifecycle, package credentials — folds into **S4 + `railiance-enablement`**, which already declares the handoff contract for + exactly these concerns + +This also gives S4, currently the widest aspiration-to-reality gap in the +family, its first concrete owned responsibility. + +Implementation is `railiance-master` and `railiance-forge` territory; this +blueprint records the decision, not the migration. + +The retirement hypothesis was **tested and rejected**: `railiance-forge` and `helix-forge` are different lineages. `helix-forge` is methodological (capability-first ecosystem, OAS dimensions, VSM vocabulary); `railiance-forge` is operational (`helm/`, `manifests/`, `releases/`, `runner/`, live workplan on @@ -186,6 +197,23 @@ to `railiance-master` (`04c776c4`, amended `f88f938d`). - delete the local `~/railiance-bootstrap` directory, which is a mis-cloned copy of `railiance-cluster.git` +### 5.6 Does Railiance use ArgoCD at all? → **OPEN**, `railiance-master` + +Raised by the operator 2026-08-11: GitOps-by-ArgoCD may be Helix Forge tooling +rather than a Railiance concern, or may not be needed at all. + +**This cannot be resolved by editing documentation.** S3 currently runs ArgoCD +as its live deployment mechanism: four Application manifests +(`external-secrets`, `issue-core`, `openbao-secretstore`, `target-revenue`), +AppProjects under `argocd/bootstrap/`, `docs/argocd-gitops.md`, and the two most +recent commits in this repo add ArgoCD Applications. Removing mentions while the +Applications remain would make the documentation describe a system that does not +exist. + +The real question is an architecture decision — *should S3 deploy via ArgoCD?* — +with a migration attached if the answer is no. Until it is taken, mentions stay +because they are accurate. + ### 5.5 Rapp granularity and composition → decided, implementation open Grouped by bounded context; members declared explicitly; grouping legitimate diff --git a/docs/credential-lane-lifecycle-runbook.md b/docs/credential-lane-lifecycle-runbook.md index 38647f2..0b943a2 100644 --- a/docs/credential-lane-lifecycle-runbook.md +++ b/docs/credential-lane-lifecycle-runbook.md @@ -46,8 +46,8 @@ secret value ever appears in Git, State Hub, chat, prompts, or shell history. `force-sync`), then restart `deploy/actcore-worker` and `deploy/actcore-event-router`, or activity-core emission silently starts failing with 401s on the next run. -- `GITEA_BACKEND_TOKEN` is a scoped Gitea token for service user - `issue-core-svc`; rotating it means minting a new token in Gitea first, +- `GITEA_BACKEND_TOKEN` is a scoped Forgejo token for service user + `issue-core-svc`; rotating it means minting a new token in Forgejo first, then updating OpenBao — order matters, or ingestion breaks between steps. ## Lane: llm-connect OpenRouter provider key (`CCR-2026-0003`) diff --git a/docs/openbao.md b/docs/openbao.md index 01d35ac..449b073 100644 --- a/docs/openbao.md +++ b/docs/openbao.md @@ -124,14 +124,14 @@ unseal keys and initial root token. Treat this as a break-glass event. ### Setup Operator And King Credential The initial accountable setup operator/contact is `tegwick` -(`bernd.worsch@gmail.com`), with Gitea identity `tegwick`. This identity can +(`bernd.worsch@gmail.com`), with Forgejo identity `tegwick`. This identity can assemble early infrastructure, receive notifications, and operate day-to-day -Git/Gitea workflows, but it is not the desired long-term platform root of +Git/Forgejo workflows, but it is not the desired long-term platform root of trust. The actual platform-root target is a separate king credential created through the NetKingdom bootstrap path before OpenBao becomes live secret custody. Email -may receive notifications, but Gitea, Git, State Hub, chat, tickets, shell +may receive notifications, but Forgejo, Git, State Hub, chat, tickets, shell history, and email must not store or transfer OpenBao unseal keys, root tokens, private keys, OTP seeds, recovery codes, or screenshots of secret output. @@ -316,7 +316,7 @@ Initial auth model: | Actor | Method | Notes | |-------|--------|-------| -| Setup operator/contact | Gitea `tegwick` / `bernd.worsch@gmail.com` | low-trust assembly and notifications; not platform root of trust | +| Setup operator/contact | Forgejo `tegwick` / `bernd.worsch@gmail.com` | low-trust assembly and notifications; not platform root of trust | | King credential | NetKingdom custody record for dedicated platform-root identity | accountable bootstrap/recovery authority; not a Git or email secret store | | Bootstrap operator | one-time root token | only for initial audit, mounts, auth, policies, and non-root token creation | | Platform operator | token with `platform-admin` | temporary until NetKingdom OIDC/admin integration is ready | diff --git a/docs/whynot-design-npm-publish-handoff.md b/docs/whynot-design-npm-publish-handoff.md index ef65a30..6741fa8 100644 --- a/docs/whynot-design-npm-publish-handoff.md +++ b/docs/whynot-design-npm-publish-handoff.md @@ -17,10 +17,10 @@ This is the next-session handoff for `CCR-2026-0001` and the - Bound IAM group: `whynot-design` - Secret path: `platform/workloads/coulomb/whynot-design/npm-publish` - Field: `NPM_AUTH_TOKEN` -- Token source: Gitea package token for +- Token source: Forgejo package token for `https://forgejo.coulomb.social/api/packages/coulomb/npm/` -The operator reported that the Gitea token was generated and stored in OpenBao. +The operator reported that the Forgejo token was generated and stored in OpenBao. Using the temporary operator token only for non-secret infrastructure work, Codex confirmed that the policy exists, the OIDC role exists with the whynot-design binding and redirect URIs, the secret metadata has the expected catalog id, and