rcf-lite 0.24.0 → 0.26.0

package/blueprints/security-auth-clerk/docs/topics.md

@@ -46,7 +46,7 @@ This table is maintained shelf-wide across every blueprint's `docs/topics.md`. R
 | application-account-settings | 25101-25899 | 26xx | shipped v1.0.0 | none |
 | application-onboarding-tour | 26101-26899 | 27xx | shipped v1.0.0 | none |
 | persistence-data-postgres | 27101-27899 | 28xx | shipped v1.0.0 | `persistenceStore`, `migrationDiscipline` |
-| object-storage-s3 | 28101-28899 | 29xx | shipped v1.0.0 | `objectStorageContract` |
+| object-storage-s3 | 28101-28899 | 29xx | shipped v1.1.0 | `objectStorageContract` |
 | messaging-queue-cloudflare | 29101-29899 | 30xx | shipped v1.0.0 | `deliverySemantics` |
 | jobs-background | 30101-30899 | 31xx | shipped v1.0.0 | `backgroundJobModel` |
 | platform-cloudflare-kv | 31101-31899 | 32xx | shipped v1.0.0 | `keyValueStoreContract` |
@@ -55,6 +55,9 @@ This table is maintained shelf-wide across every blueprint's `docs/topics.md`. R
 | edge-cloudflare-access | 34101-34899 | 35xx | shipped v1.0.0 | `edgeAuthenticationGate` |
 | edge-cloudflare-turnstile | 35101-35899 | 36xx | shipped v1.0.0 | `humanVerificationGate` |
 | edge-cloudflare-rate-limiting | 36101-36899 | 37xx | shipped v1.0.0 | `edgeThrottleContract` |
+| deploy-hetzner-server | 37101-37899 | 38xx | shipped v1.0.0 | `linuxCloudHostContract`, `snapshotAndBackupCadence` |
+| platform-docker-compose-host | 38101-38899 | 39xx | shipped v1.0.0 | `containerHostContract` |
+| edge-cloudflare-tunnel | 39101-39899 | 40xx | shipped v1.0.0 | `edgeIngressBridge` |
 
 US 9101-9110 sit at the LOW end of the 9101-9899 band on purpose. A project-side story that mechanically derives from a security-auth-clerk REQ id into the number `9110` would collide against security-auth-clerk-US-9110 in this package; the band leaves headroom at the HIGH end (US 9181-9899) so a project's own stories anchored to security-auth-clerk REQs can allocate without conflict. The watchpost run4 lesson applies here too.
 

package/blueprints/security-auth-keycloak/docs/topics.md

@@ -57,7 +57,7 @@ This table is maintained shelf-wide across every blueprint's `docs/topics.md`. R
 | application-account-settings | 25101-25899 | 26xx | shipped v1.0.0 | none |
 | application-onboarding-tour | 26101-26899 | 27xx | shipped v1.0.0 | none |
 | persistence-data-postgres | 27101-27899 | 28xx | shipped v1.0.0 | `persistenceStore`, `migrationDiscipline` |
-| object-storage-s3 | 28101-28899 | 29xx | shipped v1.0.0 | `objectStorageContract` |
+| object-storage-s3 | 28101-28899 | 29xx | shipped v1.1.0 | `objectStorageContract` |
 | messaging-queue-cloudflare | 29101-29899 | 30xx | shipped v1.0.0 | `deliverySemantics` |
 | jobs-background | 30101-30899 | 31xx | shipped v1.0.0 | `backgroundJobModel` |
 | platform-cloudflare-kv | 31101-31899 | 32xx | shipped v1.0.0 | `keyValueStoreContract` |
@@ -66,6 +66,9 @@ This table is maintained shelf-wide across every blueprint's `docs/topics.md`. R
 | edge-cloudflare-access | 34101-34899 | 35xx | shipped v1.0.0 | `edgeAuthenticationGate` |
 | edge-cloudflare-turnstile | 35101-35899 | 36xx | shipped v1.0.0 | `humanVerificationGate` |
 | edge-cloudflare-rate-limiting | 36101-36899 | 37xx | shipped v1.0.0 | `edgeThrottleContract` |
+| deploy-hetzner-server | 37101-37899 | 38xx | shipped v1.0.0 | `linuxCloudHostContract`, `snapshotAndBackupCadence` |
+| platform-docker-compose-host | 38101-38899 | 39xx | shipped v1.0.0 | `containerHostContract` |
+| edge-cloudflare-tunnel | 39101-39899 | 40xx | shipped v1.0.0 | `edgeIngressBridge` |
 
 US 11101-11113 sit at the LOW end of the 11101-11899 band on purpose. A project-side story that mechanically derives from a security-auth-keycloak REQ id into the number `11113` would collide against security-auth-keycloak-US-11113 in this package; the band leaves headroom at the HIGH end (US 11181-11899) so a project's own stories anchored to security-auth-keycloak REQs can allocate without conflict. The watchpost run4 lesson applies here too.
 

package/blueprints/security-auth-magic-link/docs/topics.md

@@ -46,7 +46,7 @@ This table is maintained shelf-wide across every blueprint's `docs/topics.md`. R
 | application-account-settings | 25101-25899 | 26xx | shipped v1.0.0 | none |
 | application-onboarding-tour | 26101-26899 | 27xx | shipped v1.0.0 | none |
 | persistence-data-postgres | 27101-27899 | 28xx | shipped v1.0.0 | `persistenceStore`, `migrationDiscipline` |
-| object-storage-s3 | 28101-28899 | 29xx | shipped v1.0.0 | `objectStorageContract` |
+| object-storage-s3 | 28101-28899 | 29xx | shipped v1.1.0 | `objectStorageContract` |
 | messaging-queue-cloudflare | 29101-29899 | 30xx | shipped v1.0.0 | `deliverySemantics` |
 | jobs-background | 30101-30899 | 31xx | shipped v1.0.0 | `backgroundJobModel` |
 | platform-cloudflare-kv | 31101-31899 | 32xx | shipped v1.0.0 | `keyValueStoreContract` |
@@ -55,6 +55,9 @@ This table is maintained shelf-wide across every blueprint's `docs/topics.md`. R
 | edge-cloudflare-access | 34101-34899 | 35xx | shipped v1.0.0 | `edgeAuthenticationGate` |
 | edge-cloudflare-turnstile | 35101-35899 | 36xx | shipped v1.0.0 | `humanVerificationGate` |
 | edge-cloudflare-rate-limiting | 36101-36899 | 37xx | shipped v1.0.0 | `edgeThrottleContract` |
+| deploy-hetzner-server | 37101-37899 | 38xx | shipped v1.0.0 | `linuxCloudHostContract`, `snapshotAndBackupCadence` |
+| platform-docker-compose-host | 38101-38899 | 39xx | shipped v1.0.0 | `containerHostContract` |
+| edge-cloudflare-tunnel | 39101-39899 | 40xx | shipped v1.0.0 | `edgeIngressBridge` |
 
 US 3101-3111 sit at the LOW end of the 3101-3899 band on purpose. A project-side story that mechanically derives from `security-auth-magic-link-REQ-011` into the number `3111` would collide against security-auth-magic-link-US-3111 in this package; the band leaves headroom at the HIGH end (US 3181-3899) so a project's own stories anchored to security-auth-magic-link REQs can allocate without conflict.
 

package/blueprints/security-auth-oauth2/docs/topics.md

@@ -57,7 +57,7 @@ This table is maintained shelf-wide across every blueprint's `docs/topics.md`. R
 | application-account-settings | 25101-25899 | 26xx | shipped v1.0.0 | none |
 | application-onboarding-tour | 26101-26899 | 27xx | shipped v1.0.0 | none |
 | persistence-data-postgres | 27101-27899 | 28xx | shipped v1.0.0 | `persistenceStore`, `migrationDiscipline` |
-| object-storage-s3 | 28101-28899 | 29xx | shipped v1.0.0 | `objectStorageContract` |
+| object-storage-s3 | 28101-28899 | 29xx | shipped v1.1.0 | `objectStorageContract` |
 | messaging-queue-cloudflare | 29101-29899 | 30xx | shipped v1.0.0 | `deliverySemantics` |
 | jobs-background | 30101-30899 | 31xx | shipped v1.0.0 | `backgroundJobModel` |
 | platform-cloudflare-kv | 31101-31899 | 32xx | shipped v1.0.0 | `keyValueStoreContract` |
@@ -66,6 +66,9 @@ This table is maintained shelf-wide across every blueprint's `docs/topics.md`. R
 | edge-cloudflare-access | 34101-34899 | 35xx | shipped v1.0.0 | `edgeAuthenticationGate` |
 | edge-cloudflare-turnstile | 35101-35899 | 36xx | shipped v1.0.0 | `humanVerificationGate` |
 | edge-cloudflare-rate-limiting | 36101-36899 | 37xx | shipped v1.0.0 | `edgeThrottleContract` |
+| deploy-hetzner-server | 37101-37899 | 38xx | shipped v1.0.0 | `linuxCloudHostContract`, `snapshotAndBackupCadence` |
+| platform-docker-compose-host | 38101-38899 | 39xx | shipped v1.0.0 | `containerHostContract` |
+| edge-cloudflare-tunnel | 39101-39899 | 40xx | shipped v1.0.0 | `edgeIngressBridge` |
 
 US 10101-10111 sit at the LOW end of the 10101-10899 band on purpose. A project-side story that mechanically derives from a security-auth-oauth2 REQ id into the number `10111` would collide against security-auth-oauth2-US-10111 in this package; the band leaves headroom at the HIGH end (US 10181-10899) so a project's own stories anchored to security-auth-oauth2 REQs can allocate without conflict. The watchpost run4 lesson applies here too.
 

package/blueprints/security-secrets-management/docs/topics.md

@@ -46,7 +46,7 @@ This table is maintained shelf-wide across every blueprint's `docs/topics.md`. R
 | application-account-settings | 25101-25899 | 26xx | shipped v1.0.0 | none |
 | application-onboarding-tour | 26101-26899 | 27xx | shipped v1.0.0 | none |
 | persistence-data-postgres | 27101-27899 | 28xx | shipped v1.0.0 | `persistenceStore`, `migrationDiscipline` |
-| object-storage-s3 | 28101-28899 | 29xx | shipped v1.0.0 | `objectStorageContract` |
+| object-storage-s3 | 28101-28899 | 29xx | shipped v1.1.0 | `objectStorageContract` |
 | messaging-queue-cloudflare | 29101-29899 | 30xx | shipped v1.0.0 | `deliverySemantics` |
 | jobs-background | 30101-30899 | 31xx | shipped v1.0.0 | `backgroundJobModel` |
 | platform-cloudflare-kv | 31101-31899 | 32xx | shipped v1.0.0 | `keyValueStoreContract` |
@@ -55,6 +55,9 @@ This table is maintained shelf-wide across every blueprint's `docs/topics.md`. R
 | edge-cloudflare-access | 34101-34899 | 35xx | shipped v1.0.0 | `edgeAuthenticationGate` |
 | edge-cloudflare-turnstile | 35101-35899 | 36xx | shipped v1.0.0 | `humanVerificationGate` |
 | edge-cloudflare-rate-limiting | 36101-36899 | 37xx | shipped v1.0.0 | `edgeThrottleContract` |
+| deploy-hetzner-server | 37101-37899 | 38xx | shipped v1.0.0 | `linuxCloudHostContract`, `snapshotAndBackupCadence` |
+| platform-docker-compose-host | 38101-38899 | 39xx | shipped v1.0.0 | `containerHostContract` |
+| edge-cloudflare-tunnel | 39101-39899 | 40xx | shipped v1.0.0 | `edgeIngressBridge` |
 
 US 8101-8110 sit at the LOW end of the 8101-8899 band on purpose. A project-side story that mechanically derives from a security-secrets-management REQ id into the number `8110` would collide against security-secrets-management-US-8110 in this package; the band leaves headroom at the HIGH end (US 8181-8899) so a project's own stories anchored to security-secrets-management REQs can allocate without conflict. The watchpost run4 lesson applies here too.
 

package/fixtures/canary-manifest.json

@@ -1,9 +1,9 @@
 {
   "registerCanary": [
     {
-      "id": "rc-2026-09-07-001",
-      "createdAt": "2026-09-07T23:45:13.314Z",
-      "buildVersion": "0.24.0-mockdriver",
+      "id": "rc-2026-09-09-001",
+      "createdAt": "2026-09-09T16:11:26.221Z",
+      "buildVersion": "0.26.0-mockdriver",
       "fixturePromptId": "canary-prompt-01",
       "responseWordCount": 55,
       "grades": {
@@ -34,9 +34,9 @@
       "shipDespiteFailReason": "mock canary driver used; no real subagent was dispatched. This record verifies canary infrastructure only, not the register itself."
     },
     {
-      "id": "rc-2026-09-07-002",
-      "createdAt": "2026-09-07T23:45:13.315Z",
-      "buildVersion": "0.24.0-mockdriver",
+      "id": "rc-2026-09-09-002",
+      "createdAt": "2026-09-09T16:11:26.222Z",
+      "buildVersion": "0.26.0-mockdriver",
       "fixturePromptId": "canary-prompt-02",
       "responseWordCount": 55,
       "grades": {
@@ -67,9 +67,9 @@
       "shipDespiteFailReason": "mock canary driver used; no real subagent was dispatched. This record verifies canary infrastructure only, not the register itself."
     },
     {
-      "id": "rc-2026-09-07-003",
-      "createdAt": "2026-09-07T23:45:13.315Z",
-      "buildVersion": "0.24.0-mockdriver",
+      "id": "rc-2026-09-09-003",
+      "createdAt": "2026-09-09T16:11:26.222Z",
+      "buildVersion": "0.26.0-mockdriver",
       "fixturePromptId": "canary-prompt-03",
       "responseWordCount": 55,
       "grades": {

package/guidance/harness-template.md

@@ -252,6 +252,73 @@ miss, feed unreachable) say nothing to the operator; freshness is a
 convenience, not a gate. Never run the upgrade without the operator's
 explicit go.
 
+### RULE 15: On blueprint apply, dispose every AC.
+
+A blueprint's acceptance criteria come in two shapes: `fixed`
+(mechanism-invariant, true for every applying project) and `template`
+(shape given, values project-specific). When you apply a blueprint
+(`rcf define blueprint add ...`), walk every AC the blueprint
+contributed. A `fixed` AC stands as authored: do not weaken or drop
+one, and if one appears wrong for the project, that is a defect against
+the blueprint, escalated on the blueprint's repo, not edited locally. A
+`template` AC is a starting shape: actively dispose of it by accepting
+as written, adjusting with the project's values, or dropping with a
+stated reason recorded against the story. Silent inheritance of a
+`template` AC is a defect. After you have disposed of every `template`
+AC, re-sweep the applied AC set against the scenario-class prompt list
+(credential missing, non-2xx, rate limit, timeout, partial write,
+permission denied, malformed input, already exists, gone, concurrent
+access, quota exhausted, dependency not ready, first-vs-repeat run,
+idempotency, empty and maximal collections, boundary values) so the
+story still covers the mechanism's documented failure paths. Any AC
+that rests on a third-party platform fact must show its vendor
+documentation URL and the ISO-8601 date the fact was verified; a
+citation older than the operator's tolerance is re-verified before the
+AC is treated as ground truth.
+
+A blueprint's seed docs are a minimal representational seed set, not a
+project spec. You have full scope of the project you are driving, and
+you are the party best placed to integrate the seed with the project's
+own chain. After you have disposed of every AC, walk the seed's REQs,
+TACs and ADRs against the project chain (existing REQs, TACs, ADRs and
+the PRD/TAD): resolve integration contradictions you can (parameter
+substitution against a settled project value, naming reconciliation
+against a settled project convention, composition-order reconciliation
+against another applied blueprint), record the disposition in the
+tree, and escalate to the operator only the ones that need a
+product-shape decision or a two-way credential or account decision. An
+internal contradiction (two of the seed's own layers disagreeing about
+the same contract) is not yours to resolve; escalate it as a defect
+against the blueprint's repo and refuse to derive downstream work from
+the ambiguity.
+
+When you escalate, pitch the question at the operator's declared
+register. On your first exchange after `rcf init`, if
+`rcf/.identity/profile.md` carries no `operatorRegister` value, ask one
+question and record the answer to the profile: "One quick set-up
+question. When we need to escalate a decision to you, do you want it
+framed as a product-owner question (plain English, outcome-shaped) or
+an engineer question (with the AC id, the seed's assertion, the
+project's convention)? Answer 'product owner', 'engineer', or 'skip'
+and I will hold the default." A `skip` answer writes `unstated`, which
+reads as `productOwner` on the first escalation; if the operator
+answers in method vocabulary, silently promote to `engineer` for the
+rest of the session and offer to persist the change to the profile.
+
+### RULE 16: Verify with positive evidence.
+
+Every "verified" claim (in the Test and Finalise stages, in the PR body's
+verification section, in any status update) names the runtime it was
+checked against AND cites the positive evidence of the property (a
+request id, a response body excerpt, a created-then-deleted resource id
+in an inventory diff, a real deploy record). "The check did not show the
+bad signature" is not evidence; "the request returned id 8f7a-... and
+the response body carried the created resource id 12345" is. Where the
+account credentials are not present, record the skip honestly (name the
+env var that was unset), never fabricate a pass on the strength of
+absence. This rule mirrors RULE 15's active-disposition posture: an
+absent check is a skip you name, an actual check is a claim you cite.
+
 ### Session start
 
 Run `rcf define validate`. A broken tree is fixed or reported before anything

package/guidance/managed/agent-instructions-block.hash

@@ -1 +1 @@
-129f4018f526ececaef7ae5bea19ecd72be03a957e2cf2ee3323e85f117f6cba
+d35bd2dfec14db5567c2bcfa2934ce58ac5d7c23fd24e47776501660e06063eb

package/guidance/managed/agent-instructions-block.md

@@ -239,6 +239,73 @@ miss, feed unreachable) say nothing to the operator; freshness is a
 convenience, not a gate. Never run the upgrade without the operator's
 explicit go.
 
+### RULE 15: On blueprint apply, dispose every AC.
+
+A blueprint's acceptance criteria come in two shapes: `fixed`
+(mechanism-invariant, true for every applying project) and `template`
+(shape given, values project-specific). When you apply a blueprint
+(`rcf define blueprint add ...`), walk every AC the blueprint
+contributed. A `fixed` AC stands as authored: do not weaken or drop
+one, and if one appears wrong for the project, that is a defect against
+the blueprint, escalated on the blueprint's repo, not edited locally. A
+`template` AC is a starting shape: actively dispose of it by accepting
+as written, adjusting with the project's values, or dropping with a
+stated reason recorded against the story. Silent inheritance of a
+`template` AC is a defect. After you have disposed of every `template`
+AC, re-sweep the applied AC set against the scenario-class prompt list
+(credential missing, non-2xx, rate limit, timeout, partial write,
+permission denied, malformed input, already exists, gone, concurrent
+access, quota exhausted, dependency not ready, first-vs-repeat run,
+idempotency, empty and maximal collections, boundary values) so the
+story still covers the mechanism's documented failure paths. Any AC
+that rests on a third-party platform fact must show its vendor
+documentation URL and the ISO-8601 date the fact was verified; a
+citation older than the operator's tolerance is re-verified before the
+AC is treated as ground truth.
+
+A blueprint's seed docs are a minimal representational seed set, not a
+project spec. You have full scope of the project you are driving, and
+you are the party best placed to integrate the seed with the project's
+own chain. After you have disposed of every AC, walk the seed's REQs,
+TACs and ADRs against the project chain (existing REQs, TACs, ADRs and
+the PRD/TAD): resolve integration contradictions you can (parameter
+substitution against a settled project value, naming reconciliation
+against a settled project convention, composition-order reconciliation
+against another applied blueprint), record the disposition in the
+tree, and escalate to the operator only the ones that need a
+product-shape decision or a two-way credential or account decision. An
+internal contradiction (two of the seed's own layers disagreeing about
+the same contract) is not yours to resolve; escalate it as a defect
+against the blueprint's repo and refuse to derive downstream work from
+the ambiguity.
+
+When you escalate, pitch the question at the operator's declared
+register. On your first exchange after `rcf init`, if
+`rcf/.identity/profile.md` carries no `operatorRegister` value, ask one
+question and record the answer to the profile: "One quick set-up
+question. When we need to escalate a decision to you, do you want it
+framed as a product-owner question (plain English, outcome-shaped) or
+an engineer question (with the AC id, the seed's assertion, the
+project's convention)? Answer 'product owner', 'engineer', or 'skip'
+and I will hold the default." A `skip` answer writes `unstated`, which
+reads as `productOwner` on the first escalation; if the operator
+answers in method vocabulary, silently promote to `engineer` for the
+rest of the session and offer to persist the change to the profile.
+
+### RULE 16: Verify with positive evidence.
+
+Every "verified" claim (in the Test and Finalise stages, in the PR body's
+verification section, in any status update) names the runtime it was
+checked against AND cites the positive evidence of the property (a
+request id, a response body excerpt, a created-then-deleted resource id
+in an inventory diff, a real deploy record). "The check did not show the
+bad signature" is not evidence; "the request returned id 8f7a-... and
+the response body carried the created resource id 12345" is. Where the
+account credentials are not present, record the skip honestly (name the
+env var that was unset), never fabricate a pass on the strength of
+absence. This rule mirrors RULE 15's active-disposition posture: an
+absent check is a skip you name, an actual check is a claim you cite.
+
 ### Session start
 
 Run `rcf define validate`. A broken tree is fixed or reported before anything

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "rcf-lite",
-  "version": "0.24.0",
+  "version": "0.26.0",
   "type": "module",
   "description": "One-install tooling for the Requirements Confidence Framework (RCF): the unified `rcf` CLI grouped into the five RCF tool groups (discover, define, build, verify, audit) plus a small core set (init, doctor, guidance, mcp), an MCP server, the live tree viewer and the fresh-context adversarial ship-gate verifier. Consumes @stravica-ai/rcf-schemas.",
   "license": "Apache-2.0",
@@ -60,7 +60,7 @@
     "#admissibility": "./src/admissibility/index.js"
   },
   "dependencies": {
-    "@stravica-ai/rcf-schemas": "0.6.1",
+    "@stravica-ai/rcf-schemas": "0.6.2",
     "ajv": "^8.20.0",
     "ajv-formats": "^3.0.1"
   },

package/rcf/adrs/adr-3801-deploy-hetzner-server-cloud-host-contract.json

@@ -0,0 +1,13 @@
+{
+  "createdAt": "2026-09-07T23:54:35.274Z",
+  "updatedAt": "2026-09-07T23:55:16.994Z",
+  "adrId": "ADR-3801-deploy-hetzner-server-cloud-host-contract",
+  "prdId": "PRD-001",
+  "tadId": "TAD-001",
+  "version": "0.1.0",
+  "status": "proposed",
+  "title": "Cloud host contract: Hetzner Cloud VM as the shipped cloudHost shape (scope global, new topic linuxCloudHostContract)",
+  "context": "T-1 repo-chain ADR mirror for the shipped blueprints/deploy-hetzner-server/contributions/adrs/adr-3801-deploy-hetzner-server-cloud-host-contract.json contribution. An applying project needs a first-class Linux VM contract that container-orchestration and edge-ingress consumers can compose on. The Hetzner Cloud API server resource plus cloud-init user-data provides the shipped v1.0.0 shape per https://docs.hetzner.cloud/. Every applied cloud-host needs one project-wide answer to the linuxCloudHostContract topic; a future non-Hetzner sibling (Vultr, DigitalOcean, Fly.io) would conflict on the same topic.",
+  "decision": "The shipped v1.0.0 default is a Hetzner Cloud server as the linuxCloudHostContract provider. The provisioner reads its shape from the applying manifest and creates a matching live server via the hcloud verbs (or the raw Hetzner Cloud API when provisioningTool=raw-api). The linuxCloudHostContract topic scope is global on this blueprint. recommendedDefault: true. Standards trace clause: Hetzner Cloud API server resource and cloud-init user-data contract per hetzner-round-7-spec-2026-09-07.md.",
+  "consequences": "Consumer blueprints that run on a Linux host (containers, systemd services, tunnel connectors) compose on capabilities: [cloudHost]. Rebuild-from-manifest is always possible: the manifest is the source of truth, the live server is derivative. Drift from the shipped manifest to the live server is out of scope for v1.0.0; a later minor may add a drift-audit runner."
+}

package/rcf/adrs/adr-3802-deploy-hetzner-server-snapshot-cadence.json

@@ -0,0 +1,13 @@
+{
+  "createdAt": "2026-09-07T23:54:35.461Z",
+  "updatedAt": "2026-09-07T23:55:17.558Z",
+  "adrId": "ADR-3802-deploy-hetzner-server-snapshot-cadence",
+  "prdId": "PRD-001",
+  "tadId": "TAD-001",
+  "version": "0.1.0",
+  "status": "proposed",
+  "title": "Snapshot cadence: weekly default, daily and off alternatives, Hetzner-managed backups elicited (scope global, new topic snapshotAndBackupCadence)",
+  "context": "T-1 repo-chain ADR mirror for the shipped blueprints/deploy-hetzner-server/contributions/adrs/adr-3802-deploy-hetzner-server-snapshot-cadence.json contribution. An applying project needs a discipline for how often the Hetzner Cloud server takes a snapshot and whether Hetzner-managed backups are enabled. Hetzner documents snapshots as manual-fire on-demand and Hetzner-managed backups as a paid subscription at 20 percent of monthly server price per https://docs.hetzner.com/cloud/servers/backups-snapshots/overview. Every cloud host needs one project-wide answer to the snapshotAndBackupCadence topic.",
+  "decision": "The shipped v1.0.0 default is weekly snapshot cadence with the snapshot fired by a scheduled runner in the applying project. Alternatives elicited: daily (higher recovery-point-objective, higher storage) and off (no automatic snapshot). Hetzner-managed backups are an elicited paid opt-in that costs 20 percent of monthly server price per the vendor docs; when opted-in, the scheduled snapshot runner still fires so the two mechanisms compose. The snapshotAndBackupCadence topic scope is global on this blueprint. recommendedDefault: true. Standards trace clause: Hetzner Cloud backups-and-snapshots documented pricing and mechanism per hetzner-round-7-spec-2026-09-07.md.",
+  "consequences": "Weekly snapshot on a cx23 costs approximately EUR 0.005 per month in extra storage; daily is approximately EUR 0.035; Hetzner-managed backups add approximately EUR 0.80 per month per server at cx23. The scheduled snapshot runner emits hetznerSnapshotTaken with snapshot id and wall-clock time so the observability sink surfaces the cadence."
+}

package/rcf/adrs/adr-3803-deploy-hetzner-server-provisioning-tool.json

@@ -0,0 +1,13 @@
+{
+  "createdAt": "2026-09-07T23:54:35.647Z",
+  "updatedAt": "2026-09-07T23:55:18.120Z",
+  "adrId": "ADR-3803-deploy-hetzner-server-provisioning-tool",
+  "prdId": "PRD-001",
+  "tadId": "TAD-001",
+  "version": "0.1.0",
+  "status": "proposed",
+  "title": "Provisioning tool: hcloud CLI default, raw Hetzner Cloud API alternative, Terraform rejected",
+  "context": "T-1 repo-chain ADR mirror for the shipped blueprints/deploy-hetzner-server/contributions/adrs/adr-3803-deploy-hetzner-server-provisioning-tool.json contribution. An applying project needs a documented answer to how the provisioner shells out to Hetzner Cloud. Options considered: hcloud CLI (small, self-documenting, JSON output), raw Hetzner Cloud REST API (no CLI dependency, useful when the target host cannot install a binary), Terraform (declarative, adds a second toolchain and a state file). Baz ruling 2026-09-07 09:50Z on decision 18: hcloud not Terraform.",
+  "decision": "The shipped v1.0.0 default is the hcloud CLI as the provisioning tool. Alternative elicited: raw-api (the provisioner fetches the Hetzner Cloud REST API directly). Terraform is a rejected alternative: adds a second toolchain and a state file, neither of which matches the shelf shape (see section 9 of hetzner-round-7-spec-2026-09-07.md). elicited: true. recommendedDefault: hcloud. Standards trace clause: Hetzner Cloud CLI documented resource verbs per hetzner-round-7-spec-2026-09-07.md.",
+  "consequences": "The applying project installs the hcloud binary on the operator laptop and any CI runner that provisions. The raw-api fork is behind the same provisioner facade so no consumer code diverges. The provisioner-facade sole-reader guarantee holds on both paths."
+}

package/rcf/adrs/adr-3804-deploy-hetzner-server-hardening-baseline.json

@@ -0,0 +1,13 @@
+{
+  "createdAt": "2026-09-07T23:54:35.833Z",
+  "updatedAt": "2026-09-07T23:55:18.681Z",
+  "adrId": "ADR-3804-deploy-hetzner-server-hardening-baseline",
+  "prdId": "PRD-001",
+  "tadId": "TAD-001",
+  "version": "0.1.0",
+  "status": "proposed",
+  "title": "Hardening baseline: SSH key-only, root disabled, UFW default-deny, DOCKER-USER chain, fail2ban, unattended-upgrades",
+  "context": "T-1 repo-chain ADR mirror for the shipped blueprints/deploy-hetzner-server/contributions/adrs/adr-3804-deploy-hetzner-server-hardening-baseline.json contribution. Every Hetzner server exposed to the public internet needs a minimum hardening set. Cloud-init landing the set at first boot is the operator-friendly shape (declarative, reproducible, in git). The Debian unattended-upgrades wiki documents the auto-update mechanism; the estate baseline at operator/knowledge/systems/environments/hetzner-cloud/overview.md Security posture baseline names the exact block set.",
+  "decision": "The shipped v1.0.0 hardening baseline is the six blocks: SSH key-only (PasswordAuthentication no), root disabled (PermitRootLogin no), UFW default-deny incoming with 22 and 80 and 443 permitted per the manifest firewall shape, DOCKER-USER iptables chain wired to drop non-conforming egress, fail2ban SSH jail, unattended-upgrades on for security updates. The render-lint probe asserts every block appears in the rendered cloud-init YAML; a mutation removes a block and the probe FAILS naming the missing line. recommendedDefault: true. Standards trace clause: Debian unattended-upgrades wiki AND the estate baseline at operator/knowledge/systems/environments/hetzner-cloud/overview.md Security posture baseline per hetzner-round-7-spec-2026-09-07.md.",
+  "consequences": "The applying project inherits the six-block baseline on every provisioned server. Deviation costs a fresh ADR at the applying project level. The baseline is text plus a rendered template; extension (extra ssh key, extra fail2ban jail) sits on top without rewriting."
+}

package/rcf/adrs/adr-3901-platform-docker-compose-host-contract.json

@@ -0,0 +1,13 @@
+{
+  "createdAt": "2026-09-08T01:42:21.686Z",
+  "updatedAt": "2026-09-08T01:44:12.275Z",
+  "adrId": "ADR-3901-platform-docker-compose-host-contract",
+  "prdId": "PRD-001",
+  "tadId": "TAD-001",
+  "version": "0.1.0",
+  "status": "accepted",
+  "title": "T-2 container host contract: docker compose as source of truth (scope global, new topic containerHostContract)",
+  "context": "An applying project running its stack on a Linux cloudHost needs one shipped contract for how services are declared, wired and brought up on a container-orchestration surface. Round-7 T-2 mints the containerHostContract topic on this ADR. Docker Compose is the shipped v1.0.0 surface (compose.yaml as source of truth, healthchecks required, secrets as files, restart discipline, reverse-proxy as artefact). Every applied container host needs one project-wide answer to the containerHostContract topic; a future non-compose sibling (Docker Swarm, Nomad) would contribute the same topic string with a different mechanism, forcing a DELIBERATE conflict the operator resolves per the round-2 conflict pattern. Standards trace clause: Docker Compose file reference AND Docker Engine install-on-Ubuntu docs per hetzner-round-7-spec-2026-09-07.md.",
+  "decision": "The shipped v1.0.0 default is docker compose on a cloudHost as the containerHostContract provider. A canonical compose.yaml at the repo root drives docker compose up on the applied cloudHost (T-1 deploy-hetzner-server); healthchecks refuse at docker compose config on missing; secrets are file mounts; restart policies are unless-stopped or on-failure; the reverse-proxy config is a first-class versioned artefact per TAC-3904. The containerHostContract topic scope is global on this blueprint; the topic string is containerHostContract (lower camelCase, one concept per topic, no version suffix, per the round-2 rules-for-new-topics clause on the shelf registry). Standards trace clause: Docker Compose file reference AND Docker Engine install-on-Ubuntu docs per hetzner-round-7-spec-2026-09-07.md.",
+  "consequences": "Consumer blueprints that ship as containers declare capabilities: [containerHost] on their applied contract; the round-7 T-3 edge-cloudflare-tunnel reads this capability at apply-time to choose the compose-service runtime. Rebuild-from-manifest is always possible: the compose file is the source of truth, the running stack is derivative. Compose is famously many right ways; over-specifying alienates a project with a defensible different shape, so v1.0.0 pins the small load-bearing set (healthchecks, secrets-as-files, restart discipline, reverse-proxy-as-artefact) and leaves everything else to project-owned ADRs."
+}

package/rcf/adrs/adr-3902-platform-docker-compose-host-reverse-proxy.json

@@ -0,0 +1,13 @@
+{
+  "createdAt": "2026-09-08T01:42:21.872Z",
+  "updatedAt": "2026-09-08T01:44:12.461Z",
+  "adrId": "ADR-3902-platform-docker-compose-host-reverse-proxy",
+  "prdId": "PRD-001",
+  "tadId": "TAD-001",
+  "version": "0.1.0",
+  "status": "accepted",
+  "title": "T-2 reverse proxy choice: caddy default per Baz decision 19; traefik alternative for docker-label auto-discovery; none for tunnel-fronted projects (elicited)",
+  "context": "Compose stacks need a reverse-proxy for HTTPS termination and hostname-to-service routing. Caddy is the estate baseline (dev-01 and ops-01 already run it per Baz decision 19 on 2026-09-07 09:50Z). Traefik has a docker-label auto-discovery model some projects prefer. Some projects front their stack only with the round-7 tunnel and skip a reverse proxy inside compose.",
+  "decision": "The reverse-proxy choice is elicited via the reverseProxy parameter. The shipped default is caddy per Baz decision 19. The alternatives are traefik (for projects that want docker-label auto-discovery) and none (for projects fronted only by the round-7 tunnel). Standards trace clause: Caddy docs AND Traefik docs per hetzner-round-7-spec-2026-09-07.md.",
+  "consequences": "A project applying reverseProxy=caddy gets the caddy/Caddyfile artefact and the caddy reload verb. A project applying reverseProxy=traefik gets the traefik/traefik.yaml artefact and the Traefik equivalent reload verb; docker-label auto-discovery is a project-side pattern the guide names. A project applying reverseProxy=none omits the reverse-proxy service and must apply edge-cloudflare-tunnel (T-3) so ingress terminates at the CF edge."
+}

package/rcf/adrs/adr-3903-platform-docker-compose-host-reject-coolify.json

@@ -0,0 +1,13 @@
+{
+  "createdAt": "2026-09-08T01:42:22.057Z",
+  "updatedAt": "2026-09-08T01:44:12.646Z",
+  "adrId": "ADR-3903-platform-docker-compose-host-reject-coolify",
+  "prdId": "PRD-001",
+  "tadId": "TAD-001",
+  "version": "0.1.0",
+  "status": "accepted",
+  "title": "T-2 Coolify rejected per Baz decision 20 (it shadows what the blueprints contract and adds its own DB and UI as a second source of state)",
+  "context": "Coolify was proposed as a candidate platform-* sibling in the round-7 proposal. It is a self-hosted PaaS with its own database and UI. Baz decision 20 on 2026-09-07 09:50Z ruled Coolify out for round 7.",
+  "decision": "reject; it shadows what the blueprints contract and adds its own DB and UI as a second source of state.",
+  "consequences": "No platform-coolify-host blueprint is scoped in round 7 and no reserved slot is allocated. A future platform-coolify-host sibling mints on operator demand under a fresh scope PR. The standards trace clause on this contribution entry is generic enterprise practice; no vendor-doc URL is claimed for the reject decision."
+}

package/rcf/adrs/adr-3904-platform-docker-compose-host-log-driver.json

@@ -0,0 +1,13 @@
+{
+  "createdAt": "2026-09-08T01:42:22.244Z",
+  "updatedAt": "2026-09-08T01:44:12.833Z",
+  "adrId": "ADR-3904-platform-docker-compose-host-log-driver",
+  "prdId": "PRD-001",
+  "tadId": "TAD-001",
+  "version": "0.1.0",
+  "status": "accepted",
+  "title": "T-2 log driver choice: journald default matching Debian 12 and Ubuntu 24.04 baseline; loki opt-in when the project runs Grafana (elicited)",
+  "context": "Containers write stdout and stderr to a log driver. Debian 12 and Ubuntu 24.04 (the T-1 cloud-init baseline) ship journald. Grafana users on the estate reach for loki as a native sink. A one-choice hard-code loses either journald parity with the OS or loki when the operator runs Grafana.",
+  "decision": "The log driver is elicited via the log-driver parameter. The shipped default is journald matching the Debian 12 and Ubuntu 24.04 baselines T-1 sets up. The alternative is loki, opted into when the applying project runs Grafana. When observability-logging is applied, the compose file wires the elicited driver to that companion. Standards trace clause: generic enterprise practice.",
+  "consequences": "A project applying log-driver=journald gets the systemd-native path; the journald sink is queried via journalctl. A project applying log-driver=loki targets the Grafana loki endpoint; the observability-logging companion supplies the endpoint address. Neither choice adds a runtime npm dependency. The compose-config-lint refuses on any driver value outside the allowed set."
+}

package/rcf/adrs/adr-4001-edge-cloudflare-tunnel-ingress-bridge-contract.json

@@ -0,0 +1,13 @@
+{
+  "createdAt": "2026-09-08T03:23:09.408Z",
+  "updatedAt": "2026-09-08T03:23:09.408Z",
+  "adrId": "ADR-4001-edge-cloudflare-tunnel-ingress-bridge-contract",
+  "prdId": "PRD-001",
+  "tadId": "TAD-001",
+  "version": "0.1.0",
+  "status": "proposed",
+  "title": "T-3 edge ingress bridge contract: Cloudflare Tunnel as the shipped ingress-bridge shape from a cloudHost service to the CF edge (scope global, new topic edgeIngressBridge)",
+  "context": "An applying project running on a Linux cloudHost needs one shipped answer to the question of how a service on that host reaches the public internet without opening origin ports. Round-7 T-3 mints the edgeIngressBridge topic on this ADR. Cloudflare Tunnel is the shipped v1.0.0 mechanism (cloudflared connector out to the CF edge; DNS route on a Cloudflare zone; ingress rules mapping public hostname to internal service URL). Every applied ingress bridge needs one project-wide answer to the edgeIngressBridge topic; a future non-Cloudflare sibling (Tailscale Funnel, Fly.io proxy) would contribute the same topic string with a different mechanism, forcing a DELIBERATE conflict the operator resolves per the round-2 conflict pattern. Standards trace clause: Cloudflare Tunnel overview and get-started documented mechanics per hetzner-round-7-spec-2026-09-07.md.",
+  "decision": "The shipped v1.0.0 default is a Cloudflare Tunnel connector as the edgeIngressBridge provider. A cloudflared connector on the applying host (compose service by default when containerHost is applied per ADR-4002; systemd unit on a bare cloudHost) reads a tunnel manifest at cloudflare/tunnels/<name>.yaml and terminates ingress at the CF edge. The edgeIngressBridge topic scope is global on this blueprint; the topic string is edgeIngressBridge (lower camelCase, one concept per topic, no version suffix, per the round-2 rules-for-new-topics clause on the shelf registry). Standards trace clause: Cloudflare Tunnel overview and get-started documented mechanics per hetzner-round-7-spec-2026-09-07.md.",
+  "consequences": "Consumer blueprints that expose a service publicly declare capabilities: [tunnelBridge] on their applied contract to know a bridge is in place. Composition with zeroTrustGate (edge-cloudflare-access) toggles the Access-gated ingress shape per ADR-4003. A T-3-only project (no reverse proxy) declares no 80/443 firewall rule; the tunnel is the sole path from the edge to the origin. Rebuild-from-manifest is always possible: the manifest is the source of truth, the running connector is derivative. Folding this shape into edge-cloudflare-access was rejected: Access is an authorisation gate, Tunnel is an ingress bridge; the responsibilities are distinct and one applies without the other."
+}

package/rcf/adrs/adr-4002-edge-cloudflare-tunnel-connector-runtime.json

@@ -0,0 +1,13 @@
+{
+  "createdAt": "2026-09-08T03:23:09.604Z",
+  "updatedAt": "2026-09-08T03:23:09.604Z",
+  "adrId": "ADR-4002-edge-cloudflare-tunnel-connector-runtime",
+  "prdId": "PRD-001",
+  "tadId": "TAD-001",
+  "version": "0.1.0",
+  "status": "proposed",
+  "title": "T-3 connector runtime: compose-service default when containerHost applied; systemd-unit alternative on bare cloudHost",
+  "context": "The cloudflared connector runs in one of two supported vendor shapes: as a container image published on the cloudflared downloads page, or as a systemd unit installed via the vendor package per the cloudflared as-a-service local-configuration-file docs. An applying project running its stack under docker compose has a natural home for the connector alongside its other services (same network, same logging driver, same restart policy). An applying project running bare on the host has no compose stack and needs a systemd unit for boot ordering and journald logging. Standards trace clause: Cloudflare cloudflared as-a-service documented systemd unit per hetzner-round-7-spec-2026-09-07.md.",
+  "decision": "The connector runtime is elicited via ADR-4002 with enum {compose-service, systemd-unit} and recommendedDefault compose-service. When the containerHost capability is applied (T-2 platform-docker-compose-host) the shipped default is compose-service; when the host runs bare (only T-1 applied) the operator picks systemd-unit at apply time. Standards trace clause: Cloudflare cloudflared as-a-service documented systemd unit per hetzner-round-7-spec-2026-09-07.md.",
+  "consequences": "The fixture ships both variants and both pass the local probes (manifest-schema-validate, cloudflared-config-lint, aud-presence-check). A future non-Cloudflare tunnel sibling (Tailscale Funnel, Fly.io proxy) reuses the runtime enum shape but the elicit lives on that siblings own ADR (conflict-by-design on edgeIngressBridge per ADR-4001). The systemd variant carries an install caveat in the guide: the vendor package landed via apt/curl per the as-a-service docs, which is out of scope for the blueprint itself."
+}

package/rcf/adrs/adr-4003-edge-cloudflare-tunnel-hostname-mode.json

@@ -0,0 +1,13 @@
+{
+  "createdAt": "2026-09-08T03:23:09.794Z",
+  "updatedAt": "2026-09-08T03:23:09.794Z",
+  "adrId": "ADR-4003-edge-cloudflare-tunnel-hostname-mode",
+  "prdId": "PRD-001",
+  "tadId": "TAD-001",
+  "version": "0.1.0",
+  "status": "proposed",
+  "title": "T-3 hostname mode: access-gated when zeroTrustGate applied (ingress attaches AUD); public-hostname when absent (block omitted)",
+  "context": "A tunnel can serve a public hostname openly (any request reaches the origin, protected only by whatever authentication the origin itself carries) or Access-gated (cloudflared refuses at the edge any request without a valid Access JWT for a named AUD, per the vendor self-hosted-public-app docs). The hostname mode is not elicited: it is DISCOVERED from the applied capability set. When zeroTrustGate is applied (edge-cloudflare-access v1.0.0), the tunnel binds the Access AUD; when it is not, the tunnel serves in public-hostname mode. Standards trace clause: Cloudflare Access self-hosted-public-app documented shape per hetzner-round-7-spec-2026-09-07.md.",
+  "decision": "ADR-4003 records the hostname mode as elicited: false and discovered from applied capabilities via the sidecar rcf/blueprints/edge-cloudflare-tunnel.applied.json. When appliedCapabilities includes zeroTrustGate, every ingress rule under the tunnel manifest attaches an originRequest.access block naming the AUD; when it does not, the block is omitted. The aud-presence-check probe runs on both fixture variants and asserts the shape flips correctly. Standards trace clause: Cloudflare Access self-hosted-public-app documented shape per hetzner-round-7-spec-2026-09-07.md.",
+  "consequences": "A project that applies zeroTrustGate later inherits the Access-gated shape on the next reapply of edge-cloudflare-tunnel without a manual manifest edit; a project that removes zeroTrustGate drops to public-hostname mode explicitly. A silent drift (the sidecar keeps zeroTrustGate but the ingress loses the AUD block) is caught by aud-presence-check refusing before the shape ships. Fixture variants live under cloudflared/*/access-gated and cloudflared/*/public-hostname; the SIMULATE_AUD_DROP mutation on the gated fixture proves the refuse path."
+}

package/rcf/code-nodes/cn-410.json

@@ -0,0 +1,20 @@
+{
+  "cnId": "CN-410",
+  "path": "../../blueprints/deploy-hetzner-server/blueprint.json",
+  "implementsAcIds": [
+    "AC-11001-1",
+    "AC-11101-1",
+    "AC-11102-1",
+    "AC-11201-1",
+    "AC-11202-1",
+    "AC-11301-1",
+    "AC-11401-1",
+    "AC-11402-1",
+    "AC-11501-1"
+  ],
+  "dependencies": [],
+  "version": "0.1.0",
+  "status": "draft",
+  "createdAt": "2026-09-07T23:59:16.031Z",
+  "updatedAt": "2026-09-07T23:59:16.220Z"
+}

package/rcf/code-nodes/cn-440.json

@@ -0,0 +1,20 @@
+{
+  "cnId": "CN-440",
+  "path": "../../blueprints/platform-docker-compose-host/blueprint.json",
+  "implementsAcIds": [
+    "AC-12001-1",
+    "AC-12101-1",
+    "AC-12102-1",
+    "AC-12201-1",
+    "AC-12202-1",
+    "AC-12301-1",
+    "AC-12401-1",
+    "AC-12402-1",
+    "AC-12501-1"
+  ],
+  "dependencies": [],
+  "version": "0.1.0",
+  "status": "draft",
+  "createdAt": "2026-09-08T01:45:43.708Z",
+  "updatedAt": "2026-09-08T01:45:43.708Z"
+}

package/rcf/code-nodes/cn-470.json

@@ -0,0 +1,19 @@
+{
+  "cnId": "CN-470",
+  "path": "../../blueprints/edge-cloudflare-tunnel/blueprint.json",
+  "implementsAcIds": [
+    "AC-13001-1",
+    "AC-13002-1",
+    "AC-13101-1",
+    "AC-13102-1",
+    "AC-13201-1",
+    "AC-13301-1",
+    "AC-13302-1",
+    "AC-13401-1"
+  ],
+  "dependencies": [],
+  "version": "0.1.0",
+  "status": "draft",
+  "createdAt": "2026-09-08T03:25:10.642Z",
+  "updatedAt": "2026-09-08T03:25:10.642Z"
+}

package/rcf/code-nodes/cn-500.json

@@ -0,0 +1,12 @@
+{
+  "cnId": "CN-500",
+  "path": "../../blueprints/object-storage-s3/blueprint.json",
+  "implementsAcIds": [
+    "AC-14001-1"
+  ],
+  "dependencies": [],
+  "version": "0.1.0",
+  "status": "draft",
+  "createdAt": "2026-09-08T09:04:04.994Z",
+  "updatedAt": "2026-09-08T09:04:04.994Z"
+}

package/rcf/code-nodes/cn-510.json

@@ -0,0 +1,12 @@
+{
+  "cnId": "CN-510",
+  "path": "../../blueprints/deploy-hetzner-server/blueprint.json",
+  "implementsAcIds": [
+    "AC-14501-1"
+  ],
+  "dependencies": [],
+  "version": "0.1.0",
+  "status": "draft",
+  "createdAt": "2026-09-08T10:52:56.753Z",
+  "updatedAt": "2026-09-08T10:52:56.753Z"
+}

package/rcf/code-nodes/cn-520.json

@@ -0,0 +1,14 @@
+{
+  "cnId": "CN-520",
+  "path": "../../blueprints/platform-cloudflare-kv/blueprint.json",
+  "implementsAcIds": [
+    "AC-15001-1",
+    "AC-15001-2",
+    "AC-15401-2"
+  ],
+  "dependencies": [],
+  "version": "0.1.0",
+  "status": "draft",
+  "createdAt": "2026-09-08T12:22:33.507Z",
+  "updatedAt": "2026-09-08T12:23:01.646Z"
+}

package/rcf/code-nodes/cn-521.json

@@ -0,0 +1,12 @@
+{
+  "cnId": "CN-521",
+  "path": "../../packages/rcf-lite/test/fixtures/cf-platform/h2-cf-kv-cache-aside-shim.mjs",
+  "implementsAcIds": [
+    "AC-15401-1"
+  ],
+  "dependencies": [],
+  "version": "0.1.0",
+  "status": "draft",
+  "createdAt": "2026-09-08T12:22:47.292Z",
+  "updatedAt": "2026-09-08T12:23:44.676Z"
+}