TruStacks and spec-driven development
If you arrived from a spec-driven development (SDD) context, such as GitHub Spec Kit, AWS Kiro, Claude Code plan mode or Cursor commands, this page explains where TruStacks fits.
The short version: spec tools turn intent into code; TruStacks governs how that code is delivered. TruStacks is AI delivery governance: the control layer between the agents that write your software and the systems that run it. It is not a spec tool and does not plan to become one.
What spec tools do well
Spec-first tools make requirements machine-readable and generate code, tests and scaffolding from them. Re-running generation against an updated spec moves the implementation forward. Teams that adopt them ship faster on the parts of the codebase the specs cover.
What they leave open
Generating code does not answer what has to be true before this reaches production?
- Delivery artifacts. Someone still writes the CI pipeline, the Helm chart or Kustomize overlays, and the ArgoCD Application, and keeps them consistent across services.
- Policy. Does the deploy respect your standards: tests and lint in CI, non-root containers, actions pinned to commit SHAs, manual promotion to production?
- Evidence. Can you show an auditor which rule a change was checked against, and who approved it?
Where TruStacks fits
TruStacks works once code exists in a service repo, however it got there.
- The Code Reviewer reads the service repo and describes it.
- The DevOps Engineer reads that analysis, your declared stack
(
environment-profile.yaml) and your platform repo, and drafts the delivery artifacts. - The artifacts are validated (do they render and parse?) and then judged by OPA against TruStacks’ signed constitution plus any rules you add. A deny stops the run with the rule cited.
- On allow, a pull request opens on your platform repo, explaining itself: summary, blast radius, rollback, rules cited, what it preserved.
- A person on your team reviews and merges it. Your ArgoCD deploys what was merged.
| Concern | Where it lives |
|---|---|
| Writing the spec | Your spec tool |
| Generating application code from it | Your spec tool (or your engineers) |
| The application source | Your service repo |
| CI workflow, Helm or Kustomize, ArgoCD Application | Drafted by TruStacks agents |
| The policy verdict on those artifacts | TruStacks (OPA, signed constitution, your overlay rules) |
| Review and merge | You |
| Deploying to the cluster | Your ArgoCD |
A team running both gets a clean split: the spec tool decides what the code should do; TruStacks drafts how it ships and checks it against your rules; a human decides whether it merges.
What TruStacks does not do today
- It does not read or evaluate your spec files.
- It does not review application-code pull requests opened by spec tools or coding agents. Its policy gate judges the delivery artifacts TruStacks’ own agents propose.
- It does not merge, deploy or operate your tools. It emits configuration; you run it on your stack.
Coexist, do not compete. Keep the spec tool you like, or change it later. The delivery governance layer is independent of how the code was written.
Where to go next
- Agents propose. Policy decides. Humans approve: the crew and the gate in detail.
- Product guide: every screen in the app.
- Constitution reference: the rules every proposal is judged against.
- Hosted quickstart: set up a workspace.