Stay compliant through the SDLC

Run the start-dev prompt for use case <USE_CASE_ID>.
Acknowledge the controls you ingested, then wait for my task.

Run start-dev with no useCaseId so you load org plus all team
use-case developer guidance. Then help me add rate limiting to
the public API.

Run start-dev for use case <USE_CASE_ID>. Extra instructions:
follow our existing auth middleware patterns in apps/api/src/middleware,
never add a new secrets store, and add or update tests for every
security-sensitive change.

Using the Keldyn MCP server:
1. Call list-use-cases and tell me if a use case already exists for
   this repository / service.
2. If none does, draft a create-use-case payload from the README and
   code (name, description, AI models if any). Ask me before you save
   anything I cannot derive (risk level, stakeholders, decision types).
3. After I confirm, create the use case.

Call list-frameworks with scope use_case. Recommend which frameworks
belong on use case <USE_CASE_ID> given this repo, then assign the ones
I approve with assign-use-case-framework. Do not assign org-only
frameworks.

Use the generate-architecture prompt for use case <USE_CASE_ID>,
scoped to apps/api. Map services, data stores, auth, queues, and
external integrations from the code. Also read infra/ (Terraform)
for trust boundaries and managed stores. Show me the model, then
save it with update-use-case-architecture.

Run analyze-use-case-architecture for use case <USE_CASE_ID> and
list issues by severity. For each, tell me whether it is a Threagile
security risk or an RCM compliance failure, which asset it hits, and
the proposedEdit.

For the highest-severity issues from that analysis, propose concrete
architecture edits (do not invent services). After I approve, save
with update-use-case-architecture and re-run analyze-use-case-architecture
to confirm they cleared.

Using Keldyn MCP for use case <USE_CASE_ID>, list-controls with
relevance code. Group them by theme (auth, encryption, API security,
logging, data-subject rights). Then get-control for every control
in the theme I am about to work on so we have acceptance criteria
before we write code.

I am adding <FEATURE> in <PATH>. After start-dev for use case
<USE_CASE_ID>, identify the controls this change must satisfy.
Implement the feature so those controls hold by construction:
follow each control's developer guidance, add or update tests that
would fail if the control stopped holding, and do not weaken any
control marked Implemented.
Show the plan (controls + files you will touch) before you edit.

List open tasks for this team (list-tasks), starting with URGENT and
HIGH. For the first one: get-task, get-control for its rcmId, implement
the gap in this repo, add tests, then stop and show me the diff before
you update-task or update-control.

Run review-changes for use case <USE_CASE_ID> against my uncommitted
changes. Only report findings tied to a listed control, with file,
line, severity, and a concrete fix. If the diff satisfies every
applicable control, say so plainly.

Run review-changes for use case <USE_CASE_ID>, target "changes vs
main". Flag any Implemented control whose prior evidence this branch
weakens or removes.

Run review-changes scoped to apps/api. Extra instructions: treat
missing tests for a newly touched auth or crypto path as a finding
if a control requires them.

Fix the high and critical findings from that review. Keep the change
scoped to the controls that failed. When you are done, run
review-changes again on the new diff and confirm those findings are
gone without regressing Implemented controls.

Run review-codebase for use case <USE_CASE_ID>. For each control,
say whether the code addresses it, partially addresses it, or does
not. Cite file paths and line ranges. Do not update Keldyn until I
approve.

Run review-codebase for use case <USE_CASE_ID>, scope apps/api.
Prioritize auth, secrets, data handling, and external I/O.

Using that review for use case <USE_CASE_ID>:
1. For fully addressed controls, draft update-control calls with
   status complete and evidenceText that names files and how they
   satisfy the criterion.
2. For partial / failing controls, draft create-task payloads linked
   with rcmId, describing current state, gap, and remediation.
Show the plan. Do not write to Keldyn until I say so.

Run collect-evidence for use case <USE_CASE_ID> and framework
"SOC 2", scoped to apps/api. Positive evidence only — cite file
paths. Propose complete only when the control is clearly implemented.
Show the list and wait for me to approve before update-control.

Run remediate-insufficient-evidence for use case <USE_CASE_ID>
and framework "SOC 2". For each gap, gather stronger file-backed
evidence that hits every listed acceptance criterion. Show proposed
evidenceText, then save only after I confirm. Do not set status
complete yourself — let the sufficiency engine re-score.

For every in-scope AppSec control on use case <USE_CASE_ID> that is
code-relevant: implement any gap, add a unit or integration test
that would fail if the control stopped holding, and draft evidenceText
that points at implementation path(s) and test path(s). Leave process
and infra controls as dated N/A or defer notes. Show the plan first.

Run review-changes for use case <USE_CASE_ID>, target "changes vs
main". If anything still fails a control, fix it on this branch.
Do not update Keldyn status from a review — only from confirmed
evidence after merge.

The change for task <TASK_ID> / control <RCM_ID> is merged.
Update-task to done. Then update-control for use case <USE_CASE_ID>
with status complete and evidenceText that cites the merged files
and tests.

Re-run generate-architecture for use case <USE_CASE_ID> scoped to
the packages we changed. Diff the new model against what is saved.
Show me what you would add or remove, then save and run
analyze-use-case-architecture.

Run analyze-use-case-architecture for use case <USE_CASE_ID> with
source=security. For each open risk, search this repo for real
mitigations before proposing a disposition. Draft update-risk-tracking
payloads (mitigated / accepted / false-positive) with justification.
Do not save accepted or false-positive without my approval.

For use case <USE_CASE_ID>: list-controls (relevance code) that are
still todo or in_progress, and list-tasks that are open and linked
to an rcmId. Propose the next week's work ordered by risk, and call
out any Implemented control whose evidence looks stale relative to
the current code.