coulomb/rapp-canned-prompts
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
rapp-canned-prompts/INTENT.md
tegwick 5a0f4cb5c8 Package canned-prompts for Railiance 
Registers the repo with State Hub (agents / practice, prefix RCP-WP) and fills
in the rapp shape.

declarations/rapp.yaml declares a manifest-managed platform service owned by
canned-prompts, bound to rail-kubernetes and reef-railiance, with rollout,
smoke and rollback contracts.

The image pin says `pending-publication` rather than carrying a placeholder
digest. The image builds and was verified locally (canned-prompts
CANP-WP-0006-T06) but has never been pushed, so no registry digest exists. A
placeholder shaped like a real digest would be worse than a sentinel: it could
be mistaken for something deployable.

manifests/ follows the rapp-sbom-nexus shape: namespace labelled for the
postgres client, external secrets from OpenBao, a migration Job, and the
runtime Deployment with a ClusterIP-only Service, dedicated ServiceAccount and
default-deny plus runtime NetworkPolicies.

Three choices worth stating. Credentials arrive as mounted files, never env
vars — an env var holding a password is visible in kubectl describe, in crash
dumps, and to anything that can read /proc. Migrations run as a Job rather than
at start-up, so a schema rollback stays separate from a code rollback and
replicas do not race. Liveness points at /healthz, which checks only that the
process is up: pointing it at a database-dependent path would restart every
replica during a database blip.

Egress is PostgreSQL and DNS only. A package arrives by publish; the registry
never reaches out, so it is given no path to.

tools/smoke.sh checks what only the cluster can answer and calls
canned-prompts' service/tools/smoke.py for health and migration head, rather
than holding a second opinion about whether the service is healthy.

RCP-WP-0002 carries the two operator actions that block a first rollout —
publishing the image and provisioning database roles — and records
per-publisher identity as a decision belonging upstream, which this repo must
not paper over with cluster configuration implying finer control than exists.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Bjefh8NUiEiahN4JLwoSKM

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 388925@bnt-lap001
Assistant-Session: 3507023f-e0fd-4a1e-9d90-a0d4217d1502
2026-09-06 21:44:17 +02:00

1.4 KiB
Raw Permalink Blame History

Intent — rapp-canned-prompts

Package and operate the canned-prompts hosted registry and index on Railiance, without moving product ownership into an operations repository.

This package makes deployment reproducible: an immutable image pin, a private ClusterIP Service, credentials mounted as files from the platform broker, a one-shot schema migration under a separate owner role, least-privilege NetworkPolicies, live verification, and digest rollback.

Format semantics, package validation, API compatibility, the schema and its migrations, and image publication remain owned by canned-prompts. PostgreSQL topology, database isolation, backups and credential issuance remain owned by rapp-postgres and the platform credential broker.

What this repo decides

  • how the workload is composed, pinned, rolled out and rolled back;
  • what "healthy" means at the cluster level, and how it is verified;
  • the network posture: what may reach the service, and what it may reach.

What it does not decide

  • what a valid prompt package is, or what any endpoint means — canned-prompts;
  • database topology, backup or credential rotation — rapp-postgres and the broker;
  • who may publish. The service's identity model is a single shared token proving "the operator". Per-publisher identity is an open question in canned-prompts, and this repo must not paper over it with cluster configuration that implies finer control than exists.