home-v1-skills-code-agent/corp-v1-channel-delivery
6
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

policy: place runtime resources on shared platforms #2

Merged
jarvis-at-skic merged 1 commits from policy/runtime-resources-on-platform into test 2026-09-05 07:22:16 -07:00
Conversation 0 Commits 1 Files Changed 1
+11 -1
1 changed files with 11 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files
SKILL.md
+11 -1
View File
@@ -1,7 +1,7 @@
---
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."
version: 1.5.2
version: 1.6.0
author: Hermes Agent
license: MIT
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.
### 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
When a build or CI failure is observed: