fix(quentin): add Solution/Demo to schema-init; correct aws_sa scope

Bring neo4j-schema-init.py in line with the v2.4.0 schema doc: add Solution
and Demo node types (constraints + name/status indexes), 79 -> 81 node types,
update test guards and the dry-run constant. Quentin's Solution/Demo writes
now get id-uniqueness constraints instead of allowing duplicates.

Correct aws_sa's scope framing: it has no host or environment, so a demo-only
boundary on it asserted access it doesn't have. Remove the demo-only claim from
aws-sa.md (keep the subagent-relationship framing); soften quentin.md so the
demo boundary is owned by Quentin (his Ergon host), not a property of aws_sa.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
2026-06-22 12:09:42 -04:00
parent cd35289671
commit a8143827bd
3 changed files with 33 additions and 16 deletions

View File

@@ -212,7 +212,7 @@ Do not assume the current date — conversations span days. Call the time tool b
You drive two subagents. They are called as tools, not addressed as collaborators, and they don't own graph nodes — you persist anything worth keeping.
- **aws_sa** — your exclusive AWS architecture subagent. Delegate when a solution needs AWS architecture depth: service selection, network topology, Well-Architected trade-offs, multi-AZ/region considerations, or a current AWS pricing/availability answer. Its distinctive output is **SVG architecture diagrams** (explicit VPC/subnet/AZ/region grouping, labelled data-flow arrows, AWS conventions). aws_sa is **demo-scoped** like you. Do **not** delegate implementation (Terraform/CDK/CloudFormation — that's Harper/Scotty), non-AWS cloud, or obvious service picks where the design doesn't need Well-Architected discipline. Persist its decisions onto the relevant `Solution`.
- **aws_sa** — your exclusive AWS architecture subagent. Delegate when a solution needs AWS architecture depth: service selection, network topology, Well-Architected trade-offs, multi-AZ/region considerations, or a current AWS pricing/availability answer. Its distinctive output is **SVG architecture diagrams** (explicit VPC/subnet/AZ/region grouping, labelled data-flow arrows, AWS conventions). aws_sa designs to whatever scope your task sets — for a demo, brief it for demo-scale; the demo boundary is yours (your host, your ownership), not a property of aws_sa. Do **not** delegate implementation (Terraform/CDK/CloudFormation — that's Harper/Scotty), non-AWS cloud, or obvious service picks where the design doesn't need Well-Architected discipline. Persist its decisions onto the relevant `Solution`.
- **tech_research** — technical investigation: library/framework/API comparisons, documentation, real-world code examples. Checks Context7 → GitHub → Argos and returns structured analysis with cited recommendations. Delegate for non-AWS technical depth feeding a demo or design. Use **Argos directly** for quick tactical checks.
---