backend-runtime-governance

name	backend-runtime-governance
description	Use when changing backend route placement, service boundaries, runtime ownership, or backend docs/tests alignment.

Hussh Backend Runtime Governance Skill

Purpose and Trigger

• Primary scope: backend-runtime-governance
• Trigger on backend route placement, service boundaries, runtime ownership, and backend runtime docs/tests alignment.
• Avoid overlap with backend-api-contracts and backend-agents-operons.

Coverage and Ownership

• Role: spoke
• Owner family: backend

Owned repo surfaces:

1. consent-protocol/api
2. consent-protocol/hushh_mcp/services
3. consent-protocol/hushh_mcp/integrations
4. consent-protocol/tests/services

Non-owned surfaces:

1. backend
2. security-audit
3. repo-operations

Do Use

1. Route and service placement decisions inside the backend runtime.
2. Runtime ownership boundaries between routes, services, and integrations.
3. Aligning backend runtime docs and service-layer tests with implementation changes.
4. Reviewing runtime DB table ownership, data-class posture, retention policy, and access paths when backend migrations or services add durable state.

Do Not Use

1. Broad backend intake where the correct spoke is still unclear.
2. Agent/operon orchestration work.
3. Proxy contract work that primarily belongs to API contracts.

Read First

1. docs/reference/architecture/architecture.md
2. docs/reference/architecture/api-contracts.md
3. consent-protocol/docs/README.md
4. .codex/skills/backend-runtime-governance/references/async-runtime-performance.md
5. docs/reference/architecture/schema-migration-discipline.md

Workflow

1. Confirm the runtime boundary before moving code between routes, services, or integrations.
2. Keep backend tests and backend docs aligned with runtime changes.
3. For any migration or durable service table, confirm the runtime DB data-plane contract declares owner, data class, primary access path, expected row growth, retention policy, deletion behavior, and plaintext/ciphertext posture.
4. Treat consent validation, trust, and audit rules as security-audit concerns when they become the primary boundary.
5. Treat uv as the canonical Python toolchain for contributor and CI flows; requirements*.txt are generated runtime artifacts, not the source of dependency truth.
6. For backend bootstrap, packaging, or runtime-governance changes, rerun the authoritative service checks once directly and once again through the canonical repo entrypoint.
7. When a backend runtime failure is visible in UAT or CI, use ./bin/hushh codex rca --surface runtime --text or --surface uat --text first so service fixes are anchored to the blocking runtime classification instead of log-chasing.
8. For slow or intermittently "unreachable" endpoints, run the async runtime performance health check before editing: confirm whether the asyncio event loop is blocked by a synchronous call (DB client, external SDK) rather than a slow DB, then apply the run_in_threadpool/asyncio.to_thread offload and the layered caching strategy in references/async-runtime-performance.md. Never call the synchronous db/db_client.py client or a blocking SDK directly from an async def handler.

Handoff Rules

1. If the request is still broad or ambiguous, route it back to backend.
2. If the task is primarily a proxy/backend wire contract, use backend-api-contracts.
3. If the task is primarily about agents or operons, use backend-agents-operons.
4. If the task becomes trust/IAM/vault policy work, route to security-audit.

Required Checks

cd consent-protocol && python3 -m pytest tests/services -q
./bin/hushh codex data-model-audit