From 54d0eb2d4c25230a097ca8b5217dd26807216b32 Mon Sep 17 00:00:00 2001 From: BoldBlackBot <296328274+BoldBlackBot@users.noreply.github.com> Date: Sun, 30 Aug 2026 13:05:12 -0400 Subject: [PATCH] chore: drop cross-product pattern references from shipped content Removes the five 'piranesi pattern' mentions from shipped skill and template comments. Shipped dispatch content does not reference the sibling enterprise product by name; each sentence now stands on its own describing the secrets-in-SSM convention directly. Golden test passes (17/17). Co-Authored-By: Julio Capote <6135+capotej@users.noreply.github.com> --- template/.agents/skills/setup-dispatch/SKILL.md | 8 ++++---- template/.agents/skills/setup-dispatch/template.yaml | 6 +++--- template/AGENTS.md | 2 +- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/template/.agents/skills/setup-dispatch/SKILL.md b/template/.agents/skills/setup-dispatch/SKILL.md index b7f3c1c..abd8cd4 100644 --- a/template/.agents/skills/setup-dispatch/SKILL.md +++ b/template/.agents/skills/setup-dispatch/SKILL.md @@ -36,8 +36,8 @@ service whose `DesiredCount` is a parameter (default `1`); the setup skill passes `0` on the first deploy — before the SSM secrets exist and the aws_ssm plugin is installed and configured (Phase 5) — then scales to 1. Secrets are **not** owned by the stack — they live in SSM Parameter Store as namespaced -SecureStrings that the user writes in Phase 3. This is the piranesi pattern: it -keeps secrets out of template diffs and lets them survive stack deletes. +SecureStrings that the user writes in Phase 3. This keeps +secrets out of template diffs and lets them survive stack deletes. ## Prerequisites @@ -815,8 +815,8 @@ Report to the user: layout works directly via host bind-mounts on the EBS volume — no custom `Dockerfile` or `entrypoint.sh` is needed. Do not build a derived image. -- **Secrets live in SSM, not Secrets Manager.** Following the piranesi pattern, - secrets are namespaced SecureString parameters (`/dispatch/KEY`) that the user +- **Secrets live in SSM, not Secrets Manager.** + Secrets are namespaced SecureString parameters (`/dispatch/KEY`) that the user writes. The `/dispatch/` namespace is hardcoded in the template so the deployer IAM policy can pin `parameter/dispatch/*`. They are not CloudFormation resources, so stack updates never clobber their values and diff --git a/template/.agents/skills/setup-dispatch/template.yaml b/template/.agents/skills/setup-dispatch/template.yaml index e047fb0..54bf4b9 100644 --- a/template/.agents/skills/setup-dispatch/template.yaml +++ b/template/.agents/skills/setup-dispatch/template.yaml @@ -263,14 +263,14 @@ Resources: TargetKeyId: !Ref SsmKmsKey # ── Secrets are NOT CloudFormation resources ────────────────────────────── - # Following the piranesi pattern, secrets live in SSM Parameter Store as + # Secrets live in SSM Parameter Store as # namespaced SecureString parameters (e.g. /dispatch/OPENROUTER_API_KEY) that # the USER writes in a skill phase (Phase 2) before the service scales up. # They are not owned by this stack, so they survive stack deletes and stack # updates never clobber their values. # - # Secrets live as SSM SecureString parameters under /dispatch/ (the piranesi - # pattern) and are NOT CloudFormation resources, so they survive stack + # Secrets live as SSM SecureString parameters under /dispatch/ and are NOT + # CloudFormation resources, so they survive stack # updates/deletes. They reach the container two ways: # # 1. aws_ssm secret-source plugin (hermes-aws-ssm-secret-source) — resolves diff --git a/template/AGENTS.md b/template/AGENTS.md index 0ec3257..3b8e046 100644 --- a/template/AGENTS.md +++ b/template/AGENTS.md @@ -53,7 +53,7 @@ You can use web-search-prime to look things up that aren't obvious in the reposi replacement. SQLite's WAL mode needs a real local block device (it is unsafe on NFS), which is the reason state is on EBS. - Secrets are **SSM SecureString** parameters under the claw's `/dispatch/KEY` - namespace, written by the user in setup Phase 3 (piranesi pattern). Not + namespace, written by the user in setup Phase 3. Not stack-owned, so they survive stack updates/deletes. A Hermes secret-source plugin (`aws_ssm`, installed in setup Phase 5) resolves every `/dispatch/*` parameter into the gateway env at startup, using the TaskRole's SSM-read