policy: place runtime resources on shared platforms

This commit is contained in:
2026-09-05 14:22:15 +00:00
parent 9edfbba511
commit 611809d5d7
+11 -1
View File
@@ -1,7 +1,7 @@
--- ---
name: corp-v1-channel-delivery name: corp-v1-channel-delivery
description: "Use when operating or synchronizing a Corp v1 project's delivery channel. Drives coding, unit testing, build and continuous-integration health, attempts safe evidence-based fixes, escalates requirement or architecture contradictions, and maintains Ways of Working and Engineering documentation." description: "Use when operating or synchronizing a Corp v1 project's delivery channel. Drives coding, unit testing, build and continuous-integration health, attempts safe evidence-based fixes, escalates requirement or architecture contradictions, and maintains Ways of Working and Engineering documentation."
version: 1.5.2 version: 1.6.0
author: Hermes Agent author: Hermes Agent
license: MIT license: MIT
metadata: metadata:
@@ -114,6 +114,16 @@ Monitor local builds and Gitea Actions for:
A green local build is not proof that CI or delivery succeeded. Verify the actual remote branch and matching CI task/run. A green local build is not proof that CI or delivery succeeded. Verify the actual remote branch and matching CI task/run.
### Runtime-resource placement
CI jobs and developer workstations must not provision databases, queues, object stores, caches, brokers, or other application runtime services. When implementation or validation needs such a resource, provision it under the owning application on the approved shared runtime platform through that project's GitOps repository, then consume it through a governed application or test interface.
- Keep every non-production environment—including development, integration, test, staging, and preview—and all of its resources isolated from production and from other non-production environments. Destructive or concurrent validation requires a per-run database/schema/role or explicit serialization; it must not reset shared data.
- CI may orchestrate exact-head validation, but it must not start application runtime-resource service containers or receive application-resource credentials. Harmless process-local test doubles and build tools are not runtime resources. Prefer a narrowly governed in-platform Job/Workflow trigger so a private resource does not need public, NodePort, or runner-network exposure.
- Persistent storage must follow the platform's storage operations skill. Never accept a dynamically provisioned volume whose reclaim policy can delete durable data when the PVC is removed.
- Secrets come from the approved external secret store; never commit connection strings or credentials.
- Provision and verify required runtime resources before treating dependent application work as deployable. Missing infrastructure blocks deployment, not safe code-only work whose tests do not require that resource.
## Failure-Repair Workflow ## Failure-Repair Workflow
When a build or CI failure is observed: When a build or CI failure is observed: