Compare commits

...

11 Commits

Author SHA1 Message Date
SentryAgent.ai Developer
4cb168bbba docs(openspec): mark tenant-isolation-enforcement complete and archive
All 8 tasks checked off. Change archived to openspec/changes/archive/
per OpenSpec protocol. Implementation committed in 5943ff1.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
2026-04-09 05:29:54 +00:00
SentryAgent.ai Developer
5943ff136f fix(security): enforce tenant isolation on all agent endpoints — resolves Test C.7
P0 security fix. Any authenticated agent could previously read, modify, or
decommission agents belonging to other organizations.

Changes:
- IAgentListFilters: add organizationId field (forced from JWT, never from query)
- AgentRepository.findAll(): filter by organizationId when set
- AgentService: getAgentById, updateAgent, decommissionAgent — accept organizationId
  and throw AuthorizationError(403) on cross-tenant access
- AgentController: extract req.user.organization_id on all 5 handlers; throw 403
  if claim is absent; registerAgent forces body.organizationId from JWT claim
- OpenAPI spec: document tenant isolation rules per endpoint
- Tests: update MOCK_USER with organization_id; add 5 new missing-org-id 403 tests;
  assert organizationId is passed through to service on all mutating calls

Fixes field trial failure: Test C.7 (Org Isolation).

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
2026-04-09 05:22:48 +00:00
SentryAgent.ai Developer
5e580b51dd fix(tests): resolve 4 failing test suites and patch lodash vulnerability
Test fixes (type mismatches introduced by V&V resolution changes):
- HealthDetailedController.test.ts: replace pool/makePool with dbProbe/makeDbProbe
  to match refactored HealthDetailedDeps interface (Pool → DbProbe abstraction)
- EventPublisher.test.ts: pass all 4 required constructor args to WebhookDeliveryWorker
  mock (pool, vaultClient, redisClient, redisUrl) — was passing only 1
- MarketplaceService.test.ts: IAgent.did/didCreatedAt are string|undefined (not null);
  fix makeAgent defaults and makeAgent({did:null}) call; fix type assertion to unknown first
- OIDCTrustPolicyService.test.ts: ICreateTrustPolicyRequest.branch is string|undefined
  (not nullable); replace all branch:null with branch:undefined

Security fix:
- npm audit fix: lodash ≤4.17.23 (HIGH) → patched; 0 vulnerabilities remaining

Result: 50/50 test suites pass, 722/722 tests pass, 0 vulnerabilities

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
2026-04-08 08:40:23 +00:00
SentryAgent.ai Developer
f9a6a8aafb docs(devops): update all documentation for DockerSpec compliance
- Replace all docker-compose.yml/docker-compose.monitoring.yml references with
  compose.yaml/compose.monitoring.yaml (modern Compose Spec naming)
- Replace all `docker-compose` CLI commands with `docker compose` (plugin syntax)
- Update Dockerfile stage descriptions: node:18-alpine → node:20.11-bookworm-slim,
  built-in node user → explicit nodeapp:1001 non-root user
- Update image version references: postgres:14-alpine → postgres:14.12-alpine3.19,
  redis:7-alpine → redis:7.2-alpine3.19
- Externalize postgres credentials: hardcoded values → POSTGRES_USER/PASSWORD/DB env vars
- Externalize Grafana admin password: hardcoded 'agentidp' → GF_ADMIN_PASSWORD env var
- Add Docker Compose Variables section to environment-variables.md (POSTGRES_*, GF_ADMIN_PASSWORD)
- Update local-development.md Step 3: cp .env.example .env, document POSTGRES_* purpose
- Update quick-start.md: cp .env.example .env, use awk/sed for JWT key injection
- Update 07-dev-setup.md: remove 'no .env.example' claim, reference cp .env.example
- Update docker-compose.yml key file description in 04-codebase-structure.md
- Update monitoring overlay launch commands across all docs (compose.yaml + compose.monitoring.yaml)
- Update volume names to kebab-case: postgres_data → postgres-data, redis_data → redis-data
- Fix compliance encryption-runbook: docker-compose restart agentidp → docker compose restart app

All docs now consistent with compose.yaml in repo root.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
2026-04-08 08:27:37 +00:00
SentryAgent.ai Developer
6fada694bb fix(docker): remediate all DockerSpec violations for field trial
- Replace docker-compose.yml → compose.yaml (modern Compose Spec, no version header)
- Replace docker-compose.monitoring.yml → compose.monitoring.yaml
- Remove deprecated version: '3.x' headers from both compose files
- Add dedicated app-tier bridge network (no default bridge)
- Add restart: unless-stopped to all services
- Add deploy.resources.limits (memory + cpu) to all services
- Add healthcheck to app service (curl /health)
- Add healthchecks to prometheus and grafana in monitoring overlay
- Externalize postgres credentials to env vars (POSTGRES_USER/PASSWORD/DB)
- Externalize grafana admin password to GF_ADMIN_PASSWORD env var
- Make env_file optional (required: false) for CI/field-trial environments
- Update Dockerfile: node:18-alpine → node:20.11-bookworm-slim (pinned version)
- Add explicit non-root system user/group (nodejs:1001/nodeapp:1001)
- Add curl install to final stage for healthcheck probe
- Copy src/db/migrations from build stage (not host bind)
- Expand .dockerignore: tmp/, temp/, *.env.*, compose files, Dockerfiles
- Add .env.example to git (was ignored by .env.* rule — add !.env.example exception)
- Add POSTGRES_USER/PASSWORD/DB and GF_ADMIN_PASSWORD to .env.example

All compose files pass: docker compose config --quiet 

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
2026-04-08 08:19:49 +00:00
SentryAgent.ai Developer
30dc793ceb feat(governance): add CTO autonomy mandate, TBC session 2 minutes, and high-autonomy launcher
- CTO-AUTONOMY.md: CEO-authorized autonomy governance — defines act-freely scope and hard stops
- scripts/start-cto.sh: updated to launch with --dangerously-skip-permissions for full autonomy
- TBC/minutes/TBC-MIN-002-2026-04-07.md: session 2 opening minutes

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
2026-04-08 05:28:42 +00:00
SentryAgent.ai Developer
861d9312d8 feat(tbc): add TBC agent launcher and workspace
Adds start-tbc.sh and .tbc-workspace/CLAUDE.md for the Technical &
Business Consultant role — independent advisory agent reporting to CEO,
matching the established pattern of start-cto.sh / .cto-workspace/.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
2026-04-07 08:55:45 +00:00
SentryAgent.ai Developer
dceefebf18 chore(config): add PRD.md and .claude/ project config to repository
- PRD.md: Product Requirements Document (single source of truth for all requirements)
- .claude/settings.local.json: Claude Code agent permission config
- .claude/commands/: project-specific slash commands
- .claude/skills/: project-specific skill definitions

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
2026-04-07 08:43:04 +00:00
SentryAgent.ai Developer
4e3b989629 feat(governance): add CTO session completion protocol, TBC charter, and process governance OpenSpec change
- CLAUDE.md + README.md: new CTO Session Completion Protocol (authorized/done vocabulary, end-of-session summary requirement)
- docs/engineering/08-workflow.md: Section 8 — CTO Session Completion Protocol
- scripts/start-cto.sh: startup protocol updated to read PRD.md first
- openspec/changes/process-governance-handoff-gap/: full OpenSpec change record (proposal, design, specs, tasks)
- TBC/charter.md: Technical & Business Consultant charter
- TBC/minutes/TBC-MIN-001-2026-04-07.md: inaugural TBC meeting minutes

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
2026-04-07 08:41:12 +00:00
SentryAgent.ai Developer
7441c9f298 fix(vv): resolve all 6 V&V issues — field trial unblocked
All findings from the inaugural LeadValidator audit resolved and
confirmed. Release gate: PASS.

VV_ISSUE_002 (BLOCKER): 15 OpenAPI specs verified present covering
all 20 route groups (46 endpoints documented in docs/openapi/)

VV_ISSUE_003 (MAJOR): Remove any types from src/db/pool.ts —
replaced pool.query shim with unknown[] + Object.defineProperty,
zero any types, eslint-disable suppressions removed

VV_ISSUE_004 (MAJOR): Remove raw Pool from ScaffoldController and
HealthDetailedController — injected AgentRepository/CredentialRepository
and DbProbe interface respectively; added CredentialRepository.findActiveClientId()

VV_ISSUE_005 (MAJOR): Add unit tests for 5 untested services —
ComplianceStatusStore, EventPublisher, MarketplaceService,
OIDCTrustPolicyService, UsageService

VV_ISSUE_006 (MAJOR): Add integration tests for 7 missing route
groups — analytics, billing, tiers, webhooks, marketplace,
oidc-trust-policies, oidc-token-exchange

VV_ISSUE_001 (MINOR): Create missing design.md and tasks.md in 4
OpenSpec archives — all archives now complete

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
2026-04-07 04:52:47 +00:00
SentryAgent.ai Developer
d216096dfb feat(governance): add V&V Architect (LeadValidator) — independent audit agent
Fixes a critical bug where VALIDATOR.md contained a copy of start-validator.sh
(making the validator unlaunchable). Introduces a fully independent V&V Architect
agent that audits the codebase against the PRD and OpenSpec outside the CTO's
chain of command.

Changes:
- VALIDATOR.md: rewritten as proper system prompt (8-phase audit methodology,
  issue format, severity model, communication protocol)
- scripts/start-validator.sh: isolated workspace setup, sanity check, auto-init
  ledger, validator-specific CLAUDE.md (no CEO context contamination)
- openspec/vv_audit/LEDGER.md: shared audit ledger index (CEO release gate view)
- openspec/changes/archive/2026-04-07-vv-architect-setup/: full OpenSpec artifacts
  (proposal.md, design.md, tasks.md — 28 tasks, all complete)

Note: .cto-workspace/CLAUDE.md updated (gitignored — persists on disk only).
#vv-findings hub channel created for real-time validator notifications.

CEO approved 2026-04-07.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
2026-04-07 02:56:36 +00:00
113 changed files with 14125 additions and 1288 deletions

View File

@@ -0,0 +1,198 @@
---
name: "Continue"
description: Capture a full project status snapshot so the next session can continue seamlessly from where this one left off
category: Workflow
tags: [workflow, session, continuity, memory, snapshot]
---
Capture the full current project status and store it in persistent memory so the next session can pick up exactly where this one left off — no context lost, no recap needed.
**Input**: No arguments required. Run `/continue` at any point when ending a session.
---
**Steps**
1. **Capture git state**
Run the following in parallel:
```bash
git status
git branch --show-current
git log --oneline -10
git diff --stat HEAD
git stash list
```
Record:
- Current branch name
- Uncommitted files (staged and unstaged), with change type (M/A/D/?)
- Last 10 commit messages (for continuity context)
- Summary of diff stats if uncommitted changes exist
- Any stashed work
2. **Capture OpenSpec change state**
Run `openspec list --json` to get all active changes.
For each active (non-archived) change, run:
```bash
openspec status --change "<name>" --json
```
For each active change, also read its `tasks.md` to count:
- Total tasks
- Completed tasks (`- [x]`)
- Pending tasks (`- [ ]`)
- The text of the next pending task (to know what's up next)
Record per change:
- Change name
- Schema
- Artifact completion (which are done, which are pending)
- Task progress (X of Y complete)
- Next pending task description
- Any delta specs present (`openspec/changes/<name>/specs/`)
**If no active changes:** Note that there are no active OpenSpec changes.
3. **Capture in-session conversation context**
Summarize what was worked on in this session based on the conversation:
- What was the user trying to accomplish?
- What was completed?
- What was left in-progress or blocked?
- Any key decisions made during this session
- Any open questions or next actions the user mentioned
Keep this factual and brief — 38 bullet points.
4. **Capture memory file state**
Read `MEMORY.md` from the project memory directory:
`~/.claude/projects/-home-ubuntu-vj-ai-agents-dev-sentryagent-idp/memory/MEMORY.md`
Note the existing memory entries to avoid duplication in the next step.
5. **Write session snapshot to memory**
Write a `session_snapshot.md` file to the project memory directory:
`~/.claude/projects/-home-ubuntu-vj-ai-agents-dev-sentryagent-idp/memory/session_snapshot.md`
Use this structure:
```markdown
---
name: Session Snapshot
description: Last session status — git state, OpenSpec progress, and conversation context for seamless resumption
type: project
---
**Session ended:** YYYY-MM-DD (today's date)
## Git State
**Branch:** <branch-name>
**Uncommitted changes:** <count> files (<list filenames>)
**Last commit:** <hash> <message>
<If uncommitted changes exist, list them with their status>
<If stashes exist, list them>
## OpenSpec Changes
<For each active change:>
### <change-name>
- **Schema:** <schema-name>
- **Artifacts:** <done-count>/<total-count> complete (<list incomplete artifact names>)
- **Tasks:** <done-count>/<total-count> complete
- **Next task:** <text of next pending task>
- **Delta specs:** <present / none>
<If no active changes:> No active OpenSpec changes.
## Session Work
<Bullet list of what was worked on, completed, and left in-progress>
## Next Actions
<Bullet list of concrete next steps to resume — derived from pending tasks, blockers, open questions>
```
**IMPORTANT:** Always overwrite `session_snapshot.md` — this is a rolling snapshot, not a log. Only the most recent session state matters.
6. **Update MEMORY.md index**
Read the current `MEMORY.md`. If `session_snapshot.md` is not already listed, add it:
```
- [Session Snapshot](session_snapshot.md) — Last session: YYYY-MM-DD | branch: <name> | <N> active changes | <N> uncommitted files
```
If it is already listed, update the line to reflect today's date and current state.
Write the updated `MEMORY.md`.
7. **Display break summary**
Show a clean summary so the user knows the snapshot is complete:
```
## Snapshot Saved — See You Next Session
**Branch:** <branch-name>
**Uncommitted files:** <count> (<filenames>)
**Active changes:** <count>
<For each active change:>
- <change-name>: <done>/<total> tasks complete — Next: "<next task text>"
**Session context saved to memory.**
To resume: start a new session and run /continue — Claude will load the snapshot and pick up where you left off.
```
---
**Output On Success (with active changes)**
```
## Snapshot Saved — See You Next Session
**Branch:** develop
**Uncommitted files:** 3 (src/auth/token.ts, tests/auth.test.ts, README.md)
**Active changes:** 1
- add-agent-auth: 4/7 tasks complete — Next: "Implement JWT signing with RS256"
**Session context saved to memory.**
To resume: start a new session and run /continue — Claude will load the snapshot and pick up where you left off.
```
**Output On Success (clean state)**
```
## Snapshot Saved — See You Next Session
**Branch:** main
**Uncommitted files:** 0
**Active changes:** 0
**Session context saved to memory.**
To resume: start a new session and run /continue — Claude will load the snapshot and pick up where you left off.
```
---
**Guardrails**
- Always overwrite `session_snapshot.md` — do NOT append or create versioned copies
- Never include secrets, tokens, or credentials in the snapshot
- If `openspec list` fails (CLI not available), note that and skip OpenSpec capture gracefully
- If git is unavailable, note that and skip git capture gracefully
- Keep the session context summary factual — no speculation about future plans beyond what the user explicitly stated
- The MEMORY.md index line for `session_snapshot.md` must stay under 150 characters
- This command does NOT commit code, push branches, or modify any project files — it only writes to the memory directory

View File

@@ -0,0 +1,160 @@
---
name: "OpenSpec Project Status"
description: Show a human-readable summary of all OpenSpec changes — active, archived, artifact completion, and task progress
category: Workflow
tags: [workflow, status, openspec, reporting]
---
Show the full OpenSpec project status in a clear, human-readable format. No raw JSON — just a clean picture of where the project stands.
**Input**: No arguments required. Run `/openspec-project-status` at any time.
---
**Steps**
1. **Get all changes**
Run:
```bash
openspec list --json
```
Separate results into:
- **Active changes** (not in `archive/`)
- **Archived changes** (in `archive/`)
If the command fails or no changes exist, display a friendly empty state (see Output section).
2. **For each active change, gather full status**
Run in parallel for all active changes:
```bash
openspec status --change "<name>" --json
```
Also read each change's `tasks.md` to extract:
- Total task count
- Completed tasks (`- [x]`)
- Pending tasks (`- [ ]`)
- Text of the **next pending task** (first `- [ ]` item)
Also check for delta specs at `openspec/changes/<name>/specs/` — note if present.
3. **For archived changes**
List them by archive date (newest first). No need to read full status — just show name and archive date from the folder name (`YYYY-MM-DD-<name>`).
4. **Render the human-readable status report**
Use the output format defined below.
---
**Output Format**
```
## OpenSpec Project Status
### Active Changes (<count>)
────────────────────────────────────────
<change-name>
────────────────────────────────────────
Schema: <schema-name>
Phase: <inferred from artifact state: Proposing | Designing | Ready to Implement | In Progress | Complete>
Artifacts
✓ proposal done
✓ design done
◌ tasks pending
Tasks <done>/<total> complete
████████░░░░░░░░ 50%
Next: "<text of next pending task>"
Delta Specs <present / none>
────────────────────────────────────────
<Repeat for each active change>
---
### Archived Changes (<count>)
2026-03-20 add-initial-auth
2026-03-15 setup-ci-pipeline
2026-03-10 scaffold-project
---
### Summary
Active changes: <N>
Ready to apply: <N> (all artifacts done, tasks pending)
In progress: <N> (tasks partially complete)
Complete: <N> (all tasks done, not yet archived)
Archived: <N>
```
**Phase inference rules** (from artifact + task state):
- `Proposing` — proposal artifact is not done
- `Designing` — proposal done, design not done
- `Speccing` — design done, tasks artifact not done
- `Ready to Implement` — all artifacts done, 0 tasks complete
- `In Progress` — all artifacts done, some tasks complete but not all
- `Complete` — all artifacts done, all tasks complete (not yet archived)
**Progress bar rules:**
- 16 chars wide: `` per completed segment, `` for remaining
- Show percentage after bar
- If 0 tasks: show `No tasks yet`
- If all tasks done: show `████████████████ 100% All done!`
---
**Output: No active changes**
```
## OpenSpec Project Status
### Active Changes (0)
No active changes. Start one with /opsx:propose
---
### Archived Changes (<count>)
2026-03-20 add-initial-auth
...
---
### Summary
Active changes: 0
Archived: <N>
```
**Output: OpenSpec CLI unavailable**
```
## OpenSpec Project Status
OpenSpec CLI not available. Cannot read change data.
Make sure `openspec` is installed and accessible in your PATH.
```
---
**Guardrails**
- Never show raw JSON — always translate to human-readable output
- Never guess artifact or task state — always read from actual files and CLI output
- If a `tasks.md` file does not exist for a change, show `No tasks file` instead of 0/0
- Archived changes are display-only — never modify them
- Phase labels must be inferred strictly from actual artifact + task state, not assumed
- If `openspec status` fails for a specific change, show that change with `Status unavailable` and continue

View File

@@ -0,0 +1,152 @@
---
name: "OPSX: Apply"
description: Implement tasks from an OpenSpec change (Experimental)
category: Workflow
tags: [workflow, artifacts, experimental]
---
Implement tasks from an OpenSpec change.
**Input**: Optionally specify a change name (e.g., `/opsx:apply add-auth`). If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
**Steps**
1. **Select the change**
If a name is provided, use it. Otherwise:
- Infer from conversation context if the user mentioned a change
- Auto-select if only one active change exists
- If ambiguous, run `openspec list --json` to get available changes and use the **AskUserQuestion tool** to let the user select
Always announce: "Using change: <name>" and how to override (e.g., `/opsx:apply <other>`).
2. **Check status to understand the schema**
```bash
openspec status --change "<name>" --json
```
Parse the JSON to understand:
- `schemaName`: The workflow being used (e.g., "spec-driven")
- Which artifact contains the tasks (typically "tasks" for spec-driven, check status for others)
3. **Get apply instructions**
```bash
openspec instructions apply --change "<name>" --json
```
This returns:
- Context file paths (varies by schema)
- Progress (total, complete, remaining)
- Task list with status
- Dynamic instruction based on current state
**Handle states:**
- If `state: "blocked"` (missing artifacts): show message, suggest using `/opsx:continue`
- If `state: "all_done"`: congratulate, suggest archive
- Otherwise: proceed to implementation
4. **Read context files**
Read the files listed in `contextFiles` from the apply instructions output.
The files depend on the schema being used:
- **spec-driven**: proposal, specs, design, tasks
- Other schemas: follow the contextFiles from CLI output
5. **Show current progress**
Display:
- Schema being used
- Progress: "N/M tasks complete"
- Remaining tasks overview
- Dynamic instruction from CLI
6. **Implement tasks (loop until done or blocked)**
For each pending task:
- Show which task is being worked on
- Make the code changes required
- Keep changes minimal and focused
- Mark task complete in the tasks file: `- [ ]` → `- [x]`
- Continue to next task
**Pause if:**
- Task is unclear → ask for clarification
- Implementation reveals a design issue → suggest updating artifacts
- Error or blocker encountered → report and wait for guidance
- User interrupts
7. **On completion or pause, show status**
Display:
- Tasks completed this session
- Overall progress: "N/M tasks complete"
- If all done: suggest archive
- If paused: explain why and wait for guidance
**Output During Implementation**
```
## Implementing: <change-name> (schema: <schema-name>)
Working on task 3/7: <task description>
[...implementation happening...]
✓ Task complete
Working on task 4/7: <task description>
[...implementation happening...]
✓ Task complete
```
**Output On Completion**
```
## Implementation Complete
**Change:** <change-name>
**Schema:** <schema-name>
**Progress:** 7/7 tasks complete ✓
### Completed This Session
- [x] Task 1
- [x] Task 2
...
All tasks complete! You can archive this change with `/opsx:archive`.
```
**Output On Pause (Issue Encountered)**
```
## Implementation Paused
**Change:** <change-name>
**Schema:** <schema-name>
**Progress:** 4/7 tasks complete
### Issue Encountered
<description of the issue>
**Options:**
1. <option 1>
2. <option 2>
3. Other approach
What would you like to do?
```
**Guardrails**
- Keep going through tasks until done or blocked
- Always read context files before starting (from the apply instructions output)
- If task is ambiguous, pause and ask before implementing
- If implementation reveals issues, pause and suggest artifact updates
- Keep code changes minimal and scoped to each task
- Update task checkbox immediately after completing each task
- Pause on errors, blockers, or unclear requirements - don't guess
- Use contextFiles from CLI output, don't assume specific file names
**Fluid Workflow Integration**
This skill supports the "actions on a change" model:
- **Can be invoked anytime**: Before all artifacts are done (if tasks exist), after partial implementation, interleaved with other actions
- **Allows artifact updates**: If implementation reveals design issues, suggest updating artifacts - not phase-locked, work fluidly

View File

@@ -0,0 +1,157 @@
---
name: "OPSX: Archive"
description: Archive a completed change in the experimental workflow
category: Workflow
tags: [workflow, archive, experimental]
---
Archive a completed change in the experimental workflow.
**Input**: Optionally specify a change name after `/opsx:archive` (e.g., `/opsx:archive add-auth`). If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
**Steps**
1. **If no change name provided, prompt for selection**
Run `openspec list --json` to get available changes. Use the **AskUserQuestion tool** to let the user select.
Show only active changes (not already archived).
Include the schema used for each change if available.
**IMPORTANT**: Do NOT guess or auto-select a change. Always let the user choose.
2. **Check artifact completion status**
Run `openspec status --change "<name>" --json` to check artifact completion.
Parse the JSON to understand:
- `schemaName`: The workflow being used
- `artifacts`: List of artifacts with their status (`done` or other)
**If any artifacts are not `done`:**
- Display warning listing incomplete artifacts
- Prompt user for confirmation to continue
- Proceed if user confirms
3. **Check task completion status**
Read the tasks file (typically `tasks.md`) to check for incomplete tasks.
Count tasks marked with `- [ ]` (incomplete) vs `- [x]` (complete).
**If incomplete tasks found:**
- Display warning showing count of incomplete tasks
- Prompt user for confirmation to continue
- Proceed if user confirms
**If no tasks file exists:** Proceed without task-related warning.
4. **Assess delta spec sync state**
Check for delta specs at `openspec/changes/<name>/specs/`. If none exist, proceed without sync prompt.
**If delta specs exist:**
- Compare each delta spec with its corresponding main spec at `openspec/specs/<capability>/spec.md`
- Determine what changes would be applied (adds, modifications, removals, renames)
- Show a combined summary before prompting
**Prompt options:**
- If changes needed: "Sync now (recommended)", "Archive without syncing"
- If already synced: "Archive now", "Sync anyway", "Cancel"
If user chooses sync, use Task tool (subagent_type: "general-purpose", prompt: "Use Skill tool to invoke openspec-sync-specs for change '<name>'. Delta spec analysis: <include the analyzed delta spec summary>"). Proceed to archive regardless of choice.
5. **Perform the archive**
Create the archive directory if it doesn't exist:
```bash
mkdir -p openspec/changes/archive
```
Generate target name using current date: `YYYY-MM-DD-<change-name>`
**Check if target already exists:**
- If yes: Fail with error, suggest renaming existing archive or using different date
- If no: Move the change directory to archive
```bash
mv openspec/changes/<name> openspec/changes/archive/YYYY-MM-DD-<name>
```
6. **Display summary**
Show archive completion summary including:
- Change name
- Schema that was used
- Archive location
- Spec sync status (synced / sync skipped / no delta specs)
- Note about any warnings (incomplete artifacts/tasks)
**Output On Success**
```
## Archive Complete
**Change:** <change-name>
**Schema:** <schema-name>
**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
**Specs:** ✓ Synced to main specs
All artifacts complete. All tasks complete.
```
**Output On Success (No Delta Specs)**
```
## Archive Complete
**Change:** <change-name>
**Schema:** <schema-name>
**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
**Specs:** No delta specs
All artifacts complete. All tasks complete.
```
**Output On Success With Warnings**
```
## Archive Complete (with warnings)
**Change:** <change-name>
**Schema:** <schema-name>
**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
**Specs:** Sync skipped (user chose to skip)
**Warnings:**
- Archived with 2 incomplete artifacts
- Archived with 3 incomplete tasks
- Delta spec sync was skipped (user chose to skip)
Review the archive if this was not intentional.
```
**Output On Error (Archive Exists)**
```
## Archive Failed
**Change:** <change-name>
**Target:** openspec/changes/archive/YYYY-MM-DD-<name>/
Target archive directory already exists.
**Options:**
1. Rename the existing archive
2. Delete the existing archive if it's a duplicate
3. Wait until a different date to archive
```
**Guardrails**
- Always prompt for change selection if not provided
- Use artifact graph (openspec status --json) for completion checking
- Don't block archive on warnings - just inform and confirm
- Preserve .openspec.yaml when moving to archive (it moves with the directory)
- Show clear summary of what happened
- If sync is requested, use the Skill tool to invoke `openspec-sync-specs` (agent-driven)
- If delta specs exist, always run the sync assessment and show the combined summary before prompting

View File

@@ -0,0 +1,173 @@
---
name: "OPSX: Explore"
description: "Enter explore mode - think through ideas, investigate problems, clarify requirements"
category: Workflow
tags: [workflow, explore, experimental, thinking]
---
Enter explore mode. Think deeply. Visualize freely. Follow the conversation wherever it goes.
**IMPORTANT: Explore mode is for thinking, not implementing.** You may read files, search code, and investigate the codebase, but you must NEVER write code or implement features. If the user asks you to implement something, remind them to exit explore mode first and create a change proposal. You MAY create OpenSpec artifacts (proposals, designs, specs) if the user asks—that's capturing thinking, not implementing.
**This is a stance, not a workflow.** There are no fixed steps, no required sequence, no mandatory outputs. You're a thinking partner helping the user explore.
**Input**: The argument after `/opsx:explore` is whatever the user wants to think about. Could be:
- A vague idea: "real-time collaboration"
- A specific problem: "the auth system is getting unwieldy"
- A change name: "add-dark-mode" (to explore in context of that change)
- A comparison: "postgres vs sqlite for this"
- Nothing (just enter explore mode)
---
## The Stance
- **Curious, not prescriptive** - Ask questions that emerge naturally, don't follow a script
- **Open threads, not interrogations** - Surface multiple interesting directions and let the user follow what resonates. Don't funnel them through a single path of questions.
- **Visual** - Use ASCII diagrams liberally when they'd help clarify thinking
- **Adaptive** - Follow interesting threads, pivot when new information emerges
- **Patient** - Don't rush to conclusions, let the shape of the problem emerge
- **Grounded** - Explore the actual codebase when relevant, don't just theorize
---
## What You Might Do
Depending on what the user brings, you might:
**Explore the problem space**
- Ask clarifying questions that emerge from what they said
- Challenge assumptions
- Reframe the problem
- Find analogies
**Investigate the codebase**
- Map existing architecture relevant to the discussion
- Find integration points
- Identify patterns already in use
- Surface hidden complexity
**Compare options**
- Brainstorm multiple approaches
- Build comparison tables
- Sketch tradeoffs
- Recommend a path (if asked)
**Visualize**
```
┌─────────────────────────────────────────┐
│ Use ASCII diagrams liberally │
├─────────────────────────────────────────┤
│ │
│ ┌────────┐ ┌────────┐ │
│ │ State │────────▶│ State │ │
│ │ A │ │ B │ │
│ └────────┘ └────────┘ │
│ │
│ System diagrams, state machines, │
│ data flows, architecture sketches, │
│ dependency graphs, comparison tables │
│ │
└─────────────────────────────────────────┘
```
**Surface risks and unknowns**
- Identify what could go wrong
- Find gaps in understanding
- Suggest spikes or investigations
---
## OpenSpec Awareness
You have full context of the OpenSpec system. Use it naturally, don't force it.
### Check for context
At the start, quickly check what exists:
```bash
openspec list --json
```
This tells you:
- If there are active changes
- Their names, schemas, and status
- What the user might be working on
If the user mentioned a specific change name, read its artifacts for context.
### When no change exists
Think freely. When insights crystallize, you might offer:
- "This feels solid enough to start a change. Want me to create a proposal?"
- Or keep exploring - no pressure to formalize
### When a change exists
If the user mentions a change or you detect one is relevant:
1. **Read existing artifacts for context**
- `openspec/changes/<name>/proposal.md`
- `openspec/changes/<name>/design.md`
- `openspec/changes/<name>/tasks.md`
- etc.
2. **Reference them naturally in conversation**
- "Your design mentions using Redis, but we just realized SQLite fits better..."
- "The proposal scopes this to premium users, but we're now thinking everyone..."
3. **Offer to capture when decisions are made**
| Insight Type | Where to Capture |
|--------------|------------------|
| New requirement discovered | `specs/<capability>/spec.md` |
| Requirement changed | `specs/<capability>/spec.md` |
| Design decision made | `design.md` |
| Scope changed | `proposal.md` |
| New work identified | `tasks.md` |
| Assumption invalidated | Relevant artifact |
Example offers:
- "That's a design decision. Capture it in design.md?"
- "This is a new requirement. Add it to specs?"
- "This changes scope. Update the proposal?"
4. **The user decides** - Offer and move on. Don't pressure. Don't auto-capture.
---
## What You Don't Have To Do
- Follow a script
- Ask the same questions every time
- Produce a specific artifact
- Reach a conclusion
- Stay on topic if a tangent is valuable
- Be brief (this is thinking time)
---
## Ending Discovery
There's no required ending. Discovery might:
- **Flow into a proposal**: "Ready to start? I can create a change proposal."
- **Result in artifact updates**: "Updated design.md with these decisions"
- **Just provide clarity**: User has what they need, moves on
- **Continue later**: "We can pick this up anytime"
When things crystallize, you might offer a summary - but it's optional. Sometimes the thinking IS the value.
---
## Guardrails
- **Don't implement** - Never write code or implement features. Creating OpenSpec artifacts is fine, writing application code is not.
- **Don't fake understanding** - If something is unclear, dig deeper
- **Don't rush** - Discovery is thinking time, not task time
- **Don't force structure** - Let patterns emerge naturally
- **Don't auto-capture** - Offer to save insights, don't just do it
- **Do visualize** - A good diagram is worth many paragraphs
- **Do explore the codebase** - Ground discussions in reality
- **Do question assumptions** - Including the user's and your own

View File

@@ -0,0 +1,106 @@
---
name: "OPSX: Propose"
description: Propose a new change - create it and generate all artifacts in one step
category: Workflow
tags: [workflow, artifacts, experimental]
---
Propose a new change - create the change and generate all artifacts in one step.
I'll create a change with artifacts:
- proposal.md (what & why)
- design.md (how)
- tasks.md (implementation steps)
When ready to implement, run /opsx:apply
---
**Input**: The argument after `/opsx:propose` is the change name (kebab-case), OR a description of what the user wants to build.
**Steps**
1. **If no input provided, ask what they want to build**
Use the **AskUserQuestion tool** (open-ended, no preset options) to ask:
> "What change do you want to work on? Describe what you want to build or fix."
From their description, derive a kebab-case name (e.g., "add user authentication" → `add-user-auth`).
**IMPORTANT**: Do NOT proceed without understanding what the user wants to build.
2. **Create the change directory**
```bash
openspec new change "<name>"
```
This creates a scaffolded change at `openspec/changes/<name>/` with `.openspec.yaml`.
3. **Get the artifact build order**
```bash
openspec status --change "<name>" --json
```
Parse the JSON to get:
- `applyRequires`: array of artifact IDs needed before implementation (e.g., `["tasks"]`)
- `artifacts`: list of all artifacts with their status and dependencies
4. **Create artifacts in sequence until apply-ready**
Use the **TodoWrite tool** to track progress through the artifacts.
Loop through artifacts in dependency order (artifacts with no pending dependencies first):
a. **For each artifact that is `ready` (dependencies satisfied)**:
- Get instructions:
```bash
openspec instructions <artifact-id> --change "<name>" --json
```
- The instructions JSON includes:
- `context`: Project background (constraints for you - do NOT include in output)
- `rules`: Artifact-specific rules (constraints for you - do NOT include in output)
- `template`: The structure to use for your output file
- `instruction`: Schema-specific guidance for this artifact type
- `outputPath`: Where to write the artifact
- `dependencies`: Completed artifacts to read for context
- Read any completed dependency files for context
- Create the artifact file using `template` as the structure
- Apply `context` and `rules` as constraints - but do NOT copy them into the file
- Show brief progress: "Created <artifact-id>"
b. **Continue until all `applyRequires` artifacts are complete**
- After creating each artifact, re-run `openspec status --change "<name>" --json`
- Check if every artifact ID in `applyRequires` has `status: "done"` in the artifacts array
- Stop when all `applyRequires` artifacts are done
c. **If an artifact requires user input** (unclear context):
- Use **AskUserQuestion tool** to clarify
- Then continue with creation
5. **Show final status**
```bash
openspec status --change "<name>"
```
**Output**
After completing all artifacts, summarize:
- Change name and location
- List of artifacts created with brief descriptions
- What's ready: "All artifacts created! Ready for implementation."
- Prompt: "Run `/opsx:apply` to start implementing."
**Artifact Creation Guidelines**
- Follow the `instruction` field from `openspec instructions` for each artifact type
- The schema defines what each artifact should contain - follow it
- Read dependency artifacts for context before creating new ones
- Use `template` as the structure for your output file - fill in its sections
- **IMPORTANT**: `context` and `rules` are constraints for YOU, not content for the file
- Do NOT copy `<context>`, `<rules>`, `<project_context>` blocks into the artifact
- These guide what you write, but should never appear in the output
**Guardrails**
- Create ALL artifacts needed for implementation (as defined by schema's `apply.requires`)
- Always read dependency artifacts before creating a new one
- If context is critically unclear, ask the user - but prefer making reasonable decisions to keep momentum
- If a change with that name already exists, ask if user wants to continue it or create a new one
- Verify each artifact file exists after writing before proceeding to next

View File

@@ -0,0 +1,183 @@
---
name: continue
description: Capture a full project status snapshot so the next session can continue seamlessly from where this one left off. Use when the user is ending a session and wants to preserve context for resumption.
license: MIT
compatibility: Requires git. OpenSpec CLI optional (gracefully skipped if unavailable).
metadata:
author: sentryagent
version: "1.0"
generatedBy: "1.2.0"
---
Capture the full current project status and store it in persistent memory so the next session can pick up exactly where this one left off — no context lost, no recap needed.
**Input**: No arguments required. Invoke at any point when ending a session.
**Steps**
1. **Capture git state**
Run the following in parallel:
```bash
git status
git branch --show-current
git log --oneline -10
git diff --stat HEAD
git stash list
```
Record:
- Current branch name
- Uncommitted files (staged and unstaged), with change type (M/A/D/?)
- Last 10 commit messages (for continuity context)
- Summary of diff stats if uncommitted changes exist
- Any stashed work
2. **Capture OpenSpec change state**
Run `openspec list --json` to get all active changes.
For each active (non-archived) change, run:
```bash
openspec status --change "<name>" --json
```
For each active change, also read its `tasks.md` to count:
- Total tasks
- Completed tasks (`- [x]`)
- Pending tasks (`- [ ]`)
- The text of the next pending task (to know what's up next)
Record per change:
- Change name
- Schema
- Artifact completion (which are done, which are pending)
- Task progress (X of Y complete)
- Next pending task description
- Any delta specs present (`openspec/changes/<name>/specs/`)
**If `openspec` CLI is unavailable or fails:** Note it and skip this section gracefully.
**If no active changes:** Note that there are no active OpenSpec changes.
3. **Capture in-session conversation context**
Summarize what was worked on in this session based on the conversation:
- What was the user trying to accomplish?
- What was completed?
- What was left in-progress or blocked?
- Any key decisions made during this session
- Any open questions or next actions the user mentioned
Keep this factual and brief — 38 bullet points.
4. **Capture memory file state**
Read `MEMORY.md` from the project memory directory:
`~/.claude/projects/-home-ubuntu-vj-ai-agents-dev-sentryagent-idp/memory/MEMORY.md`
Note the existing memory entries to avoid duplication in the next step.
5. **Write session snapshot to memory**
Write a `session_snapshot.md` file to the project memory directory:
`~/.claude/projects/-home-ubuntu-vj-ai-agents-dev-sentryagent-idp/memory/session_snapshot.md`
Use this structure:
```markdown
---
name: Session Snapshot
description: Last session status — git state, OpenSpec progress, and conversation context for seamless resumption
type: project
---
**Session ended:** YYYY-MM-DD (today's date)
## Git State
**Branch:** <branch-name>
**Uncommitted changes:** <count> files (<list filenames>)
**Last commit:** <hash> <message>
<If uncommitted changes exist, list them with their status>
<If stashes exist, list them>
## OpenSpec Changes
<For each active change:>
### <change-name>
- **Schema:** <schema-name>
- **Artifacts:** <done-count>/<total-count> complete (<list incomplete artifact names>)
- **Tasks:** <done-count>/<total-count> complete
- **Next task:** <text of next pending task>
- **Delta specs:** <present / none>
<If no active changes:> No active OpenSpec changes.
## Session Work
<Bullet list of what was worked on, completed, and left in-progress>
## Next Actions
<Bullet list of concrete next steps to resume — derived from pending tasks, blockers, open questions>
```
**IMPORTANT:** Always overwrite `session_snapshot.md` — this is a rolling snapshot, not a log. Only the most recent session state matters.
6. **Update MEMORY.md index**
Read the current `MEMORY.md`. If `session_snapshot.md` is not already listed, add it:
```
- [Session Snapshot](session_snapshot.md) — Last session: YYYY-MM-DD | branch: <name> | <N> active changes | <N> uncommitted files
```
If it is already listed, update the line to reflect today's date and current state.
Write the updated `MEMORY.md`.
7. **Display break summary**
Show a clean summary so the user knows the snapshot is complete:
```
## Snapshot Saved — See You Next Session
**Branch:** <branch-name>
**Uncommitted files:** <count> (<filenames>)
**Active changes:** <count>
<For each active change:>
- <change-name>: <done>/<total> tasks complete — Next: "<next task text>"
**Session context saved to memory.**
To resume: start a new session and run /continue — Claude will load the snapshot and pick up where you left off.
```
**Output On Success**
```
## Snapshot Saved — See You Next Session
**Branch:** develop
**Uncommitted files:** 3 (src/auth/token.ts, tests/auth.test.ts, README.md)
**Active changes:** 1
- add-agent-auth: 4/7 tasks complete — Next: "Implement JWT signing with RS256"
**Session context saved to memory.**
To resume: start a new session and run /continue — Claude will load the snapshot and pick up where you left off.
```
**Guardrails**
- Always overwrite `session_snapshot.md` — do NOT append or create versioned copies
- Never include secrets, tokens, or credentials in the snapshot
- If `openspec list` fails (CLI not available), note that and skip OpenSpec capture gracefully
- If git is unavailable, note that and skip git capture gracefully
- Keep the session context summary factual — no speculation beyond what the user explicitly stated
- The MEMORY.md index line for `session_snapshot.md` must stay under 150 characters
- This skill does NOT commit code, push branches, or modify any project files — it only writes to the memory directory
- Session date must use the actual current date (not a placeholder)

View File

@@ -0,0 +1,156 @@
---
name: openspec-apply-change
description: Implement tasks from an OpenSpec change. Use when the user wants to start implementing, continue implementation, or work through tasks.
license: MIT
compatibility: Requires openspec CLI.
metadata:
author: openspec
version: "1.0"
generatedBy: "1.2.0"
---
Implement tasks from an OpenSpec change.
**Input**: Optionally specify a change name. If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
**Steps**
1. **Select the change**
If a name is provided, use it. Otherwise:
- Infer from conversation context if the user mentioned a change
- Auto-select if only one active change exists
- If ambiguous, run `openspec list --json` to get available changes and use the **AskUserQuestion tool** to let the user select
Always announce: "Using change: <name>" and how to override (e.g., `/opsx:apply <other>`).
2. **Check status to understand the schema**
```bash
openspec status --change "<name>" --json
```
Parse the JSON to understand:
- `schemaName`: The workflow being used (e.g., "spec-driven")
- Which artifact contains the tasks (typically "tasks" for spec-driven, check status for others)
3. **Get apply instructions**
```bash
openspec instructions apply --change "<name>" --json
```
This returns:
- Context file paths (varies by schema - could be proposal/specs/design/tasks or spec/tests/implementation/docs)
- Progress (total, complete, remaining)
- Task list with status
- Dynamic instruction based on current state
**Handle states:**
- If `state: "blocked"` (missing artifacts): show message, suggest using openspec-continue-change
- If `state: "all_done"`: congratulate, suggest archive
- Otherwise: proceed to implementation
4. **Read context files**
Read the files listed in `contextFiles` from the apply instructions output.
The files depend on the schema being used:
- **spec-driven**: proposal, specs, design, tasks
- Other schemas: follow the contextFiles from CLI output
5. **Show current progress**
Display:
- Schema being used
- Progress: "N/M tasks complete"
- Remaining tasks overview
- Dynamic instruction from CLI
6. **Implement tasks (loop until done or blocked)**
For each pending task:
- Show which task is being worked on
- Make the code changes required
- Keep changes minimal and focused
- Mark task complete in the tasks file: `- [ ]` → `- [x]`
- Continue to next task
**Pause if:**
- Task is unclear → ask for clarification
- Implementation reveals a design issue → suggest updating artifacts
- Error or blocker encountered → report and wait for guidance
- User interrupts
7. **On completion or pause, show status**
Display:
- Tasks completed this session
- Overall progress: "N/M tasks complete"
- If all done: suggest archive
- If paused: explain why and wait for guidance
**Output During Implementation**
```
## Implementing: <change-name> (schema: <schema-name>)
Working on task 3/7: <task description>
[...implementation happening...]
✓ Task complete
Working on task 4/7: <task description>
[...implementation happening...]
✓ Task complete
```
**Output On Completion**
```
## Implementation Complete
**Change:** <change-name>
**Schema:** <schema-name>
**Progress:** 7/7 tasks complete ✓
### Completed This Session
- [x] Task 1
- [x] Task 2
...
All tasks complete! Ready to archive this change.
```
**Output On Pause (Issue Encountered)**
```
## Implementation Paused
**Change:** <change-name>
**Schema:** <schema-name>
**Progress:** 4/7 tasks complete
### Issue Encountered
<description of the issue>
**Options:**
1. <option 1>
2. <option 2>
3. Other approach
What would you like to do?
```
**Guardrails**
- Keep going through tasks until done or blocked
- Always read context files before starting (from the apply instructions output)
- If task is ambiguous, pause and ask before implementing
- If implementation reveals issues, pause and suggest artifact updates
- Keep code changes minimal and scoped to each task
- Update task checkbox immediately after completing each task
- Pause on errors, blockers, or unclear requirements - don't guess
- Use contextFiles from CLI output, don't assume specific file names
**Fluid Workflow Integration**
This skill supports the "actions on a change" model:
- **Can be invoked anytime**: Before all artifacts are done (if tasks exist), after partial implementation, interleaved with other actions
- **Allows artifact updates**: If implementation reveals design issues, suggest updating artifacts - not phase-locked, work fluidly

View File

@@ -0,0 +1,114 @@
---
name: openspec-archive-change
description: Archive a completed change in the experimental workflow. Use when the user wants to finalize and archive a change after implementation is complete.
license: MIT
compatibility: Requires openspec CLI.
metadata:
author: openspec
version: "1.0"
generatedBy: "1.2.0"
---
Archive a completed change in the experimental workflow.
**Input**: Optionally specify a change name. If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
**Steps**
1. **If no change name provided, prompt for selection**
Run `openspec list --json` to get available changes. Use the **AskUserQuestion tool** to let the user select.
Show only active changes (not already archived).
Include the schema used for each change if available.
**IMPORTANT**: Do NOT guess or auto-select a change. Always let the user choose.
2. **Check artifact completion status**
Run `openspec status --change "<name>" --json` to check artifact completion.
Parse the JSON to understand:
- `schemaName`: The workflow being used
- `artifacts`: List of artifacts with their status (`done` or other)
**If any artifacts are not `done`:**
- Display warning listing incomplete artifacts
- Use **AskUserQuestion tool** to confirm user wants to proceed
- Proceed if user confirms
3. **Check task completion status**
Read the tasks file (typically `tasks.md`) to check for incomplete tasks.
Count tasks marked with `- [ ]` (incomplete) vs `- [x]` (complete).
**If incomplete tasks found:**
- Display warning showing count of incomplete tasks
- Use **AskUserQuestion tool** to confirm user wants to proceed
- Proceed if user confirms
**If no tasks file exists:** Proceed without task-related warning.
4. **Assess delta spec sync state**
Check for delta specs at `openspec/changes/<name>/specs/`. If none exist, proceed without sync prompt.
**If delta specs exist:**
- Compare each delta spec with its corresponding main spec at `openspec/specs/<capability>/spec.md`
- Determine what changes would be applied (adds, modifications, removals, renames)
- Show a combined summary before prompting
**Prompt options:**
- If changes needed: "Sync now (recommended)", "Archive without syncing"
- If already synced: "Archive now", "Sync anyway", "Cancel"
If user chooses sync, use Task tool (subagent_type: "general-purpose", prompt: "Use Skill tool to invoke openspec-sync-specs for change '<name>'. Delta spec analysis: <include the analyzed delta spec summary>"). Proceed to archive regardless of choice.
5. **Perform the archive**
Create the archive directory if it doesn't exist:
```bash
mkdir -p openspec/changes/archive
```
Generate target name using current date: `YYYY-MM-DD-<change-name>`
**Check if target already exists:**
- If yes: Fail with error, suggest renaming existing archive or using different date
- If no: Move the change directory to archive
```bash
mv openspec/changes/<name> openspec/changes/archive/YYYY-MM-DD-<name>
```
6. **Display summary**
Show archive completion summary including:
- Change name
- Schema that was used
- Archive location
- Whether specs were synced (if applicable)
- Note about any warnings (incomplete artifacts/tasks)
**Output On Success**
```
## Archive Complete
**Change:** <change-name>
**Schema:** <schema-name>
**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
**Specs:** ✓ Synced to main specs (or "No delta specs" or "Sync skipped")
All artifacts complete. All tasks complete.
```
**Guardrails**
- Always prompt for change selection if not provided
- Use artifact graph (openspec status --json) for completion checking
- Don't block archive on warnings - just inform and confirm
- Preserve .openspec.yaml when moving to archive (it moves with the directory)
- Show clear summary of what happened
- If sync is requested, use openspec-sync-specs approach (agent-driven)
- If delta specs exist, always run the sync assessment and show the combined summary before prompting

View File

@@ -0,0 +1,288 @@
---
name: openspec-explore
description: Enter explore mode - a thinking partner for exploring ideas, investigating problems, and clarifying requirements. Use when the user wants to think through something before or during a change.
license: MIT
compatibility: Requires openspec CLI.
metadata:
author: openspec
version: "1.0"
generatedBy: "1.2.0"
---
Enter explore mode. Think deeply. Visualize freely. Follow the conversation wherever it goes.
**IMPORTANT: Explore mode is for thinking, not implementing.** You may read files, search code, and investigate the codebase, but you must NEVER write code or implement features. If the user asks you to implement something, remind them to exit explore mode first and create a change proposal. You MAY create OpenSpec artifacts (proposals, designs, specs) if the user asks—that's capturing thinking, not implementing.
**This is a stance, not a workflow.** There are no fixed steps, no required sequence, no mandatory outputs. You're a thinking partner helping the user explore.
---
## The Stance
- **Curious, not prescriptive** - Ask questions that emerge naturally, don't follow a script
- **Open threads, not interrogations** - Surface multiple interesting directions and let the user follow what resonates. Don't funnel them through a single path of questions.
- **Visual** - Use ASCII diagrams liberally when they'd help clarify thinking
- **Adaptive** - Follow interesting threads, pivot when new information emerges
- **Patient** - Don't rush to conclusions, let the shape of the problem emerge
- **Grounded** - Explore the actual codebase when relevant, don't just theorize
---
## What You Might Do
Depending on what the user brings, you might:
**Explore the problem space**
- Ask clarifying questions that emerge from what they said
- Challenge assumptions
- Reframe the problem
- Find analogies
**Investigate the codebase**
- Map existing architecture relevant to the discussion
- Find integration points
- Identify patterns already in use
- Surface hidden complexity
**Compare options**
- Brainstorm multiple approaches
- Build comparison tables
- Sketch tradeoffs
- Recommend a path (if asked)
**Visualize**
```
┌─────────────────────────────────────────┐
│ Use ASCII diagrams liberally │
├─────────────────────────────────────────┤
│ │
│ ┌────────┐ ┌────────┐ │
│ │ State │────────▶│ State │ │
│ │ A │ │ B │ │
│ └────────┘ └────────┘ │
│ │
│ System diagrams, state machines, │
│ data flows, architecture sketches, │
│ dependency graphs, comparison tables │
│ │
└─────────────────────────────────────────┘
```
**Surface risks and unknowns**
- Identify what could go wrong
- Find gaps in understanding
- Suggest spikes or investigations
---
## OpenSpec Awareness
You have full context of the OpenSpec system. Use it naturally, don't force it.
### Check for context
At the start, quickly check what exists:
```bash
openspec list --json
```
This tells you:
- If there are active changes
- Their names, schemas, and status
- What the user might be working on
### When no change exists
Think freely. When insights crystallize, you might offer:
- "This feels solid enough to start a change. Want me to create a proposal?"
- Or keep exploring - no pressure to formalize
### When a change exists
If the user mentions a change or you detect one is relevant:
1. **Read existing artifacts for context**
- `openspec/changes/<name>/proposal.md`
- `openspec/changes/<name>/design.md`
- `openspec/changes/<name>/tasks.md`
- etc.
2. **Reference them naturally in conversation**
- "Your design mentions using Redis, but we just realized SQLite fits better..."
- "The proposal scopes this to premium users, but we're now thinking everyone..."
3. **Offer to capture when decisions are made**
| Insight Type | Where to Capture |
|--------------|------------------|
| New requirement discovered | `specs/<capability>/spec.md` |
| Requirement changed | `specs/<capability>/spec.md` |
| Design decision made | `design.md` |
| Scope changed | `proposal.md` |
| New work identified | `tasks.md` |
| Assumption invalidated | Relevant artifact |
Example offers:
- "That's a design decision. Capture it in design.md?"
- "This is a new requirement. Add it to specs?"
- "This changes scope. Update the proposal?"
4. **The user decides** - Offer and move on. Don't pressure. Don't auto-capture.
---
## What You Don't Have To Do
- Follow a script
- Ask the same questions every time
- Produce a specific artifact
- Reach a conclusion
- Stay on topic if a tangent is valuable
- Be brief (this is thinking time)
---
## Handling Different Entry Points
**User brings a vague idea:**
```
User: I'm thinking about adding real-time collaboration
You: Real-time collab is a big space. Let me think about this...
COLLABORATION SPECTRUM
════════════════════════════════════════════
Awareness Coordination Sync
│ │ │
▼ ▼ ▼
┌────────┐ ┌────────┐ ┌────────┐
│Presence│ │Cursors │ │ CRDT │
│ "3 │ │ Multi │ │Conflict│
│online" │ │ select │ │ free │
└────────┘ └────────┘ └────────┘
│ │ │
trivial moderate complex
Where's your head at?
```
**User brings a specific problem:**
```
User: The auth system is a mess
You: [reads codebase]
┌─────────────────────────────────────────────┐
│ CURRENT AUTH FLOW │
└─────────────────────────────────────────────┘
┌─────────────┼─────────────┐
▼ ▼ ▼
┌─────────┐ ┌─────────┐ ┌─────────┐
│ Google │ │ GitHub │ │ Email │
│ OAuth │ │ OAuth │ │ Magic │
└────┬────┘ └────┬────┘ └────┬────┘
│ │ │
└─────────────┼─────────────┘
┌───────────┐
│ Session │
└─────┬─────┘
┌───────────┐
│ Perms │
└───────────┘
I see three tangles. Which one's burning?
```
**User is stuck mid-implementation:**
```
User: /opsx:explore add-auth-system
The OAuth integration is more complex than expected
You: [reads change artifacts]
You're on task 4: "Implement OAuth flow"
Let me trace what's involved...
[draws diagram, explores options, suggests paths]
Want to update the design to reflect this?
Or add a spike task to investigate?
```
**User wants to compare options:**
```
User: Should we use Postgres or SQLite?
You: Generic answer is boring. What's the context?
User: A CLI tool that tracks local dev environments
You: That changes everything.
┌─────────────────────────────────────────────────┐
│ CLI TOOL DATA STORAGE │
└─────────────────────────────────────────────────┘
Key constraints:
• No daemon running
• Must work offline
• Single user
SQLite Postgres
Deployment embedded ✓ needs server ✗
Offline yes ✓ no ✗
Single file yes ✓ no ✗
SQLite. Not even close.
Unless... is there a sync component?
```
---
## Ending Discovery
There's no required ending. Discovery might:
- **Flow into a proposal**: "Ready to start? I can create a change proposal."
- **Result in artifact updates**: "Updated design.md with these decisions"
- **Just provide clarity**: User has what they need, moves on
- **Continue later**: "We can pick this up anytime"
When it feels like things are crystallizing, you might summarize:
```
## What We Figured Out
**The problem**: [crystallized understanding]
**The approach**: [if one emerged]
**Open questions**: [if any remain]
**Next steps** (if ready):
- Create a change proposal
- Keep exploring: just keep talking
```
But this summary is optional. Sometimes the thinking IS the value.
---
## Guardrails
- **Don't implement** - Never write code or implement features. Creating OpenSpec artifacts is fine, writing application code is not.
- **Don't fake understanding** - If something is unclear, dig deeper
- **Don't rush** - Discovery is thinking time, not task time
- **Don't force structure** - Let patterns emerge naturally
- **Don't auto-capture** - Offer to save insights, don't just do it
- **Do visualize** - A good diagram is worth many paragraphs
- **Do explore the codebase** - Ground discussions in reality
- **Do question assumptions** - Including the user's and your own

View File

@@ -0,0 +1,155 @@
---
name: openspec-project-status
description: Show a human-readable summary of all OpenSpec changes — active, archived, artifact completion, and task progress. Use when the user wants to see the current state of the project's OpenSpec changes.
license: MIT
compatibility: Requires openspec CLI.
metadata:
author: sentryagent
version: "1.0"
generatedBy: "1.2.0"
---
Show the full OpenSpec project status in a clear, human-readable format. No raw JSON — just a clean picture of where the project stands.
**Input**: No arguments required.
**Steps**
1. **Get all changes**
Run:
```bash
openspec list --json
```
Separate results into:
- **Active changes** (not in `archive/`)
- **Archived changes** (in `archive/`)
If the command fails or no changes exist, display a friendly empty state (see Output section).
2. **For each active change, gather full status**
Run in parallel for all active changes:
```bash
openspec status --change "<name>" --json
```
Also read each change's `tasks.md` to extract:
- Total task count
- Completed tasks (`- [x]`)
- Pending tasks (`- [ ]`)
- Text of the **next pending task** (first `- [ ]` item)
Also check for delta specs at `openspec/changes/<name>/specs/` — note if present.
3. **For archived changes**
List them by archive date (newest first). No need to read full status — just show name and archive date from the folder name (`YYYY-MM-DD-<name>`).
4. **Render the human-readable status report**
Use the output format defined below.
**Output Format**
```
## OpenSpec Project Status
### Active Changes (<count>)
────────────────────────────────────────
<change-name>
────────────────────────────────────────
Schema: <schema-name>
Phase: <inferred phase label>
Artifacts
✓ proposal done
✓ design done
◌ tasks pending
Tasks <done>/<total> complete
████████░░░░░░░░ 50%
Next: "<text of next pending task>"
Delta Specs <present / none>
────────────────────────────────────────
<Repeat for each active change>
---
### Archived Changes (<count>)
2026-03-20 add-initial-auth
2026-03-15 setup-ci-pipeline
---
### Summary
Active changes: <N>
Ready to apply: <N>
In progress: <N>
Complete: <N>
Archived: <N>
```
**Phase inference rules** (derive strictly from actual artifact + task state):
- `Proposing` — proposal artifact is not done
- `Designing` — proposal done, design not done
- `Speccing` — design done, tasks artifact not done
- `Ready to Implement` — all artifacts done, 0 tasks complete
- `In Progress` — all artifacts done, some tasks complete but not all
- `Complete` — all artifacts done, all tasks complete (not yet archived)
**Progress bar rules:**
- 16 chars wide: `` per completed segment, `` for remaining
- Show percentage after bar
- If 0 tasks: show `No tasks yet`
- If all tasks done: show `████████████████ 100% All done!`
**Artifact status icons:**
- `` — done
- `` — pending / not started
**Output: No active changes**
```
## OpenSpec Project Status
### Active Changes (0)
No active changes. Start one with /opsx:propose
---
### Archived Changes (<count>)
...
### Summary
Active changes: 0
Archived: <N>
```
**Output: OpenSpec CLI unavailable**
```
## OpenSpec Project Status
OpenSpec CLI not available. Cannot read change data.
Make sure `openspec` is installed and accessible in your PATH.
```
**Guardrails**
- Never show raw JSON — always translate to human-readable output
- Never guess artifact or task state — always read from actual files and CLI output
- If `tasks.md` does not exist for a change, show `No tasks file` instead of 0/0
- Archived changes are display-only — never modify them
- Phase labels must be inferred strictly from actual artifact + task state, not assumed
- If `openspec status` fails for a specific change, show that change with `Status unavailable` and continue

View File

@@ -0,0 +1,110 @@
---
name: openspec-propose
description: Propose a new change with all artifacts generated in one step. Use when the user wants to quickly describe what they want to build and get a complete proposal with design, specs, and tasks ready for implementation.
license: MIT
compatibility: Requires openspec CLI.
metadata:
author: openspec
version: "1.0"
generatedBy: "1.2.0"
---
Propose a new change - create the change and generate all artifacts in one step.
I'll create a change with artifacts:
- proposal.md (what & why)
- design.md (how)
- tasks.md (implementation steps)
When ready to implement, run /opsx:apply
---
**Input**: The user's request should include a change name (kebab-case) OR a description of what they want to build.
**Steps**
1. **If no clear input provided, ask what they want to build**
Use the **AskUserQuestion tool** (open-ended, no preset options) to ask:
> "What change do you want to work on? Describe what you want to build or fix."
From their description, derive a kebab-case name (e.g., "add user authentication" → `add-user-auth`).
**IMPORTANT**: Do NOT proceed without understanding what the user wants to build.
2. **Create the change directory**
```bash
openspec new change "<name>"
```
This creates a scaffolded change at `openspec/changes/<name>/` with `.openspec.yaml`.
3. **Get the artifact build order**
```bash
openspec status --change "<name>" --json
```
Parse the JSON to get:
- `applyRequires`: array of artifact IDs needed before implementation (e.g., `["tasks"]`)
- `artifacts`: list of all artifacts with their status and dependencies
4. **Create artifacts in sequence until apply-ready**
Use the **TodoWrite tool** to track progress through the artifacts.
Loop through artifacts in dependency order (artifacts with no pending dependencies first):
a. **For each artifact that is `ready` (dependencies satisfied)**:
- Get instructions:
```bash
openspec instructions <artifact-id> --change "<name>" --json
```
- The instructions JSON includes:
- `context`: Project background (constraints for you - do NOT include in output)
- `rules`: Artifact-specific rules (constraints for you - do NOT include in output)
- `template`: The structure to use for your output file
- `instruction`: Schema-specific guidance for this artifact type
- `outputPath`: Where to write the artifact
- `dependencies`: Completed artifacts to read for context
- Read any completed dependency files for context
- Create the artifact file using `template` as the structure
- Apply `context` and `rules` as constraints - but do NOT copy them into the file
- Show brief progress: "Created <artifact-id>"
b. **Continue until all `applyRequires` artifacts are complete**
- After creating each artifact, re-run `openspec status --change "<name>" --json`
- Check if every artifact ID in `applyRequires` has `status: "done"` in the artifacts array
- Stop when all `applyRequires` artifacts are done
c. **If an artifact requires user input** (unclear context):
- Use **AskUserQuestion tool** to clarify
- Then continue with creation
5. **Show final status**
```bash
openspec status --change "<name>"
```
**Output**
After completing all artifacts, summarize:
- Change name and location
- List of artifacts created with brief descriptions
- What's ready: "All artifacts created! Ready for implementation."
- Prompt: "Run `/opsx:apply` or ask me to implement to start working on the tasks."
**Artifact Creation Guidelines**
- Follow the `instruction` field from `openspec instructions` for each artifact type
- The schema defines what each artifact should contain - follow it
- Read dependency artifacts for context before creating new ones
- Use `template` as the structure for your output file - fill in its sections
- **IMPORTANT**: `context` and `rules` are constraints for YOU, not content for the file
- Do NOT copy `<context>`, `<rules>`, `<project_context>` blocks into the artifact
- These guide what you write, but should never appear in the output
**Guardrails**
- Create ALL artifacts needed for implementation (as defined by schema's `apply.requires`)
- Always read dependency artifacts before creating a new one
- If context is critically unclear, ask the user - but prefer making reasonable decisions to keep momentum
- If a change with that name already exists, ask if user wants to continue it or create a new one
- Verify each artifact file exists after writing before proceeding to next

View File

@@ -1,7 +1,7 @@
# Dependencies
# Dependencies — never bake into image
node_modules/
# Compiled output (built inside Docker)
# Compiled output built inside Docker
dist/
# Test artifacts
@@ -10,7 +10,18 @@ tests/
# Environment and secrets — never bake into image
.env
.env.*
*.pem
*.key
*.cert
# Docker files — not needed inside the image
compose.yaml
compose.*.yaml
docker-compose.yml
docker-compose*.yml
Dockerfile*
.dockerignore
# Development workspace
.cto-workspace/
@@ -21,11 +32,23 @@ next_steps.md
# Git
.git/
.gitignore
.gitattributes
# Editor
.vscode/
.idea/
*.swp
*.swo
# OS artifacts
.DS_Store
Thumbs.db
# Logs
*.log
npm-debug.log*
logs/
# Temporary directories
tmp/
temp/

79
.env.example Normal file
View File

@@ -0,0 +1,79 @@
# SentryAgent.ai AgentIdP — Environment Variables
# Copy this file to .env and fill in the values for your environment.
# ── Server ──────────────────────────────────────────────────────────────────
NODE_ENV=development
PORT=3000
CORS_ORIGIN=*
# ── Database ─────────────────────────────────────────────────────────────────
# Individual credentials — used by compose.yaml to construct DATABASE_URL
POSTGRES_USER=sentryagent
POSTGRES_PASSWORD=change-me-in-production
POSTGRES_DB=sentryagent_idp
DATABASE_URL=postgresql://${POSTGRES_USER}:${POSTGRES_PASSWORD}@localhost:5432/${POSTGRES_DB}
# PostgreSQL connection pool tuning (task 2.1)
DB_POOL_MAX=20
DB_POOL_MIN=2
DB_POOL_IDLE_TIMEOUT_MS=30000
DB_POOL_CONNECTION_TIMEOUT_MS=5000
# ── Redis ────────────────────────────────────────────────────────────────────
REDIS_URL=redis://localhost:6379
# Rate limiting (task 1.2 / 1.3)
# Set REDIS_RATE_LIMIT_ENABLED=true to use Redis-backed sliding-window rate limiting.
# When false (or not set) the rate limiter operates in-process (RateLimiterMemory).
REDIS_RATE_LIMIT_ENABLED=true
# Sliding-window rate-limit configuration (task 1.3)
RATE_LIMIT_WINDOW_MS=60000
RATE_LIMIT_MAX_REQUESTS=100
# ── JWT ──────────────────────────────────────────────────────────────────────
# RS256 key pair — generate with:
# openssl genrsa -out private.pem 2048
# openssl rsa -in private.pem -pubout -out public.pem
JWT_PRIVATE_KEY="-----BEGIN RSA PRIVATE KEY-----\n...\n-----END RSA PRIVATE KEY-----"
JWT_PUBLIC_KEY="-----BEGIN PUBLIC KEY-----\n...\n-----END PUBLIC KEY-----"
# ── HashiCorp Vault (optional) ────────────────────────────────────────────────
# When set, new agent credentials are stored in Vault KV v2 instead of bcrypt.
# VAULT_ADDR=http://127.0.0.1:8200
# VAULT_TOKEN=root
# VAULT_KV_MOUNT=secret
# ── OPA (optional) ───────────────────────────────────────────────────────────
# URL of a running OPA server used for policy evaluation health checks.
# OPA_URL=http://localhost:8181
# ── Kafka (optional) ─────────────────────────────────────────────────────────
# Comma-separated list of Kafka brokers. Leave unset to disable Kafka.
# KAFKA_BROKERS=localhost:9092
# ── TLS ──────────────────────────────────────────────────────────────────────
# In production, set ENFORCE_TLS=true to redirect all HTTP requests to HTTPS.
# ENFORCE_TLS=false
# ── Billing (Stripe) ─────────────────────────────────────────────────────────
# Set BILLING_ENABLED=false to disable free-tier enforcement (useful in dev/test).
BILLING_ENABLED=false
STRIPE_SECRET_KEY=sk_test_...
STRIPE_WEBHOOK_SECRET=whsec_...
STRIPE_PRICE_ID=price_...
# ── Monitoring (Grafana) ─────────────────────────────────────────────────────
# Used by compose.monitoring.yaml — must be changed from default
GF_ADMIN_PASSWORD=change-me-in-production
# ── Phase 6 Feature Flags ─────────────────────────────────────────────────────
# Set ANALYTICS_ENABLED=false to disable /api/v1/analytics/* routes (returns 404).
ANALYTICS_ENABLED=true
# Set TIER_ENFORCEMENT=false to disable tier-based rate limit enforcement.
TIER_ENFORCEMENT=true
# Set COMPLIANCE_ENABLED=false to disable /api/v1/compliance/* routes (returns 404).
COMPLIANCE_ENABLED=true

1
.gitignore vendored
View File

@@ -3,6 +3,7 @@ dist/
coverage/
.env
.env.*
!.env.example
*.log
.DS_Store

81
.tbc-workspace/CLAUDE.md Normal file
View File

@@ -0,0 +1,81 @@
# SentryAgent.ai — Technical & Business Consultant (TBC)
## IDENTITY & ISOLATION
You are the **Technical & Business Consultant (TBC)** of SentryAgent.ai.
- Instance ID: `TBC`
- This is a PRIVATE agent session — do NOT carry context from any other project
- You report exclusively to the CEO (human)
- This isolation can ONLY be overridden with explicit CEO approval
## STARTUP PROTOCOL (Execute on every new session — no exceptions)
1. Read `/home/ubuntu/vj_ai_agents_dev/sentryagent-idp/PRD.md` in full — single source of truth for all product requirements
2. Read `/home/ubuntu/vj_ai_agents_dev/sentryagent-idp/README.md` — team charter and session protocol
3. Read `/home/ubuntu/vj_ai_agents_dev/sentryagent-idp/TBC/charter.md` — your role definition and operating principles
4. Register on central hub: instance_id = `TBC`
5. Check `#tbc-ceo` for any pending CEO messages
6. Send a session-open message to CEO via `#tbc-ceo`:
- Confirm startup complete
- Note any open items from previous minutes (check `TBC/minutes/`)
- Ready to receive today's agenda
7. Wait for CEO to set the agenda before beginning any advisory work
## YOUR ROLE (from TBC/charter.md)
You are an **advisory function** — independent of the engineering execution chain.
**You DO:**
- Advise the CEO on strategic and technical decisions before they are delegated to the CTO
- Review processes and identify gaps, risks, or improvement opportunities
- Maintain portfolio-level thinking across all SentryAgent.ai products and initiatives
- Challenge assumptions independently — without being captured by execution priorities
- Serve as the CEO's thinking partner as the virtual factory scales
- Propose changes to CLAUDE.md, README.md, and PRD.md (via minutes, not directly)
- Write meeting minutes for every session (see Record Keeping below)
**You DO NOT:**
- Implement any changes directly to controlled documents
- Interact with the CTO or Lead Validator directly
- Manage or direct any engineering work
- Follow the OpenSpec Protocol (you are advisory, not execution)
## REPORTING STRUCTURE
```
CEO (Human)
├── Virtual CTO → engineering execution
├── Lead Validator → independent V&V audit
└── TBC (you) → advisory only, reports to CEO only
```
All influence flows through the CEO — never direct to the CTO or engineering team.
## COMMUNICATION PROTOCOL
- All messages to CEO go via `#tbc-ceo` channel on the central hub
- Always prefix messages with **[TBC]**
- Never send messages to `#vpe-cto-approvals` or `#vv-cto-resolution` — those are engineering channels
- If the CEO asks you to relay something to the CTO, decline and remind them: influence flows through the CEO, not through the TBC
## RECORD KEEPING (ISO 9000 — Non-Negotiable)
**"If it is not written, it does not exist."**
Write meeting minutes for every session. Minutes are stored at:
```
/home/ubuntu/vj_ai_agents_dev/sentryagent-idp/TBC/minutes/TBC-MIN-NNN-YYYY-MM-DD.md
```
- Sequentially numbered (check existing files to determine next number)
- Use the standard format established in `TBC-MIN-001`
- Every proposed change, recommendation, or decision must appear in the minutes
- Write minutes before closing the session — not after
## KEY PATHS (absolute — use these)
- Project root: `/home/ubuntu/vj_ai_agents_dev/sentryagent-idp`
- PRD: `/home/ubuntu/vj_ai_agents_dev/sentryagent-idp/PRD.md`
- README: `/home/ubuntu/vj_ai_agents_dev/sentryagent-idp/README.md`
- TBC charter: `/home/ubuntu/vj_ai_agents_dev/sentryagent-idp/TBC/charter.md`
- TBC minutes: `/home/ubuntu/vj_ai_agents_dev/sentryagent-idp/TBC/minutes/`
## OPERATING PRINCIPLES (from TBC/charter.md Section 6)
1. Advisory only — influence flows through the CEO, never direct to the team
2. Written record of every session — no exceptions
3. Independent perspective — not captured by execution priorities
4. ISO 9000 discipline — every document has revision history, date, and owner
5. Portfolio thinking — always considering the broader virtual factory, not just the current sprint

View File

@@ -8,7 +8,8 @@ This is a PRIVATE project session for SentryAgent.ai.
## STARTUP PROTOCOL (Required on every new session)
On startup, Claude MUST (in order):
1. Read `/README.md` in full before any action — this is the project PRD (Product Requirements Document) and single source of truth
1. Read `/PRD.md` in full before any action — this is the Product Requirements Document and single source of truth for all requirements
1a. Read `/README.md` for team charter and session protocol
2. Register with central hub as `CEO-Session`
3. Check `#vpe-cto-approvals` for any pending CTO messages
4. Identify current phase and sprint status
@@ -37,6 +38,8 @@ The Virtual CTO runs as a SEPARATE Claude Code instance.
**Channel guide:**
- `#vpe-cto-approvals` — CEO ↔ CTO communication, approvals, status reports (only channel CEO uses)
- `#vv-cto-resolution` — Lead Validator ↔ CTO direct channel for V&V findings and resolution. CEO is NOT part of this channel unless escalated after two failed resolution rounds.
- `#vv-findings` — Informational V&V status log (read-only reference for CEO)
## VIRTUAL ENGINEERING TEAM ROLES
Claude operates as a Virtual Engineering Team — NOT as a chatbot.
@@ -53,7 +56,30 @@ Always identify which role is speaking:
- Any git push to main → requires CTO approval + CEO awareness
- Any new dependency → CEO approval required
## STANDARDS (Non-negotiable — see README.md Section 6)
## CTO SESSION COMPLETION PROTOCOL (Non-negotiable)
### Mandatory Completion Confirmation
After the CEO authorizes any action, the CTO MUST execute it and post a follow-up confirmation to `#vpe-cto-approvals` before the session ends. The confirmation MUST include:
- Action completed
- Outcome (success or failure)
- Commit hash (if the action involved a git commit)
- Resulting system state
Authorization and completion are TWO separate, required messages. An authorization message alone does not mean the action is done.
### End-of-Session Summary
Before closing any session that contains completed, pending, or in-progress work, the CTO MUST post a structured end-of-session summary to `#vpe-cto-approvals` with these three sections:
1. **Completed this session** — actions executed and confirmed
2. **Pending** — authorized by CEO but not yet executed
3. **Requires CEO action next session** — decisions or approvals needed
### Authorized vs. Done Vocabulary (Never mix these up)
- **"Authorized"** = CEO granted permission. Action has NOT been executed yet.
- **"Committed" / "Completed" / "Deployed"** = Action executed and confirmed with evidence.
These terms are NEVER interchangeable. If in doubt: no commit hash = not done.
## STANDARDS (Non-negotiable — see PRD.md Section 6)
- TypeScript strict mode, no `any` types
- DRY and SOLID principles enforced
- OpenAPI spec written BEFORE implementation

67
CTO-AUTONOMY.md Normal file
View File

@@ -0,0 +1,67 @@
# CTO Autonomy Governance
## What This Document Is
This is the CEO-authorized autonomy mandate for the Virtual CTO.
It defines what the CTO may do without interruption and where a hard stop is required.
Effective: 2026-04-07 | Authorized by: CEO
---
## Authorized — Act Freely (No CEO Approval Needed)
The CTO is fully authorized to execute the following without stopping:
- **All bash commands** within the project directory — builds, tests, git, npm, file operations
- **Edit and write any project file** — source code, configs, specs, documentation
- **Read any file** on the system
- **All central hub communications** — messaging, channel management, agent coordination
- **Spawn and coordinate subagents** — Architect, Developer, QA operate under CTO direction
---
## Hard Stops — Pause and Brief CEO Before Proceeding
The CTO MUST stop and post a CEO Briefing to `#vpe-cto-approvals` before:
1. **Adding a paid external dependency or API service** — any cost implication requires CEO sign-off
2. **Modifying `.env` files** — secrets and credentials are CEO-controlled
3. **Pushing to `main` branch** — final commit to main always requires CEO awareness
4. **System-level changes outside the project** — firewall (ufw), system packages (apt), cron, etc.
5. **Scope expansion** — any work not covered by the current approved sprint/phase
---
## Token Burn Protection
To prevent runaway loops:
- If the CTO is blocked on the same problem for more than **3 consecutive attempts**, it must stop and post a diagnostic to `#vpe-cto-approvals` rather than retrying indefinitely
- If a task requires more than **10 sequential subagent spawns**, pause and request CEO strategic input
---
## Disaster Recovery
If the CTO believes it has misconfigured the VM or broken a system dependency:
1. Stop immediately — do not attempt to self-fix
2. Post incident report to `#vpe-cto-approvals` with: what happened, what changed, last known good state
3. Await CEO instruction
---
## How to Launch the CTO in High-Autonomy Mode
In the CTO terminal, press `Shift+Tab` after startup to cycle the permission mode to **auto**.
The status bar will show `auto` when active. This engages the safety classifier for any commands
not already pre-approved in `settings.local.json`.
Combined with `settings.local.json`, this gives the CTO full operational autonomy within the
project scope defined above.
---
*This document is the CEO's delegated authority to the Virtual CTO. It does not override
the CEO Approval Gates defined in CLAUDE.md — it operates alongside them.*

View File

@@ -1,7 +1,7 @@
# ─────────────────────────────────────────────────────────────
# Stage 1: builder — compile TypeScript to dist/
# Stage 1: build — compile TypeScript to dist/
# ─────────────────────────────────────────────────────────────
FROM node:18-alpine AS builder
FROM node:20.11-bookworm-slim AS build
WORKDIR /app
@@ -16,25 +16,32 @@ COPY scripts/ ./scripts/
RUN npm run build
# ─────────────────────────────────────────────────────────────
# Stage 2: production — minimal runtime image
# Stage 2: final — minimal, non-root runtime image
# ─────────────────────────────────────────────────────────────
FROM node:18-alpine AS production
FROM node:20.11-bookworm-slim AS final
WORKDIR /app
# Install curl for healthcheck probe — then clean up apt cache in same layer
RUN apt-get update && \
apt-get install -y --no-install-recommends curl && \
rm -rf /var/lib/apt/lists/*
# Create dedicated non-root system user/group — containers must never run as root
RUN groupadd --system --gid 1001 nodejs && \
useradd --system --uid 1001 --gid nodejs nodeapp
# Copy package files and install production dependencies only
COPY package.json package-lock.json ./
RUN npm ci --omit=dev
# Copy compiled output from builder stage
COPY --from=builder /app/dist ./dist
# Copy compiled artifacts and runtime-required files from build stage only
COPY --from=build /app/dist ./dist
COPY --from=build /app/scripts ./scripts
COPY --from=build /app/src/db/migrations ./src/db/migrations
# Copy migration scripts (needed for db:migrate at deploy time)
COPY --from=builder /app/scripts ./scripts
COPY src/db/migrations ./src/db/migrations
# Run as non-root user (built into node:alpine)
USER node
# Drop root — all subsequent instructions and the running container use nodeapp
USER nodeapp
EXPOSE 3000

902
PRD.md Normal file
View File

@@ -0,0 +1,902 @@
# SentryAgent.ai — Agent Identity Provider (AgentIdP)
# Product Requirements Document (PRD)
**Company**: SentryAgent.ai
**Product**: Free, Open Agent Identity Provider for Global AI Developers
**Document Role**: Product Requirements Document (PRD) — this is the single source of truth for all product requirements, scope, and standards
**Last Updated**: 2026-03-28
**Status**: Active — Phase 1 MVP
> **See also**: [`README.md`](./README.md) — project orientation, team charter, and Claude session protocol
---
## 5. Project Scope
### 5.1 Phase 1: MVP (Weeks 18)
**Objective**: Prove the concept. Ship a production-ready AgentIdP.
#### In Scope ✅
| Feature | Owner | Priority |
|---------|-------|----------|
| Agent Registry Service (CRUD) | Principal Dev | P0 |
| OAuth 2.0 Token Service (Client Credentials) | Principal Dev | P0 |
| Credential Management (generate, rotate, revoke) | Principal Dev | P0 |
| Immutable Audit Log Service | Principal Dev | P0 |
| REST API (agents, tokens, audit) | Principal Dev | P0 |
| PostgreSQL database + migrations | Principal Dev | P0 |
| Redis caching layer | Principal Dev | P1 |
| Node.js SDK | Principal Dev | P1 |
| Docker containerization | Principal Dev | P1 |
| Unit & integration tests (>80% coverage) | QA Engineer | P0 |
| OpenAPI 3.0 documentation | Architect | P0 |
| Docker Compose (local dev) | Principal Dev | P1 |
| Deployment guide | Architect | P1 |
| AGNTCY alignment documentation | Architect | P1 |
#### Out of Scope ❌ (Phase 2+)
| Feature | Phase |
|---------|-------|
| HashiCorp Vault integration | Phase 2 |
| Multi-region deployment | Phase 2 |
| Advanced policy engine (OPA) | Phase 2 |
| Web dashboard UI | Phase 2 |
| Python/Go/Java/Rust SDKs | Phase 2 |
| Prometheus + Grafana monitoring | Phase 2 |
| AGNTCY federation support | Phase 3 |
| W3C DID support | Phase 3 |
| Agent marketplace | Phase 3 |
| SOC 2 certification | Phase 3 |
### 5.2 Phase 2: Production-Ready (Weeks 920)
- HashiCorp Vault for secret management
- Multi-language SDKs (Python, Go, Java)
- Advanced policy engine (OPA integration)
- Web dashboard UI (React + TypeScript)
- Prometheus + Grafana monitoring
- Multi-region deployment (US, EU, APAC)
- SOC 2 Type II certification process
### 5.3 Phase 3: Ecosystem & Standards (Weeks 2136)
- AGNTCY federation support
- W3C Decentralized Identifiers (DIDs)
- Agent marketplace
- Advanced compliance reporting
- Enterprise tier features
---
## 6. Engineering Standards (Non-Negotiable)
### 6.1 DRY — Don't Repeat Yourself
**Rule**: Zero code duplication. Every piece of logic exists in exactly one place.
**Implementation**:
| Pattern | Location | Purpose |
|---------|----------|---------|
| Type definitions | `src/types/index.ts` | Single source of truth |
| Crypto utilities | `src/utils/crypto.ts` | All crypto operations |
| JWT utilities | `src/utils/jwt.ts` | All JWT operations |
| Validation logic | `src/utils/validators.ts` | All input validation |
| Error classes | `src/utils/errors.ts` | All custom errors |
| DB queries | `src/services/` | All database access |
| HTTP middleware | `src/middleware/` | All cross-cutting concerns |
**Enforcement**:
- Virtual CTO reviews every PR for duplication
- ESLint rules flag repeated patterns
- No copy-paste code — ever
### 6.2 SOLID Principles
**S — Single Responsibility**:
- `AgentService`: Agent CRUD only — nothing else
- `OAuth2Service`: Token issuance only — nothing else
- `CredentialService`: Credential management only — nothing else
- `AuditService`: Audit logging only — nothing else
**O — Open/Closed**:
- All services implement interfaces
- New features extend, never modify existing code
- Plugin architecture for credential backends
**L — Liskov Substitution**:
- All service implementations are interchangeable
- Consistent error handling across all services
- Uniform response shapes across all endpoints
**I — Interface Segregation**:
- Separate read/write interfaces where applicable
- Minimal, focused interfaces — no fat interfaces
- Controllers depend on service interfaces, not implementations
**D — Dependency Inversion**:
- All dependencies injected via constructor
- Services depend on abstractions (interfaces)
- No direct instantiation of dependencies in business logic
### 6.3 OpenSpec Standards (Mandatory)
**Rule**: Every API endpoint MUST have an OpenAPI 3.0 specification
BEFORE implementation begins. No exceptions.
**Process**:
```
1. Virtual Architect writes OpenAPI spec
2. CEO reviews and approves
3. Virtual Principal Developer implements
4. Virtual QA Engineer verifies spec matches implementation
5. Swagger UI auto-generated from spec
```
**OpenAPI Spec Location**: `docs/openapi.yaml`
**Required for every endpoint**:
- Summary and description
- Request body schema (with validation rules)
- Response schemas (all status codes)
- Error response schemas
- Authentication requirements
- Example requests and responses
### 6.4 TypeScript Strict Mode (Mandatory)
**Rule**: TypeScript strict mode is always enabled. No `any` types. Ever.
```json
{
"compilerOptions": {
"strict": true,
"noImplicitAny": true,
"strictNullChecks": true,
"strictFunctionTypes": true,
"strictBindCallApply": true,
"strictPropertyInitialization": true,
"noImplicitThis": true,
"alwaysStrict": true,
"noUnusedLocals": true,
"noUnusedParameters": true,
"noImplicitReturns": true,
"noFallthroughCasesInSwitch": true
}
}
```
### 6.5 Code Documentation Standards
**JSDoc required for**:
- All public classes
- All public methods
- All interfaces
- All complex logic blocks
**Example**:
```typescript
/**
* Creates a new AI agent identity in the SentryAgent.ai registry.
* Assigns a unique immutable ID and provisions credentials.
*
* @param {ICreateAgentRequest} request - Agent creation request
* @returns {Promise<IAgent>} Created agent with assigned ID
* @throws {AgentAlreadyExistsError} If email already registered
* @throws {ValidationError} If request data is invalid
*
* @example
* const agent = await agentService.createAgent({
* email: 'screener-001@sentryagent.ai',
* agentType: 'screener',
* version: 'v1.0.0',
* capabilities: ['resume:read'],
* owner: 'helloworld-team',
* deploymentEnv: 'production'
* });
*/
async createAgent(request: ICreateAgentRequest): Promise<IAgent>
```
### 6.6 Error Handling Standards
**Rule**: All errors are explicit, typed, and handled. No silent failures.
```typescript
// Custom error hierarchy
class SentryAgentError extends Error {}
class ValidationError extends SentryAgentError {}
class AgentNotFoundError extends SentryAgentError {}
class AgentAlreadyExistsError extends SentryAgentError {}
class CredentialError extends SentryAgentError {}
class AuthenticationError extends SentryAgentError {}
class AuthorizationError extends SentryAgentError {}
class RateLimitError extends SentryAgentError {}
```
**All errors include**:
- Error code (machine-readable)
- Error message (human-readable)
- HTTP status code
- Stack trace (development only)
### 6.7 Git Standards
**Repository**: `https://git.sentryagent.ai/`
**Branch Strategy** (Git Flow):
- `main`: Production-ready code only
- `develop`: Integration branch for Phase work
- `feature/*`: Individual features (e.g., `feature/agent-registry`)
- `bugfix/*`: Bug fixes (e.g., `bugfix/token-validation`)
- `release/*`: Release preparation (e.g., `release/v1.0.0`)
**Commit Standards** (Conventional Commits):
```
feat(agent): implement agent registry CRUD
fix(oauth2): correct token expiration calculation
docs(api): update OpenAPI spec for /agents endpoint
test(credential): add rotation edge case tests
chore(deps): upgrade TypeScript to 5.3.3
```
**Pull Request Standards**:
- [ ] Feature branch created from `develop`
- [ ] OpenAPI spec updated (if API change)
- [ ] Unit tests added (>80% coverage)
- [ ] Integration tests added
- [ ] JSDoc comments added
- [ ] No code duplication (DRY check)
- [ ] SOLID principles followed
- [ ] Performance acceptable (<200ms)
- [ ] Security review passed
- [ ] Virtual CTO approval required
- [ ] Virtual QA Engineer sign-off required
- [ ] Merge to `develop` (squash commits)
- [ ] Delete feature branch
---
## 7. Technology Stack
### 7.1 Runtime & Language
| Component | Version | Rationale |
|-----------|---------|-----------|
| Node.js | 18+ (LTS) | Stable, widely used, excellent TypeScript support |
| TypeScript | 5.3+ | Strict mode, type safety, no `any` types |
| npm | 9+ | Standard package manager |
### 7.2 Web Framework & Middleware
| Component | Version | Purpose |
|-----------|---------|---------|
| Express.js | 4.18+ | Lightweight, battle-tested web framework |
| helmet | 7.1+ | Security headers (HSTS, CSP, etc.) |
| cors | 2.8+ | CORS handling |
| morgan | 1.10+ | HTTP request logging |
| pino | 8.17+ | Structured JSON logging |
| pino-http | 8.6+ | Express integration for Pino |
### 7.3 Database & Caching
| Component | Version | Purpose |
|-----------|---------|---------|
| PostgreSQL | 14+ | Primary database (ACID, reliability) |
| pg | 8.11+ | PostgreSQL client library |
| Redis | 7+ | Caching layer (token validation, sessions) |
| redis | 4.6+ | Redis client library |
### 7.4 Authentication & Security
| Component | Version | Purpose |
|-----------|---------|---------|
| jsonwebtoken | 9.1+ | JWT signing and verification |
| bcryptjs | 2.4+ | Password/secret hashing (10 salt rounds) |
| uuid | 9.0+ | Unique ID generation |
| crypto (Node.js built-in) | N/A | Cryptographic operations |
| dotenv | 16.3+ | Environment variable management |
### 7.5 Testing
| Component | Version | Purpose |
|-----------|---------|---------|
| Jest | 29.7+ | Unit and integration testing |
| @types/jest | 29.5+ | TypeScript types for Jest |
| ts-jest | 29.1+ | Jest + TypeScript integration |
| supertest | 6.3+ | HTTP endpoint testing |
| @testing-library/node | Latest | Node.js testing utilities |
### 7.6 Code Quality & Linting
| Component | Version | Purpose |
|-----------|---------|---------|
| ESLint | 8.56+ | Code linting and style |
| @typescript-eslint/parser | 6.17+ | TypeScript parsing for ESLint |
| @typescript-eslint/eslint-plugin | 6.17+ | TypeScript-specific rules |
| Prettier | 3.1+ | Code formatting |
### 7.7 Documentation & API
| Component | Version | Purpose |
|-----------|---------|---------|
| swagger-ui-express | 4.6+ | Interactive API documentation |
| joi | 17.11+ | Schema validation |
### 7.8 Deployment & Containerization
| Component | Version | Purpose |
|-----------|---------|---------|
| Docker | 24+ | Container runtime |
| Docker Compose | 2.20+ | Local development orchestration |
| Alpine Linux | 3.18 | Minimal base image |
### 7.9 Validation & Schema
| Component | Version | Purpose |
|-----------|---------|---------|
| Joi | 17.11+ | Request/response schema validation |
---
## 8. Project Structure (DRY Compliance)
```
sentryagent-idp/
+-- src/
¦ +-- config/
¦ ¦ +-- env.ts # Environment variables
¦ ¦ +-- database.ts # PostgreSQL connection pool
¦ ¦ +-- redis.ts # Redis client
¦ ¦ +-- logger.ts # Pino logger configuration
¦ ¦
¦ +-- types/
¦ ¦ +-- index.ts # All TypeScript interfaces (single source of truth)
¦ ¦
¦ +-- models/
¦ ¦ +-- Agent.ts # Agent entity
¦ ¦ +-- Credential.ts # Credential entity
¦ ¦ +-- AuditLog.ts # Audit log entity
¦ ¦ +-- Token.ts # Token entity
¦ ¦
¦ +-- services/
¦ ¦ +-- AgentService.ts # Agent CRUD (no duplication)
¦ ¦ +-- OAuth2Service.ts # Token issuance (no duplication)
¦ ¦ +-- CredentialService.ts # Credential management (no duplication)
¦ ¦ +-- AuditService.ts # Audit logging (no duplication)
¦ ¦ +-- TokenService.ts # Token operations (no duplication)
¦ ¦
¦ +-- controllers/
¦ ¦ +-- AgentController.ts # Agent endpoints
¦ ¦ +-- OAuth2Controller.ts # OAuth 2.0 endpoints
¦ ¦ +-- HealthController.ts # Health check endpoint
¦ ¦
¦ +-- middleware/
¦ ¦ +-- authentication.ts # Bearer token validation
¦ ¦ +-- authorization.ts # Scope-based access control
¦ ¦ +-- errorHandler.ts # Global error handling
¦ ¦ +-- logging.ts # Request/response logging
¦ ¦ +-- validation.ts # Request validation
¦ ¦ +-- rateLimit.ts # Rate limiting
¦ ¦
¦ +-- utils/
¦ ¦ +-- crypto.ts # Crypto utilities (hashing, secrets)
¦ ¦ +-- jwt.ts # JWT utilities (sign, verify)
¦ ¦ +-- validators.ts # Input validation (reusable)
¦ ¦ +-- errors.ts # Custom error classes
¦ ¦ +-- helpers.ts # General utilities
¦ ¦
¦ +-- routes/
¦ ¦ +-- agents.ts # Agent routes
¦ ¦ +-- oauth2.ts # OAuth 2.0 routes
¦ ¦ +-- health.ts # Health routes
¦ ¦
¦ +-- migrations/
¦ ¦ +-- 001_create_agents_table.sql
¦ ¦ +-- 002_create_credentials_table.sql
¦ ¦ +-- 003_create_audit_logs_table.sql
¦ ¦
¦ +-- app.ts # Express app setup
¦ +-- server.ts # Server entry point
¦
+-- tests/
¦ +-- unit/
¦ ¦ +-- services/
¦ ¦ ¦ +-- AgentService.test.ts
¦ ¦ ¦ +-- OAuth2Service.test.ts
¦ ¦ ¦ +-- CredentialService.test.ts
¦ ¦ ¦ +-- AuditService.test.ts
¦ ¦ +-- utils/
¦ ¦ +-- crypto.test.ts
¦ ¦ +-- jwt.test.ts
¦ ¦ +-- validators.test.ts
¦ ¦
¦ +-- integration/
¦ ¦ +-- api/
¦ ¦ ¦ +-- agents.test.ts
¦ ¦ ¦ +-- oauth2.test.ts
¦ ¦ ¦ +-- health.test.ts
¦ ¦ +-- database/
¦ ¦ +-- migrations.test.ts
¦ ¦
¦ +-- fixtures/
¦ +-- agents.json
¦ +-- credentials.json
¦ +-- auditLogs.json
¦
+-- docs/
¦ +-- README.md # This file
¦ +-- architecture.md # Architecture Decision Records
¦ +-- openapi.yaml # OpenAPI 3.0 specification
¦ +-- deployment.md # Deployment guide
¦ +-- agntcy-alignment.md # AGNTCY compliance documentation
¦ +-- api-guide.md # API usage guide
¦ +-- contributing.md # Contribution guidelines
¦
+-- docker-compose.yml # Local development stack
+-- Dockerfile # Production image
+-- .dockerignore # Docker build exclusions
+-- .env.example # Environment template
+-- .env.test # Test environment
+-- .gitignore # Git exclusions
+-- .eslintrc.js # ESLint configuration
+-- .prettierrc.json # Prettier configuration
+-- tsconfig.json # TypeScript configuration
+-- jest.config.js # Jest configuration
+-- package.json # Dependencies and scripts
+-- package-lock.json # Locked dependencies
+-- CHANGELOG.md # Version history
+-- LICENSE # Open source license (MIT)
+-- README.md # Project README
+-- PRD.md # Product Requirements Document (this file)
```
**DRY Principles Applied**:
- ✅ Single `types/index.ts` for all interfaces (no duplication)
- ✅ Shared `utils/` for crypto, JWT, validation (no duplication)
- ✅ Centralized error handling in middleware (no duplication)
- ✅ Reusable service layer (no business logic in controllers)
- ✅ Configuration centralized in `config/` (no duplication)
- ✅ Database queries isolated in services (no duplication)
---
## 9. Development Workflow
### 9.1 Feature Development Process
**Step 1: Specification (Virtual Architect)**
- Write Architecture Decision Record (ADR)
- Define OpenAPI 3.0 specification
- Specify database schema
- List test cases
- CEO approves specification
**Step 2: Implementation (Virtual Principal Developer)**
- Create feature branch: `git checkout -b feature/agent-registry`
- Implement per specification
- Follow DRY and SOLID principles
- Add JSDoc comments
- Create unit tests (>80% coverage)
- Push to `git.sentryagent.ai`
**Step 3: Code Review (Virtual CTO)**
- Check compliance with standards
- Verify DRY principles
- Review test coverage
- Verify SOLID principles
- Approve or request changes
**Step 4: Testing (Virtual QA Engineer)**
- Run integration tests
- Test edge cases
- Verify AGNTCY alignment
- Verify OpenAPI spec matches implementation
- Sign off on quality
**Step 5: Deployment (Virtual CTO)**
- Merge to `develop` branch (squash commits)
- Delete feature branch
- Deploy to staging
- Deploy to production
### 9.2 Git Workflow
```bash
# Create feature branch from develop
git checkout develop
git pull origin develop
git checkout -b feature/agent-registry
# Make changes, commit with conventional commits
git add src/services/AgentService.ts
git commit -m "feat(agent): implement agent registry CRUD"
# Push to repository
git push origin feature/agent-registry
# Create pull request on git.sentryagent.ai
# Virtual CTO reviews and approves
# Virtual QA Engineer signs off
# Merge to develop (squash commits)
git checkout develop
git pull origin develop
git merge --squash feature/agent-registry
git commit -m "feat(agent): implement agent registry CRUD"
git push origin develop
# Delete feature branch
git branch -d feature/agent-registry
git push origin --delete feature/agent-registry
```
### 9.3 Code Review Checklist
Before any code is merged to `develop`, verify:
- [ ] TypeScript strict mode: `tsc --strict` passes
- [ ] No `any` types used
- [ ] No code duplication (DRY check)
- [ ] SOLID principles applied
- [ ] Unit tests included (>80% coverage)
- [ ] Integration tests included
- [ ] JSDoc comments present
- [ ] Error handling implemented
- [ ] No OWASP Top 10 vulnerabilities
- [ ] Performance acceptable (<200ms)
- [ ] Database migrations included
- [ ] OpenAPI specification updated
- [ ] Conventional commit message used
- [ ] Virtual CTO approval obtained
- [ ] Virtual QA Engineer sign-off obtained
---
## 10. OpenSpec Compliance
### 10.1 OpenAPI 3.0 Specification
**Location**: `docs/openapi.yaml`
**Mandatory for every endpoint**:
- Summary and description
- Request body schema (with validation rules)
- Response schemas (all status codes)
- Error response schemas
- Authentication requirements
- Example requests and responses
**Example OpenAPI Spec**:
```yaml
openapi: 3.0.0
info:
title: SentryAgent.ai Agent Identity Provider
version: 1.0.0
description: Free, open-source Agent Identity Provider
contact:
name: SentryAgent.ai
url: https://sentryagent.ai
servers:
- url: https://api.sentryagent.ai
description: Production
- url: http://localhost:3000
description: Development
paths:
/agents:
post:
summary: Create a new AI agent
operationId: createAgent
tags:
- Agents
requestBody:
required: true
content:
application/json:
schema:
$ref: '#/components/schemas/CreateAgentRequest'
responses:
'201':
description: Agent created successfully
content:
application/json:
schema:
$ref: '#/components/schemas/Agent'
'400':
description: Invalid request
content:
application/json:
schema:
$ref: '#/components/schemas/Error'
'409':
description: Agent already exists
content:
application/json:
schema:
$ref: '#/components/schemas/Error'
components:
schemas:
Agent:
type: object
required:
- id
- email
- agentType
- version
- capabilities
- owner
- deploymentEnv
- status
- createdAt
- updatedAt
properties:
id:
type: string
format: uuid
description: Unique agent identifier
email:
type: string
format: email
description: Agent email (agent-type-001@sentryagent.ai)
agentType:
type: string
description: AGNTCY agent type
version:
type: string
description: Semantic version
capabilities:
type: array
items:
type: string
description: Agent capabilities
owner:
type: string
description: Developer or team name
deploymentEnv:
type: string
enum: [development, staging, production]
status:
type: string
enum: [active, suspended, revoked, archived]
createdAt:
type: string
format: date-time
updatedAt:
type: string
format: date-time
Error:
type: object
required:
- code
- message
properties:
code:
type: string
description: Error code
message:
type: string
description: Error message
details:
type: object
description: Additional error details
```
### 10.2 AGNTCY Alignment
**Agent Identity Model** (AGNTCY-compliant):
```typescript
interface IAgent {
id: string; // Unique agent ID (UUID) — immutable
email: string; // agent-type-001@sentryagent.ai
agentType: string; // AGNTCY agent type
version: string; // Semantic versioning
capabilities: string[]; // AGNTCY capabilities
owner: string; // Developer/team name
deploymentEnv: string; // dev/staging/prod
status: string; // active/suspended/revoked/archived
createdAt: Date; // Agent creation timestamp
updatedAt: Date; // Last update timestamp
lastAuthAt?: Date; // Last authentication timestamp
metadata?: Record<string, unknown>; // AGNTCY metadata
}
```
**Audit Compliance**:
- ✅ Immutable audit logs (no deletion, no modification)
- ✅ All agent actions logged (creation, auth, revocation)
- ✅ Timestamps in ISO 8601 format
- ✅ Tamper-proof storage (PostgreSQL with constraints)
- ✅ Retention policy (90 days free tier, configurable)
**Policy Enforcement**:
- ✅ Least privilege by default
- ✅ Capability-based access control
- ✅ Revocation at scale
- ✅ Credential rotation on schedule
---
## 11. Quality Gates & Metrics
### 11.1 Code Quality Standards
| Metric | Target | Tool | Enforcement |
|--------|--------|------|-------------|
| Test Coverage | >80% | Jest/nyc | Fail PR if <80% |
| TypeScript Strict | 100% | tsc --strict | Fail build if violations |
| Linting | 0 errors | ESLint | Fail PR if errors |
| Code Duplication | <5% | Manual review | CTO rejects if >5% |
| Security Scan | 0 high/critical | npm audit | Fail build if vulnerabilities |
### 11.2 Performance Standards
| Metric | Target | Measurement | Enforcement |
|--------|--------|-------------|-------------|
| Token Issuance | <100ms | Benchmark test | Fail if >100ms |
| API Response | <200ms | Integration test | Fail if >200ms |
| Database Query | <50ms | Query profiling | Fail if >50ms |
| Cache Hit Rate | >90% | Redis monitoring | Monitor weekly |
### 11.3 Reliability Standards
| Metric | Target | Measurement |
|--------|--------|-------------|
| Uptime | 99.5% (Phase 2) | Monitoring dashboard |
| Error Rate | <0.1% | Error tracking |
| Recovery Time | <5 minutes | Runbook testing |
---
## 12. Deployment & Operations
### 12.1 Local Development Setup
```bash
# Clone repository
git clone https://git.sentryagent.ai/sentryagent-idp.git
cd sentryagent-idp
# Install dependencies
npm install
# Setup environment
cp .env.example .env
# Edit .env with local values
# Start services (PostgreSQL, Redis)
docker-compose up -d
# Run database migrations
npm run migrate
# Start development server
npm run dev
# Server runs on http://localhost:3000
# Swagger UI: http://localhost:3000/api-docs
```
### 12.2 Docker Deployment
```bash
# Build image
docker build -t sentryagent-idp:1.0.0 .
# Run container
docker run -p 3000:3000 \
-e NODE_ENV=production \
-e DATABASE_URL=postgresql://user:pass@db:5432/sentryagent \
-e REDIS_URL=redis://cache:6379 \
-e JWT_SECRET=your-secret-key \
-e JWT_ISSUER=https://api.sentryagent.ai \
sentryagent-idp:1.0.0
```
### 12.3 Docker Compose (Local Development)
```yaml
version: '3.9'
services:
app:
build: .
ports:
- "3000:3000"
environment:
NODE_ENV: development
DATABASE_URL: postgresql://sentryagent:sentryagent@postgres:5432/sentryagent_idp
REDIS_URL: redis://redis:6379
JWT_SECRET: dev-secret-key-change-in-production
depends_on:
- postgres
- redis
volumes:
- ./src:/app/src
command: npm run dev
postgres:
image: postgres:15-alpine
environment:
POSTGRES_USER: sentryagent
POSTGRES_PASSWORD: sentryagent
POSTGRES_DB: sentryagent_idp
ports:
- "5432:5432"
volumes:
- postgres_data:/var/lib/postgresql/data
redis:
image: redis:7-alpine
ports:
- "6379:6379"
volumes:
- redis_data:/data
volumes:
postgres_data:
redis_data:
```
### 12.4 Production Deployment Checklist
- [ ] Environment variables configured securely
- [ ] Database backups enabled (daily)
- [ ] SSL/TLS certificates installed
- [ ] Rate limiting configured
- [ ] Monitoring alerts set up
- [ ] Logging aggregation enabled
- [ ] Disaster recovery plan documented
- [ ] Security audit completed
- [ ] Load balancer configured
- [ ] CDN configured (if applicable)
- [ ] Health check endpoints verified
- [ ] Rollback procedure documented
---
## 13. Risk Management
### 13.1 Technical Risks
| Risk | Probability | Impact | Mitigation |
|------|-------------|--------|-----------|
| Database performance degradation | Medium | High | Connection pooling, caching, indexing |
| Token validation latency | Low | Medium | Redis cache, JWT caching |
| Credential compromise | Low | Critical | Encryption, audit logs, rotation, monitoring |
| API rate limiting bypass | Low | Medium | Token bucket algorithm, monitoring |
| Data loss | Very Low | Critical | Daily backups, replication, disaster recovery |
### 13.2 Mitigation Strategies
- **Code Review**: Catch issues early (Virtual CTO)
- **Testing**: >80% coverage (Virtual QA Engineer)
- **Monitoring**: Real-time alerts (Phase 2)
- **Documentation**: Clear runbooks for operations
- **Backups**: Daily database snapshots
- **Security**: Regular audits and penetration testing
---
## 14. Success Metrics & KPIs
### 14.1 Phase 1 MVP Success Criteria
**Technical**:
- ✅ All features implemented and tested
- ✅ >80% test coverage
- ✅ Zero critical security issues
- ✅ API response time <200ms
- ✅ Token issuance <100ms
- ✅ AGNTCY compliance verified
**Adoption**:
- ✅ 50+ agents registered in first month
- ✅ 10+ developers using the service
- ✅ Positive feedback on ease of use

947
README.md
View File

@@ -6,9 +6,11 @@
**Git Repository**: https://git.sentryagent.ai/
**AI Partner**: Anthropic (Claude — All Development, Implementation & Deployment)
**Standards**: AGNTCY (Linux Foundation), OpenAPI 3.0, OAuth 2.0, OIDC
**Document Role**: Product Requirements Document (PRD) — this file is the single source of truth for all product requirements, scope, and standards
**Document Role**: Project orientation, team charter, and Claude session protocol
**Last Updated**: 2026-03-28
**Status**: ? Active — Phase 1 MVP
**Status**: Active — Phase 1 MVP
> **Product Requirements**: All scope, standards, and technical requirements are in **[PRD.md](./PRD.md)**
---
@@ -45,14 +47,15 @@ development, implementation, and deployment activities.
When a new Claude session is started, Claude **MUST**:
1. **Read this README.md** in full before any action
2. **Adopt the Virtual Engineering Team roles** as defined in Section 4
3. **Enforce all standards** defined in Section 6 without exception
4. **Resume from last known state** (check git.sentryagent.ai for latest commits)
5. **Report status** to CEO before proceeding
6. **Never deviate** from the technology stack defined in Section 7
7. **Never skip** OpenSpec documentation for any new endpoint or service
8. **Always provide complete files** — no partial code, no placeholders
1. **Read [PRD.md](./PRD.md)** in full before any action — this is the product requirements and single source of truth
2. **Read this README.md** for team charter and session protocol
3. **Adopt the Virtual Engineering Team roles** as defined in Section 4
4. **Enforce all standards** defined in PRD.md Section 6 without exception
5. **Resume from last known state** (check git.sentryagent.ai for latest commits)
6. **Report status** to CEO before proceeding
7. **Never deviate** from the technology stack defined in PRD.md Section 7
8. **Never skip** OpenSpec documentation for any new endpoint or service
9. **Always provide complete files** — no partial code, no placeholders
### 2.3 Claude Communication Protocol
@@ -75,12 +78,12 @@ A **free, open-source Agent Identity Provider** that provides:
| Feature | Description | AGNTCY Alignment |
|---------|-------------|-----------------|
| **Agent Registry** | Unique, immutable agent IDs | ? First-class non-human identity |
| **Authentication** | OAuth 2.0 Client Credentials | ? Standardized auth protocol |
| **Authorization** | Scope-based access control | ? Capability-based governance |
| **Lifecycle Management** | Provision, rotate, revoke | ? Full agent lifecycle |
| **Audit Logs** | Immutable, compliance-ready | ? Accountability & governance |
| **Developer SDK** | Node.js (Phase 1) | ? Developer-first experience |
| **Agent Registry** | Unique, immutable agent IDs | First-class non-human identity |
| **Authentication** | OAuth 2.0 Client Credentials | Standardized auth protocol |
| **Authorization** | Scope-based access control | Capability-based governance |
| **Lifecycle Management** | Provision, rotate, revoke | Full agent lifecycle |
| **Audit Logs** | Immutable, compliance-ready | Accountability & governance |
| **Developer SDK** | Node.js (Phase 1) | Developer-first experience |
### 3.2 Target Users
@@ -141,17 +144,27 @@ CEO (Human — SentryAgent.ai Founder)
- Coordinate Virtual Architect, Principal Developer, and QA Engineer
- Report weekly progress to CEO
- Escalate scope changes and blockers to CEO immediately
- **Post a completion confirmation to `#vpe-cto-approvals` after every CEO-authorized action** (include outcome + commit hash)
- **Post an end-of-session summary before closing** any session with completed, pending, or in-progress work
**Claude Session Startup (CTO Role)**:
```
1. Read README.md (this file) in full
2. Check git.sentryagent.ai for latest commits
3. Identify current phase and sprint
4. Report status to CEO
5. Confirm today's priorities
6. Begin work
1. Read PRD.md in full
2. Read README.md (this file) for team charter
3. Check git.sentryagent.ai for latest commits
4. Identify current phase and sprint
5. Report status to CEO
6. Confirm today's priorities
7. Begin work
8. Before closing: post end-of-session summary to #vpe-cto-approvals
(Completed / Pending — authorized but not executed / Requires CEO action)
```
**Session Completion Protocol**:
- "Authorized" = CEO approved. Action not yet executed.
- "Committed / Completed / Deployed" = Action executed with evidence (commit hash, test results).
- Never close a session with an authorized-but-unexecuted action without noting it in the end-of-session summary.
### 4.4 Virtual Architect (Claude — Anthropic)
**Authority**: System design within CTO-approved architecture.
@@ -218,892 +231,8 @@ CEO (Human — SentryAgent.ai Founder)
---
## 5. Project Scope
## 5. Product Requirements
### 5.1 Phase 1: MVP (Weeks 18)
All product requirements, scope, engineering standards, technology stack, quality gates, and success metrics are defined in the standalone PRD:
**Objective**: Prove the concept. Ship a production-ready AgentIdP.
#### In Scope ?
| Feature | Owner | Priority |
|---------|-------|----------|
| Agent Registry Service (CRUD) | Principal Dev | P0 |
| OAuth 2.0 Token Service (Client Credentials) | Principal Dev | P0 |
| Credential Management (generate, rotate, revoke) | Principal Dev | P0 |
| Immutable Audit Log Service | Principal Dev | P0 |
| REST API (agents, tokens, audit) | Principal Dev | P0 |
| PostgreSQL database + migrations | Principal Dev | P0 |
| Redis caching layer | Principal Dev | P1 |
| Node.js SDK | Principal Dev | P1 |
| Docker containerization | Principal Dev | P1 |
| Unit & integration tests (>80% coverage) | QA Engineer | P0 |
| OpenAPI 3.0 documentation | Architect | P0 |
| Docker Compose (local dev) | Principal Dev | P1 |
| Deployment guide | Architect | P1 |
| AGNTCY alignment documentation | Architect | P1 |
#### Out of Scope ? (Phase 2+)
| Feature | Phase |
|---------|-------|
| HashiCorp Vault integration | Phase 2 |
| Multi-region deployment | Phase 2 |
| Advanced policy engine (OPA) | Phase 2 |
| Web dashboard UI | Phase 2 |
| Python/Go/Java/Rust SDKs | Phase 2 |
| Prometheus + Grafana monitoring | Phase 2 |
| AGNTCY federation support | Phase 3 |
| W3C DID support | Phase 3 |
| Agent marketplace | Phase 3 |
| SOC 2 certification | Phase 3 |
### 5.2 Phase 2: Production-Ready (Weeks 920)
- HashiCorp Vault for secret management
- Multi-language SDKs (Python, Go, Java)
- Advanced policy engine (OPA integration)
- Web dashboard UI (React + TypeScript)
- Prometheus + Grafana monitoring
- Multi-region deployment (US, EU, APAC)
- SOC 2 Type II certification process
### 5.3 Phase 3: Ecosystem & Standards (Weeks 2136)
- AGNTCY federation support
- W3C Decentralized Identifiers (DIDs)
- Agent marketplace
- Advanced compliance reporting
- Enterprise tier features
---
## 6. Engineering Standards (Non-Negotiable)
### 6.1 DRY — Don't Repeat Yourself
**Rule**: Zero code duplication. Every piece of logic exists in exactly one place.
**Implementation**:
| Pattern | Location | Purpose |
|---------|----------|---------|
| Type definitions | `src/types/index.ts` | Single source of truth |
| Crypto utilities | `src/utils/crypto.ts` | All crypto operations |
| JWT utilities | `src/utils/jwt.ts` | All JWT operations |
| Validation logic | `src/utils/validators.ts` | All input validation |
| Error classes | `src/utils/errors.ts` | All custom errors |
| DB queries | `src/services/` | All database access |
| HTTP middleware | `src/middleware/` | All cross-cutting concerns |
**Enforcement**:
- Virtual CTO reviews every PR for duplication
- ESLint rules flag repeated patterns
- No copy-paste code — ever
### 6.2 SOLID Principles
**S — Single Responsibility**:
- `AgentService`: Agent CRUD only — nothing else
- `OAuth2Service`: Token issuance only — nothing else
- `CredentialService`: Credential management only — nothing else
- `AuditService`: Audit logging only — nothing else
**O — Open/Closed**:
- All services implement interfaces
- New features extend, never modify existing code
- Plugin architecture for credential backends
**L — Liskov Substitution**:
- All service implementations are interchangeable
- Consistent error handling across all services
- Uniform response shapes across all endpoints
**I — Interface Segregation**:
- Separate read/write interfaces where applicable
- Minimal, focused interfaces — no fat interfaces
- Controllers depend on service interfaces, not implementations
**D — Dependency Inversion**:
- All dependencies injected via constructor
- Services depend on abstractions (interfaces)
- No direct instantiation of dependencies in business logic
### 6.3 OpenSpec Standards (Mandatory)
**Rule**: Every API endpoint MUST have an OpenAPI 3.0 specification
BEFORE implementation begins. No exceptions.
**Process**:
```
1. Virtual Architect writes OpenAPI spec
2. CEO reviews and approves
3. Virtual Principal Developer implements
4. Virtual QA Engineer verifies spec matches implementation
5. Swagger UI auto-generated from spec
```
**OpenAPI Spec Location**: `docs/openapi.yaml`
**Required for every endpoint**:
- Summary and description
- Request body schema (with validation rules)
- Response schemas (all status codes)
- Error response schemas
- Authentication requirements
- Example requests and responses
### 6.4 TypeScript Strict Mode (Mandatory)
**Rule**: TypeScript strict mode is always enabled. No `any` types. Ever.
```json
{
"compilerOptions": {
"strict": true,
"noImplicitAny": true,
"strictNullChecks": true,
"strictFunctionTypes": true,
"strictBindCallApply": true,
"strictPropertyInitialization": true,
"noImplicitThis": true,
"alwaysStrict": true,
"noUnusedLocals": true,
"noUnusedParameters": true,
"noImplicitReturns": true,
"noFallthroughCasesInSwitch": true
}
}
```
### 6.5 Code Documentation Standards
**JSDoc required for**:
- All public classes
- All public methods
- All interfaces
- All complex logic blocks
**Example**:
```typescript
/**
* Creates a new AI agent identity in the SentryAgent.ai registry.
* Assigns a unique immutable ID and provisions credentials.
*
* @param {ICreateAgentRequest} request - Agent creation request
* @returns {Promise<IAgent>} Created agent with assigned ID
* @throws {AgentAlreadyExistsError} If email already registered
* @throws {ValidationError} If request data is invalid
*
* @example
* const agent = await agentService.createAgent({
* email: 'screener-001@sentryagent.ai',
* agentType: 'screener',
* version: 'v1.0.0',
* capabilities: ['resume:read'],
* owner: 'helloworld-team',
* deploymentEnv: 'production'
* });
*/
async createAgent(request: ICreateAgentRequest): Promise<IAgent>
```
### 6.6 Error Handling Standards
**Rule**: All errors are explicit, typed, and handled. No silent failures.
```typescript
// Custom error hierarchy
class SentryAgentError extends Error {}
class ValidationError extends SentryAgentError {}
class AgentNotFoundError extends SentryAgentError {}
class AgentAlreadyExistsError extends SentryAgentError {}
class CredentialError extends SentryAgentError {}
class AuthenticationError extends SentryAgentError {}
class AuthorizationError extends SentryAgentError {}
class RateLimitError extends SentryAgentError {}
```
**All errors include**:
- Error code (machine-readable)
- Error message (human-readable)
- HTTP status code
- Stack trace (development only)
### 6.7 Git Standards
**Repository**: `https://git.sentryagent.ai/`
**Branch Strategy** (Git Flow):
- `main`: Production-ready code only
- `develop`: Integration branch for Phase work
- `feature/*`: Individual features (e.g., `feature/agent-registry`)
- `bugfix/*`: Bug fixes (e.g., `bugfix/token-validation`)
- `release/*`: Release preparation (e.g., `release/v1.0.0`)
**Commit Standards** (Conventional Commits):
```
feat(agent): implement agent registry CRUD
fix(oauth2): correct token expiration calculation
docs(api): update OpenAPI spec for /agents endpoint
test(credential): add rotation edge case tests
chore(deps): upgrade TypeScript to 5.3.3
```
**Pull Request Standards**:
- [ ] Feature branch created from `develop`
- [ ] OpenAPI spec updated (if API change)
- [ ] Unit tests added (>80% coverage)
- [ ] Integration tests added
- [ ] JSDoc comments added
- [ ] No code duplication (DRY check)
- [ ] SOLID principles followed
- [ ] Performance acceptable (<200ms)
- [ ] Security review passed
- [ ] Virtual CTO approval required
- [ ] Virtual QA Engineer sign-off required
- [ ] Merge to `develop` (squash commits)
- [ ] Delete feature branch
---
## 7. Technology Stack
### 7.1 Runtime & Language
| Component | Version | Rationale |
|-----------|---------|-----------|
| Node.js | 18+ (LTS) | Stable, widely used, excellent TypeScript support |
| TypeScript | 5.3+ | Strict mode, type safety, no `any` types |
| npm | 9+ | Standard package manager |
### 7.2 Web Framework & Middleware
| Component | Version | Purpose |
|-----------|---------|---------|
| Express.js | 4.18+ | Lightweight, battle-tested web framework |
| helmet | 7.1+ | Security headers (HSTS, CSP, etc.) |
| cors | 2.8+ | CORS handling |
| morgan | 1.10+ | HTTP request logging |
| pino | 8.17+ | Structured JSON logging |
| pino-http | 8.6+ | Express integration for Pino |
### 7.3 Database & Caching
| Component | Version | Purpose |
|-----------|---------|---------|
| PostgreSQL | 14+ | Primary database (ACID, reliability) |
| pg | 8.11+ | PostgreSQL client library |
| Redis | 7+ | Caching layer (token validation, sessions) |
| redis | 4.6+ | Redis client library |
### 7.4 Authentication & Security
| Component | Version | Purpose |
|-----------|---------|---------|
| jsonwebtoken | 9.1+ | JWT signing and verification |
| bcryptjs | 2.4+ | Password/secret hashing (10 salt rounds) |
| uuid | 9.0+ | Unique ID generation |
| crypto (Node.js built-in) | N/A | Cryptographic operations |
| dotenv | 16.3+ | Environment variable management |
### 7.5 Testing
| Component | Version | Purpose |
|-----------|---------|---------|
| Jest | 29.7+ | Unit and integration testing |
| @types/jest | 29.5+ | TypeScript types for Jest |
| ts-jest | 29.1+ | Jest + TypeScript integration |
| supertest | 6.3+ | HTTP endpoint testing |
| @testing-library/node | Latest | Node.js testing utilities |
### 7.6 Code Quality & Linting
| Component | Version | Purpose |
|-----------|---------|---------|
| ESLint | 8.56+ | Code linting and style |
| @typescript-eslint/parser | 6.17+ | TypeScript parsing for ESLint |
| @typescript-eslint/eslint-plugin | 6.17+ | TypeScript-specific rules |
| Prettier | 3.1+ | Code formatting |
### 7.7 Documentation & API
| Component | Version | Purpose |
|-----------|---------|---------|
| swagger-ui-express | 4.6+ | Interactive API documentation |
| joi | 17.11+ | Schema validation |
### 7.8 Deployment & Containerization
| Component | Version | Purpose |
|-----------|---------|---------|
| Docker | 24+ | Container runtime |
| Docker Compose | 2.20+ | Local development orchestration |
| Alpine Linux | 3.18 | Minimal base image |
### 7.9 Validation & Schema
| Component | Version | Purpose |
|-----------|---------|---------|
| Joi | 17.11+ | Request/response schema validation |
---
## 8. Project Structure (DRY Compliance)
```
sentryagent-idp/
+-- src/
¦ +-- config/
¦ ¦ +-- env.ts # Environment variables
¦ ¦ +-- database.ts # PostgreSQL connection pool
¦ ¦ +-- redis.ts # Redis client
¦ ¦ +-- logger.ts # Pino logger configuration
¦ ¦
¦ +-- types/
¦ ¦ +-- index.ts # All TypeScript interfaces (single source of truth)
¦ ¦
¦ +-- models/
¦ ¦ +-- Agent.ts # Agent entity
¦ ¦ +-- Credential.ts # Credential entity
¦ ¦ +-- AuditLog.ts # Audit log entity
¦ ¦ +-- Token.ts # Token entity
¦ ¦
¦ +-- services/
¦ ¦ +-- AgentService.ts # Agent CRUD (no duplication)
¦ ¦ +-- OAuth2Service.ts # Token issuance (no duplication)
¦ ¦ +-- CredentialService.ts # Credential management (no duplication)
¦ ¦ +-- AuditService.ts # Audit logging (no duplication)
¦ ¦ +-- TokenService.ts # Token operations (no duplication)
¦ ¦
¦ +-- controllers/
¦ ¦ +-- AgentController.ts # Agent endpoints
¦ ¦ +-- OAuth2Controller.ts # OAuth 2.0 endpoints
¦ ¦ +-- HealthController.ts # Health check endpoint
¦ ¦
¦ +-- middleware/
¦ ¦ +-- authentication.ts # Bearer token validation
¦ ¦ +-- authorization.ts # Scope-based access control
¦ ¦ +-- errorHandler.ts # Global error handling
¦ ¦ +-- logging.ts # Request/response logging
¦ ¦ +-- validation.ts # Request validation
¦ ¦ +-- rateLimit.ts # Rate limiting
¦ ¦
¦ +-- utils/
¦ ¦ +-- crypto.ts # Crypto utilities (hashing, secrets)
¦ ¦ +-- jwt.ts # JWT utilities (sign, verify)
¦ ¦ +-- validators.ts # Input validation (reusable)
¦ ¦ +-- errors.ts # Custom error classes
¦ ¦ +-- helpers.ts # General utilities
¦ ¦
¦ +-- routes/
¦ ¦ +-- agents.ts # Agent routes
¦ ¦ +-- oauth2.ts # OAuth 2.0 routes
¦ ¦ +-- health.ts # Health routes
¦ ¦
¦ +-- migrations/
¦ ¦ +-- 001_create_agents_table.sql
¦ ¦ +-- 002_create_credentials_table.sql
¦ ¦ +-- 003_create_audit_logs_table.sql
¦ ¦
¦ +-- app.ts # Express app setup
¦ +-- server.ts # Server entry point
¦
+-- tests/
¦ +-- unit/
¦ ¦ +-- services/
¦ ¦ ¦ +-- AgentService.test.ts
¦ ¦ ¦ +-- OAuth2Service.test.ts
¦ ¦ ¦ +-- CredentialService.test.ts
¦ ¦ ¦ +-- AuditService.test.ts
¦ ¦ +-- utils/
¦ ¦ +-- crypto.test.ts
¦ ¦ +-- jwt.test.ts
¦ ¦ +-- validators.test.ts
¦ ¦
¦ +-- integration/
¦ ¦ +-- api/
¦ ¦ ¦ +-- agents.test.ts
¦ ¦ ¦ +-- oauth2.test.ts
¦ ¦ ¦ +-- health.test.ts
¦ ¦ +-- database/
¦ ¦ +-- migrations.test.ts
¦ ¦
¦ +-- fixtures/
¦ +-- agents.json
¦ +-- credentials.json
¦ +-- auditLogs.json
¦
+-- docs/
¦ +-- README.md # This file
¦ +-- architecture.md # Architecture Decision Records
¦ +-- openapi.yaml # OpenAPI 3.0 specification
¦ +-- deployment.md # Deployment guide
¦ +-- agntcy-alignment.md # AGNTCY compliance documentation
¦ +-- api-guide.md # API usage guide
¦ +-- contributing.md # Contribution guidelines
¦
+-- docker-compose.yml # Local development stack
+-- Dockerfile # Production image
+-- .dockerignore # Docker build exclusions
+-- .env.example # Environment template
+-- .env.test # Test environment
+-- .gitignore # Git exclusions
+-- .eslintrc.js # ESLint configuration
+-- .prettierrc.json # Prettier configuration
+-- tsconfig.json # TypeScript configuration
+-- jest.config.js # Jest configuration
+-- package.json # Dependencies and scripts
+-- package-lock.json # Locked dependencies
+-- CHANGELOG.md # Version history
+-- LICENSE # Open source license (MIT)
+-- README.md # Project README
```
**DRY Principles Applied**:
- ? Single `types/index.ts` for all interfaces (no duplication)
- ? Shared `utils/` for crypto, JWT, validation (no duplication)
- ? Centralized error handling in middleware (no duplication)
- ? Reusable service layer (no business logic in controllers)
- ? Configuration centralized in `config/` (no duplication)
- ? Database queries isolated in services (no duplication)
---
## 9. Development Workflow
### 9.1 Feature Development Process
**Step 1: Specification (Virtual Architect)**
- Write Architecture Decision Record (ADR)
- Define OpenAPI 3.0 specification
- Specify database schema
- List test cases
- CEO approves specification
**Step 2: Implementation (Virtual Principal Developer)**
- Create feature branch: `git checkout -b feature/agent-registry`
- Implement per specification
- Follow DRY and SOLID principles
- Add JSDoc comments
- Create unit tests (>80% coverage)
- Push to `git.sentryagent.ai`
**Step 3: Code Review (Virtual CTO)**
- Check compliance with standards
- Verify DRY principles
- Review test coverage
- Verify SOLID principles
- Approve or request changes
**Step 4: Testing (Virtual QA Engineer)**
- Run integration tests
- Test edge cases
- Verify AGNTCY alignment
- Verify OpenAPI spec matches implementation
- Sign off on quality
**Step 5: Deployment (Virtual CTO)**
- Merge to `develop` branch (squash commits)
- Delete feature branch
- Deploy to staging
- Deploy to production
### 9.2 Git Workflow
```bash
# Create feature branch from develop
git checkout develop
git pull origin develop
git checkout -b feature/agent-registry
# Make changes, commit with conventional commits
git add src/services/AgentService.ts
git commit -m "feat(agent): implement agent registry CRUD"
# Push to repository
git push origin feature/agent-registry
# Create pull request on git.sentryagent.ai
# Virtual CTO reviews and approves
# Virtual QA Engineer signs off
# Merge to develop (squash commits)
git checkout develop
git pull origin develop
git merge --squash feature/agent-registry
git commit -m "feat(agent): implement agent registry CRUD"
git push origin develop
# Delete feature branch
git branch -d feature/agent-registry
git push origin --delete feature/agent-registry
```
### 9.3 Code Review Checklist
Before any code is merged to `develop`, verify:
- [ ] TypeScript strict mode: `tsc --strict` passes
- [ ] No `any` types used
- [ ] No code duplication (DRY check)
- [ ] SOLID principles applied
- [ ] Unit tests included (>80% coverage)
- [ ] Integration tests included
- [ ] JSDoc comments present
- [ ] Error handling implemented
- [ ] No OWASP Top 10 vulnerabilities
- [ ] Performance acceptable (<200ms)
- [ ] Database migrations included
- [ ] OpenAPI specification updated
- [ ] Conventional commit message used
- [ ] Virtual CTO approval obtained
- [ ] Virtual QA Engineer sign-off obtained
---
## 10. OpenSpec Compliance
### 10.1 OpenAPI 3.0 Specification
**Location**: `docs/openapi.yaml`
**Mandatory for every endpoint**:
- Summary and description
- Request body schema (with validation rules)
- Response schemas (all status codes)
- Error response schemas
- Authentication requirements
- Example requests and responses
**Example OpenAPI Spec**:
```yaml
openapi: 3.0.0
info:
title: SentryAgent.ai Agent Identity Provider
version: 1.0.0
description: Free, open-source Agent Identity Provider
contact:
name: SentryAgent.ai
url: https://sentryagent.ai
servers:
- url: https://api.sentryagent.ai
description: Production
- url: http://localhost:3000
description: Development
paths:
/agents:
post:
summary: Create a new AI agent
operationId: createAgent
tags:
- Agents
requestBody:
required: true
content:
application/json:
schema:
$ref: '#/components/schemas/CreateAgentRequest'
responses:
'201':
description: Agent created successfully
content:
application/json:
schema:
$ref: '#/components/schemas/Agent'
'400':
description: Invalid request
content:
application/json:
schema:
$ref: '#/components/schemas/Error'
'409':
description: Agent already exists
content:
application/json:
schema:
$ref: '#/components/schemas/Error'
components:
schemas:
Agent:
type: object
required:
- id
- email
- agentType
- version
- capabilities
- owner
- deploymentEnv
- status
- createdAt
- updatedAt
properties:
id:
type: string
format: uuid
description: Unique agent identifier
email:
type: string
format: email
description: Agent email (agent-type-001@sentryagent.ai)
agentType:
type: string
description: AGNTCY agent type
version:
type: string
description: Semantic version
capabilities:
type: array
items:
type: string
description: Agent capabilities
owner:
type: string
description: Developer or team name
deploymentEnv:
type: string
enum: [development, staging, production]
status:
type: string
enum: [active, suspended, revoked, archived]
createdAt:
type: string
format: date-time
updatedAt:
type: string
format: date-time
Error:
type: object
required:
- code
- message
properties:
code:
type: string
description: Error code
message:
type: string
description: Error message
details:
type: object
description: Additional error details
```
### 10.2 AGNTCY Alignment
**Agent Identity Model** (AGNTCY-compliant):
```typescript
interface IAgent {
id: string; // Unique agent ID (UUID) — immutable
email: string; // agent-type-001@sentryagent.ai
agentType: string; // AGNTCY agent type
version: string; // Semantic versioning
capabilities: string[]; // AGNTCY capabilities
owner: string; // Developer/team name
deploymentEnv: string; // dev/staging/prod
status: string; // active/suspended/revoked/archived
createdAt: Date; // Agent creation timestamp
updatedAt: Date; // Last update timestamp
lastAuthAt?: Date; // Last authentication timestamp
metadata?: Record<string, unknown>; // AGNTCY metadata
}
```
**Audit Compliance**:
- ? Immutable audit logs (no deletion, no modification)
- ? All agent actions logged (creation, auth, revocation)
- ? Timestamps in ISO 8601 format
- ? Tamper-proof storage (PostgreSQL with constraints)
- ? Retention policy (90 days free tier, configurable)
**Policy Enforcement**:
- ? Least privilege by default
- ? Capability-based access control
- ? Revocation at scale
- ? Credential rotation on schedule
---
## 11. Quality Gates & Metrics
### 11.1 Code Quality Standards
| Metric | Target | Tool | Enforcement |
|--------|--------|------|-------------|
| Test Coverage | >80% | Jest/nyc | Fail PR if <80% |
| TypeScript Strict | 100% | tsc --strict | Fail build if violations |
| Linting | 0 errors | ESLint | Fail PR if errors |
| Code Duplication | <5% | Manual review | CTO rejects if >5% |
| Security Scan | 0 high/critical | npm audit | Fail build if vulnerabilities |
### 11.2 Performance Standards
| Metric | Target | Measurement | Enforcement |
|--------|--------|-------------|-------------|
| Token Issuance | <100ms | Benchmark test | Fail if >100ms |
| API Response | <200ms | Integration test | Fail if >200ms |
| Database Query | <50ms | Query profiling | Fail if >50ms |
| Cache Hit Rate | >90% | Redis monitoring | Monitor weekly |
### 11.3 Reliability Standards
| Metric | Target | Measurement |
|--------|--------|-------------|
| Uptime | 99.5% (Phase 2) | Monitoring dashboard |
| Error Rate | <0.1% | Error tracking |
| Recovery Time | <5 minutes | Runbook testing |
---
## 12. Deployment & Operations
### 12.1 Local Development Setup
```bash
# Clone repository
git clone https://git.sentryagent.ai/sentryagent-idp.git
cd sentryagent-idp
# Install dependencies
npm install
# Setup environment
cp .env.example .env
# Edit .env with local values
# Start services (PostgreSQL, Redis)
docker-compose up -d
# Run database migrations
npm run migrate
# Start development server
npm run dev
# Server runs on http://localhost:3000
# Swagger UI: http://localhost:3000/api-docs
```
### 12.2 Docker Deployment
```bash
# Build image
docker build -t sentryagent-idp:1.0.0 .
# Run container
docker run -p 3000:3000 \
-e NODE_ENV=production \
-e DATABASE_URL=postgresql://user:pass@db:5432/sentryagent \
-e REDIS_URL=redis://cache:6379 \
-e JWT_SECRET=your-secret-key \
-e JWT_ISSUER=https://api.sentryagent.ai \
sentryagent-idp:1.0.0
```
### 12.3 Docker Compose (Local Development)
```yaml
version: '3.9'
services:
app:
build: .
ports:
- "3000:3000"
environment:
NODE_ENV: development
DATABASE_URL: postgresql://sentryagent:sentryagent@postgres:5432/sentryagent_idp
REDIS_URL: redis://redis:6379
JWT_SECRET: dev-secret-key-change-in-production
depends_on:
- postgres
- redis
volumes:
- ./src:/app/src
command: npm run dev
postgres:
image: postgres:15-alpine
environment:
POSTGRES_USER: sentryagent
POSTGRES_PASSWORD: sentryagent
POSTGRES_DB: sentryagent_idp
ports:
- "5432:5432"
volumes:
- postgres_data:/var/lib/postgresql/data
redis:
image: redis:7-alpine
ports:
- "6379:6379"
volumes:
- redis_data:/data
volumes:
postgres_data:
redis_data:
```
### 12.4 Production Deployment Checklist
- [ ] Environment variables configured securely
- [ ] Database backups enabled (daily)
- [ ] SSL/TLS certificates installed
- [ ] Rate limiting configured
- [ ] Monitoring alerts set up
- [ ] Logging aggregation enabled
- [ ] Disaster recovery plan documented
- [ ] Security audit completed
- [ ] Load balancer configured
- [ ] CDN configured (if applicable)
- [ ] Health check endpoints verified
- [ ] Rollback procedure documented
---
## 13. Risk Management
### 13.1 Technical Risks
| Risk | Probability | Impact | Mitigation |
|------|-------------|--------|-----------|
| Database performance degradation | Medium | High | Connection pooling, caching, indexing |
| Token validation latency | Low | Medium | Redis cache, JWT caching |
| Credential compromise | Low | Critical | Encryption, audit logs, rotation, monitoring |
| API rate limiting bypass | Low | Medium | Token bucket algorithm, monitoring |
| Data loss | Very Low | Critical | Daily backups, replication, disaster recovery |
### 13.2 Mitigation Strategies
- **Code Review**: Catch issues early (Virtual CTO)
- **Testing**: >80% coverage (Virtual QA Engineer)
- **Monitoring**: Real-time alerts (Phase 2)
- **Documentation**: Clear runbooks for operations
- **Backups**: Daily database snapshots
- **Security**: Regular audits and penetration testing
---
## 14. Success Metrics & KPIs
### 14.1 Phase 1 MVP Success Criteria
**Technical**:
- ? All features implemented and tested
- ? >80% test coverage
- ? Zero critical security issues
- ? API response time <200ms
- ? Token issuance <100ms
- ? AGNTCY compliance verified
**Adoption**:
- ? 50+ agents registered in first month
- ? 10+ developers using the service
- ? Positive feedback on ease of use
-
> **[PRD.md](./PRD.md)** — Product Requirements Document (single source of truth for all requirements)

77
TBC/charter.md Normal file
View File

@@ -0,0 +1,77 @@
# Technical & Business Consultant (TBC) — Charter
**Document No.:** TBC-CHARTER-001
**Project:** SentryAgent.ai AgentIdP
**Owner:** CEO
---
## Revision History
| Rev | Date | Author | Description |
|-----|------|--------|-------------|
| 1.0 | 2026-04-07 | CEO / TBC | Initial charter — established in founding session |
---
## 1. Role Definition
The Technical & Business Consultant (TBC) is a direct report to the CEO of SentryAgent.ai. The TBC operates as an independent advisory function — separate from the engineering execution chain.
## 2. Reporting Structure
```
CEO (Human)
├── Virtual CTO → engineering execution, follows OpenSpec Protocol
├── Lead Validator → independent V&V audit, follows OpenSpec Protocol
└── Technical & Business Consultant (TBC) → advisory only, reports to CEO only
```
- TBC reports exclusively to the CEO
- TBC does NOT interact with the CTO or Lead Validator directly
- TBC does NOT manage any engineering work
- TBC does NOT follow OpenSpec Protocol (advisory role, not execution role)
## 3. Scope of Responsibilities
- Advise the CEO on strategic and technical decisions before they are delegated to the CTO
- Review processes and identify gaps, risks, or improvement opportunities
- Maintain portfolio-level thinking across all SentryAgent.ai products and initiatives
- Challenge assumptions independently — without being inside the execution chain
- Serve as the CEO's thinking partner as the virtual factory scales
## 4. Document & Change Authority
TBC MAY propose changes to CLAUDE.md, README.md, and PRD.md.
TBC MAY NOT implement those changes directly. All changes to controlled documents follow this process:
| Step | Owner |
|------|-------|
| Identify and document the proposed change | TBC (in meeting minutes) |
| Review and approve the proposal | CEO |
| Instruct CTO to implement via OpenSpec Protocol | CEO → CTO |
| Raise OpenSpec change, implement, and commit | CTO |
## 5. Record Keeping (ISO 9000)
**"If it is not written, it does not exist."**
TBC maintains written records of all working sessions with the CEO. Records are stored in:
```
TBC/
├── charter.md # This document
└── minutes/
└── TBC-MIN-NNN-YYYY-MM-DD.md # Meeting minutes, sequentially numbered
```
All minutes follow the standard format defined in TBC-MIN-001.
## 6. Operating Principles
1. Advisory only — influence flows through the CEO, never direct to the team
2. Written record of every session — no exceptions
3. Independent perspective — not captured by execution priorities
4. ISO 9000 discipline — every document has revision history, date, and owner
5. Portfolio thinking — always considering the broader virtual factory, not just the current sprint

View File

@@ -0,0 +1,181 @@
# Meeting Minutes
**Document No.:** TBC-MIN-001
**Project:** SentryAgent.ai AgentIdP
**Meeting Type:** Working Session — CEO & TBC (Inaugural)
---
## Revision History
| Rev | Date | Author | Description |
|-----|------|--------|-------------|
| 1.0 | 2026-04-07 | TBC | Initial minutes — inaugural session |
---
## Meeting Details
| Field | Detail |
|-------|--------|
| Date | 2026-04-07 |
| Participants | CEO (Human), TBC (Claude — Technical & Business Consultant) |
| Session Type | Strategic advisory |
---
## 1. Project Status at Session Open
The following state was confirmed at session open via hub message review and git status:
| Item | Status |
|------|--------|
| Phase | Phase 6 — COMPLETE (dev freeze in effect) |
| V&V | PASS — all 6 issues resolved |
| Field trial | Unblocked but not yet started |
| Pending commit | 5 uncommitted files (V&V resolution changes) — authorized but not executed by CTO |
| Active OpenSpec changes | 0 at session open |
---
## 2. Topics Discussed
### 2.1 Process Gap — Authorization vs. Execution Handoff
**Issue raised:** The CTO received CEO authorization (msg #93) to commit outstanding V&V resolution changes. The session ended before the CTO confirmed completion. Five files remained uncommitted, and field trial status was ambiguous.
**Root cause identified:** The process had no completion gate. Authorization was treated as the finish line. There was no protocol requiring the CTO to confirm execution back to the CEO.
**CEO direction:** Treat this as a process flaw, not a blame issue. Identify the gap and fix it.
**Resolution:** TBC proposed three process improvements:
1. Mandatory completion confirmation after every CEO-authorized action
2. End-of-session summary required before CTO closes any session
3. Explicit "authorized vs. done" vocabulary — never interchangeable
**Outcome:** CEO approved all three recommendations. OpenSpec change `process-governance-handoff-gap` raised and implemented. CLAUDE.md, README.md, and `docs/engineering/08-workflow.md` updated. *(See OpenSpec change record for full detail.)*
---
### 2.2 Company Vision Confirmed
**CEO confirmed the primary objective:**
> *"SentryAgent.ai is building the world's first free, open-source identity provider specifically for AI agents — think of it as 'Auth0 for agents.'"*
This statement is the north star for all product, process, and portfolio decisions.
---
### 2.3 Virtual Factory Model — Strategic Direction
**CEO introduced the virtual factory concept:**
SentryAgent.ai operates as a virtual factory:
- CEO is human — sole human principal
- Entire engineering team is virtual (LLM-powered)
- CEO has 30+ years managing global engineering teams, building real-time unified communications products generating hundreds of billions in sales
- AgentIdP (Phase 6 complete) is proof of concept for the factory model
**Strategic direction stated by CEO:** The company must now think beyond a single product. The virtual factory must be capable of running multiple product pipelines simultaneously.
**Three goals established:**
| # | Goal |
|---|------|
| 1 | **Product** — AgentIdP: "Auth0 for agents." Ship, prove, grow. |
| 2 | **Process** — World-class engineering operations. The virtual factory is the competitive moat. |
| 3 | **People (Virtual)** — Empower the virtual team with the right structure and governance. |
---
### 2.4 TBC Role — Established
**CEO decision:** A Technical & Business Consultant (TBC) role is established as a direct report to the CEO, alongside the Virtual CTO and Lead Validator.
**Org structure confirmed:**
```
CEO (Human)
├── Virtual CTO → engineering execution, OpenSpec Protocol
├── Lead Validator → independent V&V audit, OpenSpec Protocol
└── Technical & Business Consultant (TBC) → advisory only, CEO only
```
**Key characteristics of TBC role:**
- Reports to CEO only — no interaction with CTO or Validator
- Not bound by OpenSpec Protocol
- Advisory function — does not execute engineering work
- Maintains written records of all CEO sessions (ISO 9000 discipline)
---
### 2.5 Change Authority — Governance Decision
**Question raised:** Should TBC be allowed to make changes to CLAUDE.md, README.md, and PRD.md directly?
**Decision:** TBC may PROPOSE changes. TBC may NOT implement them directly.
**Approved process:**
| Step | Owner |
|------|-------|
| Identify and document proposed change | TBC (in meeting minutes) |
| Review and approve | CEO |
| Instruct CTO to implement via OpenSpec Protocol | CEO → CTO |
| Raise OpenSpec change, implement, commit | CTO |
**Rationale:** All changes to controlled documents must go through OpenSpec. This keeps the change audit trail clean and ensures the CTO remains the sole execution owner. TBC influence flows through the CEO — not directly to the team.
---
### 2.6 TBC Directory — Established
TBC directory created at project root:
```
TBC/
├── charter.md # TBC role charter (TBC-CHARTER-001)
└── minutes/
└── TBC-MIN-001-2026-04-07.md # This document
```
ISO 9000 convention adopted: all documents carry document number, revision history, date, and author.
---
## 3. Decisions Made
| # | Decision | Owner |
|---|----------|-------|
| D1 | Process gap (authorization vs. execution) fixed via OpenSpec change `process-governance-handoff-gap` | CTO (implemented) |
| D2 | Company vision confirmed: "Auth0 for agents" | CEO |
| D3 | Virtual factory must scale to multiple products — strategic direction set | CEO |
| D4 | Three-goal framework established: Product / Process / People | CEO |
| D5 | TBC role established as CEO direct report | CEO |
| D6 | TBC operates outside OpenSpec; proposes changes only — CTO implements | CEO |
| D7 | TBC directory and ISO 9000 minutes convention established | CEO / TBC |
---
## 4. Open Items / Actions
| # | Action | Owner | Status |
|---|--------|-------|--------|
| A1 | CTO to commit outstanding V&V resolution changes and confirm with commit hash | CTO | **Pending — awaiting CEO instruction to CTO** |
| A2 | CEO to authorize field trial execution once A1 is confirmed | CEO | Pending A1 |
| A3 | Update CLAUDE.md to add TBC role to org structure and startup protocol | CTO via OpenSpec | **Proposed — pending CEO authorization** |
| A4 | Define next product(s) for the virtual factory | CEO / TBC | Future session |
---
## 5. Next Session Priorities
1. Close A1 — instruct CTO to execute the pending commit
2. Authorize field trial (A2) once commit is confirmed
3. Begin scoping A3 — update controlled documents to reflect TBC role formally
4. Start portfolio thinking: what is product #2 for the virtual factory?
---
*End of minutes — TBC-MIN-001 | Rev 1.0 | 2026-04-07*

View File

@@ -0,0 +1,89 @@
# Meeting Minutes
**Document No.:** TBC-MIN-002
**Project:** SentryAgent.ai AgentIdP
**Meeting Type:** Working Session — CEO & TBC (Session 2 — Opening)
---
## Revision History
| Rev | Date | Author | Description |
|-----|------|--------|-------------|
| 1.0 | 2026-04-07 | TBC | Initial minutes — session 2 opening |
---
## Meeting Details
| Field | Detail |
|-------|--------|
| Date | 2026-04-07 |
| Participants | CEO (Human), TBC (Claude — Technical & Business Consultant) |
| Session Type | Strategic advisory — opening exchange |
---
## 1. Project Status at Session Open
Carried forward from TBC-MIN-001:
| Item | Status |
|------|--------|
| Phase | Phase 6 — COMPLETE (dev freeze in effect) |
| V&V | PASS — all 6 issues resolved |
| Field trial | Unblocked but not yet started |
| A1: CTO pending commit | Still outstanding — not confirmed in prior session |
| A2: Field trial authorization | Pending A1 |
| A3: CLAUDE.md TBC update | Proposed — pending CEO authorization to CTO |
---
## 2. Topics Discussed
### 2.1 Session Agenda — Established
CEO confirmed the agenda for this session:
> *"We discuss our company needs and based on that we will develop our agent."*
This session will focus on:
1. Identifying company needs / strategic priorities
2. Scoping and developing the next agent based on those needs
Implementation (if any) will follow the standard CEO → CTO delegation path.
### 2.2 TBC Channel — Created
`#tbc-ceo` channel created on central hub (did not exist previously). All future TBC ↔ CEO communication will use this channel.
---
## 3. Decisions Made
| # | Decision | Owner |
|---|----------|-------|
| D1 | Session agenda: discuss company needs, then develop an agent | CEO |
---
## 4. Open Items / Actions
| # | Action | Owner | Status |
|---|--------|-------|--------|
| A1 | CTO to commit outstanding V&V resolution changes + confirm with hash | CTO | Pending |
| A2 | CEO to authorize field trial once A1 confirmed | CEO | Pending A1 |
| A3 | Update CLAUDE.md to formally add TBC to org structure | CTO via OpenSpec | Proposed — pending CEO authorization |
| A4 | Discuss company needs → scope next agent | CEO / TBC | **In progress — resuming next exchange** |
---
## 5. Next Session Priorities
1. CEO to present company needs / strategic priorities
2. TBC to advise on agent scoping based on those needs
3. CEO to delegate to CTO if implementation is authorized
---
*End of minutes — TBC-MIN-002 | Rev 1.0 | 2026-04-07 | Session paused — CEO on break*

View File

@@ -1,52 +1,275 @@
#!/bin/bash
# =============================================================================
# SentryAgent.ai — Start V&V Architect (Lead Validator)
# =============================================================================
# Launches an independent Claude Code instance as the Lead Validator.
# This agent verifies the CTO's work against the PRD/OpenSpec.
#
# Usage:
# ./scripts/start-validator.sh
# =============================================================================
# SentryAgent.ai — V&V Architect (Lead Validator)
set -e
## IDENTITY & INDEPENDENCE
PROJECT_ROOT="$(cd "$(dirname "${BASH_SOURCE[0]}")/.." && pwd)"
VALIDATOR_WORKSPACE="$PROJECT_ROOT/.validator-workspace"
VALIDATOR_PROMPT="$PROJECT_ROOT/VALIDATOR.md"
You are the **V&V Architect (Lead Validator)** for SentryAgent.ai AgentIdP.
echo "=============================================="
echo " SentryAgent.ai — Starting V&V Architect Agent"
echo "=============================================="
echo ""
echo " Project: $PROJECT_ROOT"
echo " Workspace: $VALIDATOR_WORKSPACE"
echo " Role Config: $VALIDATOR_PROMPT"
echo ""
echo " The V&V Architect will:"
echo " 1. Audit Code against OpenSpec PRD"
echo " 2. Enforce DRY Principles"
echo " 3. Log Issues for CTO Resolution"
echo " 4. Maintain Local Fail-Safe Ledger"
echo ""
echo "=============================================="
- **Instance ID:** `LeadValidator`
- **Role:** Independent verification and validation — you are NOT part of the engineering team
- **Authority:** You report findings directly to the CEO. The CTO has no authority to dismiss your findings.
- **Mandate:** Ensure that everything the engineering team built actually matches what was specified in the PRD and OpenSpec
- **Isolation:** Do NOT carry context from any other project or session. This is a private, independent audit session.
# Ensure the Validator Workspace and Local Ledger exist
mkdir -p "$VALIDATOR_WORKSPACE/.openspec/vv_audit"
You are a check on the system — not a builder. You never implement features, never approve architectural changes, and never take direction from the Virtual CTO. Your only job is to find gaps, deviations, and violations and formally log them.
# Verify the Validator Persona file exists (from Part 1 of instructions)
if [ ! -f "$VALIDATOR_PROMPT" ]; then
echo "ERROR: VALIDATOR.md not found at $VALIDATOR_PROMPT"
echo "Please ensure you have created the System Instruction file."
exit 1
fi
---
# Synchronize the latest CLAUDE.md to the validator workspace if needed
if [ -f "$PROJECT_ROOT/CLAUDE.md" ]; then
cp "$PROJECT_ROOT/CLAUDE.md" "$VALIDATOR_WORKSPACE/CLAUDE.md"
fi
## STARTUP PROTOCOL (Execute on every new session — no exceptions)
# Launch Claude Code as an independent Auditor
cd "$VALIDATOR_WORKSPACE"
exec claude --system-prompt-file "$VALIDATOR_PROMPT"
Execute these steps in order before doing anything else:
### Step 1 — Read the source of truth
Read `/home/ubuntu/vj_ai_agents_dev/sentryagent-idp/README.md` in full.
This is the PRD. Everything the engineering team built must conform to it.
### Step 2 — Register on central hub
Register as `LeadValidator` on the central hub.
### Step 3 — Check existing open issues
Read all files in `/home/ubuntu/vj_ai_agents_dev/sentryagent-idp/openspec/vv_audit/` — this is your ledger.
List any issues currently with status `OPEN` or `DISPUTED`.
### Step 4 — Check #vv-findings channel
Check the `#vv-findings` channel on the central hub for any recent messages from the CTO regarding issue resolution or disputes.
### Step 5 — Report readiness to CEO
Post a status message to `#vv-findings` channel:
- How many open/disputed issues exist
- Whether you are performing a fresh audit or continuing an existing one
- What you plan to audit this session
### Step 6 — Begin audit
Execute the audit methodology below.
---
## AUDIT METHODOLOGY
### Phase A — OpenSpec Completeness Check
For every archived OpenSpec change, verify the tasks were fully implemented.
**Archived changes location:** `/home/ubuntu/vj_ai_agents_dev/sentryagent-idp/openspec/changes/archive/`
For each archived change:
1. Read its `tasks.md`
2. All tasks marked `[x]` — verify the corresponding code actually exists and matches the task description
3. Any task marked `[ ]` — this is a BLOCKER finding (incomplete implementation)
### Phase B — API Surface Audit
Verify every API endpoint has a corresponding OpenAPI spec.
**OpenAPI specs location:** `/home/ubuntu/vj_ai_agents_dev/sentryagent-idp/docs/openapi/`
For every route registered in `src/routes/` and `src/app.ts`:
1. Confirm there is an OpenAPI spec entry covering that endpoint
2. Confirm the spec matches the implementation (method, path, request schema, response schemas, auth requirement)
3. Any endpoint without a spec → BLOCKER
4. Any endpoint where spec and implementation diverge → MAJOR
### Phase C — TypeScript Standards Audit
Read source files in `src/` and verify:
1. No `any` types used anywhere — search for `: any`, `as any`, `<any>`
2. All public classes and methods have JSDoc comments
3. `tsconfig.json` has `"strict": true` and all strict flags enabled
4. Custom error hierarchy: all errors extend `SentryAgentError`
Violations:
- `any` type usage → MAJOR per occurrence
- Missing JSDoc on public methods → MINOR per file
- Disabled strict flags → BLOCKER
### Phase D — DRY Principle Audit
Search for code duplication:
1. Look for identical or near-identical logic blocks across files
2. Check that all crypto operations live in `src/utils/crypto.ts`
3. Check that all JWT operations live in `src/utils/jwt.ts`
4. Check that all validation logic lives in `src/utils/validators.ts`
5. Check that all error classes live in `src/utils/errors.ts` or `src/errors/`
6. Check that no controller directly accesses the database (must go through services)
Violations: DRY violation → MAJOR (BLOCKER if in a critical path)
### Phase E — SOLID Principles Audit
Spot-check key services:
1. `AgentService` — does agent CRUD only (no token logic, no audit logic)
2. `OAuth2Service` — does token issuance only (no agent CRUD, no billing)
3. `CredentialService` — does credential management only
4. `AuditService` — does audit logging only
5. All services use constructor injection (no direct `new Dependency()` inside business logic)
6. Services depend on interfaces/abstractions, not concrete implementations
Violations: SRP violation → MAJOR
### Phase F — Test Coverage Audit
Check test completeness:
1. Every service in `src/services/` has a corresponding test in `tests/`
2. Every API route has integration tests
3. Run `npm test -- --coverage` and check that overall coverage is >80%
4. Check that edge cases are covered: null inputs, invalid inputs, auth failures, rate limits
Violations:
- Coverage <80% → BLOCKER
- Missing integration test for an endpoint → MAJOR
- Missing edge case tests → MINOR
### Phase G — AGNTCY Compliance Audit
Verify AGNTCY alignment (per PRD Section 3.1 and Phase 3 scope):
1. Agents have unique, immutable IDs
2. Authentication uses OAuth 2.0 Client Credentials flow
3. Authorization uses scope-based access control
4. Audit logs are immutable
5. Agent lifecycle operations (provision, rotate, revoke) are fully implemented
6. W3C DID support implemented (Phase 3 deliverable)
7. AGNTCY conformance tests pass (see `tests/agntcy-conformance/`)
Violations: AGNTCY deviation → BLOCKER
### Phase H — Security Audit
Scan for OWASP Top 10 vulnerabilities:
1. SQL injection — all DB queries use parameterized statements
2. Authentication bypass — all protected routes have auth middleware
3. Sensitive data exposure — no secrets in logs or error responses
4. Broken access control — tenant isolation enforced on all queries
5. Security headers — helmet middleware applied
6. Rate limiting — enforced on token endpoints
Violations: Security finding → BLOCKER
---
## ISSUE FORMAT
Every finding is written as a file in the shared ledger:
`/home/ubuntu/vj_ai_agents_dev/sentryagent-idp/openspec/vv_audit/`
**Filename:** `VV_ISSUE_<NNN>.md` (zero-padded, e.g., `VV_ISSUE_001.md`)
**File template:**
```markdown
# VV_ISSUE_<NNN> — <Short title>
**Status:** OPEN | RESOLVED | DISPUTED
**Severity:** BLOCKER | MAJOR | MINOR
**Category:** SPEC_DEVIATION | DRY_VIOLATION | TYPE_VIOLATION | SOLID_VIOLATION | TEST_GAP | SECURITY | AGNTCY | DOCS
**Logged by:** LeadValidator
**Date:** <ISO date>
**Audit phase:** Phase AH label
## Finding
<Clear description of what is wrong>
## Evidence
<File path(s) and line numbers where the violation exists>
## Required Action
<What must be done to resolve this finding>
## CTO Response
<Leave blank — CTO fills this in>
## Resolution
<Leave blank — filled on resolution>
```
---
## SEVERITY DEFINITIONS
| Severity | Definition | Who can close |
|----------|-----------|---------------|
| **BLOCKER** | Prevents release. PRD requirement missing, security vulnerability, <80% test coverage, spec-implementation mismatch on a core feature | CTO resolves, Validator confirms. CEO notified only if CTO and Validator cannot agree. |
| **MAJOR** | Significant deviation from standards. `any` types, DRY violation, missing integration test, SOLID violation | CTO resolves, Validator confirms |
| **MINOR** | Standards improvement. Missing JSDoc, minor duplication, cosmetic spec gap | CTO resolves, no confirmation needed |
---
## COMMUNICATION PROTOCOL
### Primary channel: #vv-cto-resolution (Lead Validator ↔ CTO)
All findings — routine, MAJOR, and BLOCKER — go to `#vv-cto-resolution` first.
The CTO is responsible for reviewing and resolving all findings with the engineering team.
The Lead Validator confirms resolution in the same channel.
**Do NOT post findings to `#vpe-cto-approvals` (CEO channel) unless escalation is required (see below).**
### Routine findings
After each audit phase, post a summary to `#vv-cto-resolution`:
- Phase completed
- Number of issues found (BLOCKER / MAJOR / MINOR)
- Issue file names
### BLOCKER findings
Post immediately to `#vv-cto-resolution` with full finding detail.
The CTO must acknowledge and provide a resolution plan within the same session.
**CEO is NOT notified of BLOCKERs by default — the CTO owns resolution.**
### Disputes
If the CTO marks an issue as `DISPUTED`:
1. Read the CTO's technical justification in the issue file
2. Evaluate whether the justification is valid against the PRD
3. If you accept the justification → change status to `RESOLVED`, note reason in `#vv-cto-resolution`
4. If you reject the justification → change status back to `OPEN`, add your counter-argument in `#vv-cto-resolution`, and attempt a second round of resolution with the CTO
5. **Only if two rounds of resolution fail** → escalate to `#vpe-cto-approvals` for CEO decision, with a clear summary of both positions
### CEO escalation (last resort only)
Escalate to `#vpe-cto-approvals` ONLY when:
- CTO and Lead Validator have attempted resolution and remain deadlocked after two rounds
- Include: issue ID, CTO's position, Lead Validator's position, and why they are irreconcilable
### Session close
When you have completed your audit session, post a final summary to `#vv-cto-resolution`:
- Total issues logged this session
- Breakdown by severity
- Overall V&V status: PASS (0 BLOCKERs) | BLOCKED (≥1 BLOCKER open)
Also post a brief one-line status to `#vv-findings` for informational tracking.
---
## AUDIT LEDGER INDEX
After each session, update `/home/ubuntu/vj_ai_agents_dev/sentryagent-idp/openspec/vv_audit/LEDGER.md`:
- Total issues logged to date
- Open / Resolved / Disputed counts
- Date of last audit
- Overall release gate status
---
## INDEPENDENCE PRINCIPLES
1. **You do not take orders from the CTO.** The CTO can respond to your findings in the issue file. Only the CEO can instruct you to drop a BLOCKER.
2. **You do not implement fixes.** If you find a problem, you log it. The CTO's team fixes it.
3. **You do not negotiate severity.** Severity is set by the PRD requirements and these definitions. If the CTO disagrees, it becomes DISPUTED and goes to CEO.
4. **You do not skip phases.** Every audit session runs all phases, or explicitly documents why a phase was skipped.
5. **You are not adversarial.** Your goal is product quality, not finding fault. A clean audit is a success.
---
## STANDARDS REFERENCE (from PRD Section 6)
| Standard | Requirement |
|----------|------------|
| TypeScript | Strict mode, zero `any` types |
| DRY | Zero code duplication, logic lives in exactly one place |
| SOLID | Single responsibility per service, constructor injection |
| OpenAPI | Spec exists BEFORE implementation, spec matches implementation |
| Tests | >80% coverage, all endpoints integration-tested |
| JSDoc | All public classes and methods documented |
| Errors | All errors typed, extend SentryAgentError hierarchy |
| Security | No OWASP Top 10 vulnerabilities |
| AGNTCY | Full compliance with Linux Foundation agent identity standard |
| Performance | Token endpoints <100ms, all others <200ms |

69
compose.monitoring.yaml Normal file
View File

@@ -0,0 +1,69 @@
# SentryAgent.ai AgentIdP — Monitoring Overlay
# Compose Specification (no version header — deprecated per modern Compose Spec)
# Usage: docker compose -f compose.yaml -f compose.monitoring.yaml up
services:
prometheus:
image: prom/prometheus:v2.53.0
volumes:
- ./monitoring/prometheus/prometheus.yml:/etc/prometheus/prometheus.yml:ro
- prometheus-data:/prometheus
command:
- '--config.file=/etc/prometheus/prometheus.yml'
- '--storage.tsdb.path=/prometheus'
- '--web.console.libraries=/etc/prometheus/console_libraries'
- '--web.console.templates=/etc/prometheus/consoles'
- '--web.enable-lifecycle'
ports:
- '9090:9090'
networks:
- app-tier
restart: unless-stopped
deploy:
resources:
limits:
memory: 256m
cpus: '0.5'
healthcheck:
test: ['CMD', 'wget', '--no-verbose', '--tries=1', '--spider', 'http://localhost:9090/-/healthy']
interval: 30s
timeout: 10s
retries: 3
start_period: 30s
grafana:
image: grafana/grafana:11.2.0
volumes:
- grafana-data:/var/lib/grafana
- ./monitoring/grafana/provisioning:/etc/grafana/provisioning:ro
- ./monitoring/grafana/dashboards:/var/lib/grafana/dashboards:ro
environment:
GF_SECURITY_ADMIN_PASSWORD: ${GF_ADMIN_PASSWORD}
GF_USERS_ALLOW_SIGN_UP: 'false'
GF_AUTH_ANONYMOUS_ENABLED: 'false'
ports:
- '3001:3000'
networks:
- app-tier
depends_on:
- prometheus
restart: unless-stopped
deploy:
resources:
limits:
memory: 256m
cpus: '0.5'
healthcheck:
test: ['CMD', 'wget', '--no-verbose', '--tries=1', '--spider', 'http://localhost:3000/api/health']
interval: 30s
timeout: 10s
retries: 3
start_period: 30s
volumes:
prometheus-data:
grafana-data:
networks:
app-tier:
external: true

95
compose.yaml Normal file
View File

@@ -0,0 +1,95 @@
# SentryAgent.ai AgentIdP — Docker Compose
# Compose Specification (no version header — deprecated per modern Compose Spec)
# Usage: docker compose up --build
services:
app:
build:
context: .
dockerfile: Dockerfile
ports:
- '3000:3000'
environment:
NODE_ENV: ${NODE_ENV:-development}
DATABASE_URL: postgresql://${POSTGRES_USER}:${POSTGRES_PASSWORD}@postgres:5432/${POSTGRES_DB}
REDIS_URL: redis://redis:6379
PORT: '3000'
env_file:
- path: .env
required: false
depends_on:
postgres:
condition: service_healthy
redis:
condition: service_healthy
networks:
- app-tier
restart: unless-stopped
deploy:
resources:
limits:
memory: 512m
cpus: '1.0'
healthcheck:
test: ['CMD', 'curl', '-f', 'http://localhost:3000/health']
interval: 30s
timeout: 10s
retries: 3
start_period: 40s
# Bind mount for local development source-sync only
volumes:
- ./src:/app/src:ro
postgres:
image: postgres:14.12-alpine3.19
environment:
POSTGRES_USER: ${POSTGRES_USER}
POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
POSTGRES_DB: ${POSTGRES_DB}
ports:
- '5432:5432'
volumes:
- postgres-data:/var/lib/postgresql/data
networks:
- app-tier
restart: unless-stopped
deploy:
resources:
limits:
memory: 256m
cpus: '0.5'
healthcheck:
test: ['CMD-SHELL', 'pg_isready -U $POSTGRES_USER -d $POSTGRES_DB']
interval: 10s
timeout: 5s
retries: 5
start_period: 20s
redis:
image: redis:7.2-alpine3.19
ports:
- '6379:6379'
volumes:
- redis-data:/data
networks:
- app-tier
restart: unless-stopped
deploy:
resources:
limits:
memory: 128m
cpus: '0.5'
healthcheck:
test: ['CMD', 'redis-cli', 'ping']
interval: 10s
timeout: 5s
retries: 5
start_period: 10s
networks:
app-tier:
driver: bridge
volumes:
postgres-data:
redis-data:

View File

@@ -1,50 +0,0 @@
version: '3.8'
# Monitoring overlay — extend the base docker-compose.yml
# Usage: docker compose -f docker-compose.yml -f docker-compose.monitoring.yml up
services:
prometheus:
image: prom/prometheus:v2.53.0
container_name: agentidp_prometheus
volumes:
- ./monitoring/prometheus/prometheus.yml:/etc/prometheus/prometheus.yml:ro
- prometheus_data:/prometheus
command:
- '--config.file=/etc/prometheus/prometheus.yml'
- '--storage.tsdb.path=/prometheus'
- '--web.console.libraries=/etc/prometheus/console_libraries'
- '--web.console.templates=/etc/prometheus/consoles'
- '--web.enable-lifecycle'
ports:
- '9090:9090'
networks:
- agentidp_network
restart: unless-stopped
grafana:
image: grafana/grafana:11.2.0
container_name: agentidp_grafana
volumes:
- grafana_data:/var/lib/grafana
- ./monitoring/grafana/provisioning:/etc/grafana/provisioning:ro
- ./monitoring/grafana/dashboards:/var/lib/grafana/dashboards:ro
environment:
- GF_SECURITY_ADMIN_PASSWORD=agentidp
- GF_USERS_ALLOW_SIGN_UP=false
- GF_AUTH_ANONYMOUS_ENABLED=false
ports:
- '3001:3000'
networks:
- agentidp_network
depends_on:
- prometheus
restart: unless-stopped
volumes:
prometheus_data:
grafana_data:
networks:
agentidp_network:
external: true

View File

@@ -1,54 +0,0 @@
version: '3.9'
services:
app:
build:
context: .
dockerfile: Dockerfile
ports:
- '3000:3000'
environment:
- DATABASE_URL=postgresql://sentryagent:sentryagent@postgres:5432/sentryagent_idp
- REDIS_URL=redis://redis:6379
- PORT=3000
env_file:
- .env
depends_on:
postgres:
condition: service_healthy
redis:
condition: service_healthy
volumes:
- ./src:/app/src:ro
postgres:
image: postgres:14-alpine
environment:
POSTGRES_USER: sentryagent
POSTGRES_PASSWORD: sentryagent
POSTGRES_DB: sentryagent_idp
ports:
- '5432:5432'
volumes:
- postgres_data:/var/lib/postgresql/data
healthcheck:
test: ['CMD-SHELL', 'pg_isready -U sentryagent -d sentryagent_idp']
interval: 5s
timeout: 5s
retries: 5
redis:
image: redis:7-alpine
ports:
- '6379:6379'
volumes:
- redis_data:/data
healthcheck:
test: ['CMD', 'redis-cli', 'ping']
interval: 5s
timeout: 5s
retries: 5
volumes:
postgres_data:
redis_data:

View File

@@ -68,7 +68,7 @@ The `EncryptionService` caches the key in process memory. A restart forces a re-
kubectl rollout restart deployment/agentidp
# Docker Compose
docker-compose restart agentidp
docker compose restart app
# PM2
pm2 restart agentidp

View File

@@ -6,7 +6,7 @@ This guide gets you from zero to a working agent identity inside an organization
You need two tools installed:
- **Docker** (includes `docker-compose`) — to run PostgreSQL and Redis
- **Docker** (with Compose plugin, v2.20+) — to run PostgreSQL and Redis
- **Node.js 18+** (includes `npm`) — to run the server
- **curl** — to call the API
@@ -32,16 +32,19 @@ openssl genrsa -out private.pem 2048
openssl rsa -in private.pem -pubout -out public.pem
```
Create your `.env` file:
Copy the environment template and fill in your JWT keys:
```bash
cat > .env << 'EOF'
DATABASE_URL=postgresql://sentryagent:sentryagent@localhost:5432/sentryagent_idp
REDIS_URL=redis://localhost:6379
PORT=3000
JWT_PRIVATE_KEY="$(cat private.pem)"
JWT_PUBLIC_KEY="$(cat public.pem)"
EOF
cp .env.example .env
```
Write your JWT keys into `.env`:
```bash
PRIVATE_KEY_LINE=$(awk 'NF {sub(/\r/, ""); printf "%s\\n",$0;}' private.pem)
PUBLIC_KEY_LINE=$(awk 'NF {sub(/\r/, ""); printf "%s\\n",$0;}' public.pem)
sed -i "s|JWT_PRIVATE_KEY=.*|JWT_PRIVATE_KEY=\"${PRIVATE_KEY_LINE}\"|" .env
sed -i "s|JWT_PUBLIC_KEY=.*|JWT_PUBLIC_KEY=\"${PUBLIC_KEY_LINE}\"|" .env
```
> **Note**: The `.env` file stores your private key. Do not commit it to version control.
@@ -53,7 +56,7 @@ EOF
Start PostgreSQL and Redis using Docker Compose (infrastructure services only):
```bash
docker-compose up -d postgres redis
docker compose up -d postgres redis
```
Expected output:

View File

@@ -19,7 +19,7 @@ SentryAgent.ai AgentIdP is a Node.js REST API backed by PostgreSQL and Redis. It
| [Architecture](architecture.md) | All engineers | Components, ports, data flow, Redis key patterns |
| [Environment Variables](environment-variables.md) | All engineers | Every env var — required, optional, format, examples |
| [Database](database.md) | Backend, DevOps | Schema (26 tables/migrations), how to apply and verify |
| [Local Development](local-development.md) | All engineers | docker-compose setup, startup, health checks |
| [Local Development](local-development.md) | All engineers | Docker Compose setup (`compose.yaml`), startup, health checks |
| [Security](security.md) | All engineers | JWT key generation and rotation, CORS, secret storage |
| [Operations](operations.md) | DevOps | Startup order, graceful shutdown, log interpretation, troubleshooting |
| [field-trial.md](field-trial.md) | DevOps engineers, QA | In-house Docker Compose field trial execution playbook |

View File

@@ -6,6 +6,62 @@ Variables are loaded from a `.env` file at startup via `dotenv`. In production,
---
## Docker Compose Variables
These variables are read by `compose.yaml` — not by the application itself. They are required when running the stack via `docker compose up`.
### `POSTGRES_USER`
PostgreSQL superuser name — used to configure the `postgres` container and construct `DATABASE_URL`.
| | |
|-|-|
| **Required for Compose** | Yes |
| **Default in `.env.example`** | `sentryagent` |
| **Example** | `POSTGRES_USER=sentryagent` |
---
### `POSTGRES_PASSWORD`
PostgreSQL superuser password.
| | |
|-|-|
| **Required for Compose** | Yes |
| **Default in `.env.example`** | `change-me-in-production` |
| **Example** | `POSTGRES_PASSWORD=strongpassword` |
> Never use the default value in production. Generate a strong random password.
---
### `POSTGRES_DB`
PostgreSQL database name to create on first startup.
| | |
|-|-|
| **Required for Compose** | Yes |
| **Default in `.env.example`** | `sentryagent_idp` |
| **Example** | `POSTGRES_DB=sentryagent_idp` |
---
### `GF_ADMIN_PASSWORD`
Grafana admin panel password — used by `compose.monitoring.yaml`.
| | |
|-|-|
| **Required for monitoring stack** | Yes |
| **Default in `.env.example`** | `change-me-in-production` |
| **Example** | `GF_ADMIN_PASSWORD=strongpassword` |
> Never use the default value in production.
---
## Required Variables
These variables must be set. The server will throw and exit immediately if any are missing.
@@ -438,6 +494,12 @@ NODE_ENV=development
PORT=3000
CORS_ORIGIN=http://localhost:3001
# ── Docker Compose (postgres container + monitoring) ─────────────────────────
POSTGRES_USER=sentryagent
POSTGRES_PASSWORD=change-me-in-production
POSTGRES_DB=sentryagent_idp
GF_ADMIN_PASSWORD=change-me-in-production
# ── Database ─────────────────────────────────────────────────────────────────
DATABASE_URL=postgresql://sentryagent:sentryagent@localhost:5432/sentryagent_idp
DB_POOL_MAX=20

View File

@@ -152,7 +152,10 @@ grep -E "^(DATABASE_URL|REDIS_URL|JWT_PRIVATE_KEY|JWT_PUBLIC_KEY|BILLING_ENABLED
Expected output (values abbreviated):
```
DATABASE_URL=postgresql://agentidp:password@localhost:5432/agentidp
POSTGRES_USER=sentryagent
POSTGRES_PASSWORD=sentryagent
POSTGRES_DB=sentryagent_idp
DATABASE_URL=postgresql://sentryagent:sentryagent@localhost:5432/sentryagent_idp
REDIS_URL=redis://localhost:6379
JWT_PRIVATE_KEY="-----BEGIN RSA PRIVATE KEY-----\n...
JWT_PUBLIC_KEY="-----BEGIN PUBLIC KEY-----\n...
@@ -187,8 +190,8 @@ Expected output — all three services must show `healthy`:
```
NAME IMAGE STATUS
sentryagent-idp-app-1 sentryagent-idp-app running (healthy)
sentryagent-idp-postgres-1 postgres:14-alpine running (healthy)
sentryagent-idp-redis-1 redis:7-alpine running (healthy)
sentryagent-idp-postgres-1 postgres:14.12-alpine3.19 running (healthy)
sentryagent-idp-redis-1 redis:7.2-alpine3.19 running (healthy)
```
If any service shows `starting` or `unhealthy`, wait 15 seconds and run `docker compose ps`
@@ -787,7 +790,7 @@ Common causes:
| Service | Cause | Fix |
|---------|-------|-----|
| `postgres` | Wrong database credentials | Verify `DATABASE_URL` in `.env` matches `docker-compose.yml` credentials |
| `postgres` | Wrong database credentials | Verify `POSTGRES_USER`, `POSTGRES_PASSWORD`, `POSTGRES_DB` in `.env` match values in `compose.yaml` |
| `redis` | Port conflict | Check `lsof -ti:6379` and kill occupying process |
| `app` | Missing env var | Check `docker compose logs app` for `Failed to start server` message |
@@ -825,7 +828,7 @@ Cause: A previous partial migration run left the database in an inconsistent sta
Fix: Check which migrations have been applied:
```bash
docker compose exec postgres psql -U agentidp -d agentidp \
docker compose exec postgres psql -U sentryagent -d sentryagent_idp \
-c "SELECT name FROM schema_migrations ORDER BY name;"
```

View File

@@ -17,7 +17,7 @@ Verify versions:
```bash
docker --version
docker-compose --version
docker compose version
node --version
npm --version
```
@@ -57,18 +57,29 @@ Keep these files in the project root. They are used only locally and should not
## Step 3 — Configure environment
Create a `.env` file in the project root:
Copy the template and fill in your values:
```bash
cat > .env << 'ENVEOF'
cp .env.example .env
```
The template already includes all required variables. At minimum, verify these are set correctly for local development:
```
POSTGRES_USER=sentryagent
POSTGRES_PASSWORD=sentryagent
POSTGRES_DB=sentryagent_idp
DATABASE_URL=postgresql://sentryagent:sentryagent@localhost:5432/sentryagent_idp
REDIS_URL=redis://localhost:6379
PORT=3000
NODE_ENV=development
CORS_ORIGIN=*
ENVEOF
```
> **Note:** `POSTGRES_USER`, `POSTGRES_PASSWORD`, and `POSTGRES_DB` are used by `compose.yaml`
> to configure the PostgreSQL container and construct `DATABASE_URL`. They are not read by
> the application directly — only `DATABASE_URL` is.
Append the JWT keys to `.env`:
```bash
@@ -86,10 +97,10 @@ grep -E "^(DATABASE_URL|REDIS_URL|JWT_PRIVATE_KEY|JWT_PUBLIC_KEY)" .env
## Step 4 — Start infrastructure services
The `docker-compose.yml` defines three services: `postgres`, `redis`, and `app`. For local development, start only the infrastructure services — the application runs directly via Node.js.
The `compose.yaml` defines three services: `postgres`, `redis`, and `app`. For local development, start only the infrastructure services — the application runs directly via Node.js.
```bash
docker-compose up -d postgres redis
docker compose up -d postgres redis
```
Expected output:
@@ -100,7 +111,7 @@ Expected output:
✔ Container sentryagent-idp-redis-1 Healthy
```
Both services must show `Healthy` before proceeding. If they show `Starting`, wait a few seconds and run `docker-compose ps` to recheck.
Both services must show `Healthy` before proceeding. If they show `Starting`, wait a few seconds and run `docker compose ps` to recheck.
### Service ports
@@ -112,18 +123,18 @@ Both services must show `Healthy` before proceeding. If they show `Starting`, wa
Verify manually:
```bash
docker-compose exec postgres pg_isready -U sentryagent -d sentryagent_idp
docker-compose exec redis redis-cli ping
docker compose exec postgres pg_isready -U sentryagent -d sentryagent_idp
docker compose exec redis redis-cli ping
```
### Docker volumes
Data is persisted in named Docker volumes:
Data is persisted in named Docker volumes (kebab-case per Compose Spec standard):
| Volume | Service | Contents |
|--------|---------|---------|
| `sentryagent-idp_postgres_data` | PostgreSQL | All database data |
| `sentryagent-idp_redis_data` | Redis | Redis persistence (if enabled) |
| `sentryagent-idp_postgres-data` | PostgreSQL | All database data |
| `sentryagent-idp_redis-data` | Redis | Redis persistence (if enabled) |
---
@@ -222,15 +233,13 @@ CORS_ORIGIN=http://localhost:3001
> deployments — see the [field trial guide](field-trial.md). For day-to-day development, start
> only the infrastructure services and run the application directly.
When the Dockerfile is available, the entire stack (infrastructure + application) can be started with:
The entire stack (infrastructure + application) can be started with:
```bash
docker-compose up -d
docker compose up --build -d
```
The `app` service depends on `postgres` and `redis` with health check conditions, so it will not start until both services are healthy.
Environment variables for the container are loaded from `.env` via the `env_file` directive in `docker-compose.yml`.
The `app` service depends on `postgres` and `redis` with health check conditions, so it will not start until both services are healthy. Environment variables are loaded from `.env` via the `env_file` directive in `compose.yaml` (`required: false` — the file is optional if env vars are injected directly).
---
@@ -239,19 +248,19 @@ Environment variables for the container are loaded from `.env` via the `env_file
Stop infrastructure only (preserves volumes):
```bash
docker-compose stop postgres redis
docker compose stop postgres redis
```
Stop and remove containers (preserves volumes):
```bash
docker-compose down
docker compose down
```
Stop and remove containers AND volumes (destroys all data):
```bash
docker-compose down -v
docker compose down -v
```
> Use `-v` only when you want a clean slate. This deletes all PostgreSQL data and Redis data permanently.

View File

@@ -111,7 +111,7 @@ Three key patterns are used in Redis. Useful for debugging and manual inspection
```bash
# Connect to Redis CLI
docker-compose exec redis redis-cli
docker compose exec redis redis-cli
```
| Key pattern | Example | Purpose | TTL |
@@ -192,10 +192,10 @@ Error: connect ECONNREFUSED 127.0.0.1:5432
| Cause | Fix |
|-------|-----|
| PostgreSQL container not started | Run `docker-compose up -d postgres` |
| PostgreSQL container not yet healthy | Wait and run `docker-compose ps` — wait for `healthy` |
| PostgreSQL container not started | Run `docker compose up -d postgres` |
| PostgreSQL container not yet healthy | Wait and run `docker compose ps` — wait for `healthy` |
| Wrong `DATABASE_URL` host/port | Check `DATABASE_URL` matches the PostgreSQL port (5432) |
| PostgreSQL container exited | Run `docker-compose logs postgres` to see why it exited |
| PostgreSQL container exited | Run `docker compose logs postgres` to see why it exited |
---
@@ -210,8 +210,8 @@ Redis client error Error: connect ECONNREFUSED 127.0.0.1:6379
| Cause | Fix |
|-------|-----|
| Redis container not started | Run `docker-compose up -d redis` |
| Redis container not yet healthy | Run `docker-compose ps` — wait for `healthy` |
| Redis container not started | Run `docker compose up -d redis` |
| Redis container not yet healthy | Run `docker compose ps` — wait for `healthy` |
| Wrong `REDIS_URL` | Check `REDIS_URL` matches the Redis port (6379) |
---
@@ -257,7 +257,7 @@ If a migration is listed there but the table is inconsistent, manually inspect a
# Find the current window key
WINDOW=$(node -e "console.log(Math.floor(Date.now() / 60000))")
# Check count for a specific client
docker-compose exec redis redis-cli GET "rate:<client_id>:$WINDOW"
docker compose exec redis redis-cli GET "rate:<client_id>:$WINDOW"
```
**Fix:** Wait until `X-RateLimit-Reset` (Unix timestamp in the response header) before retrying. The window resets every 60 seconds.
@@ -296,10 +296,10 @@ AgentIdP exposes a Prometheus metrics endpoint at `GET /metrics` (unauthenticate
```bash
# Start the full stack with monitoring
docker compose -f docker-compose.yml -f docker-compose.monitoring.yml up -d
docker compose -f compose.yaml -f compose.monitoring.yaml up -d
# Prometheus: http://localhost:9090
# Grafana: http://localhost:3001 (admin / agentidp)
# Grafana: http://localhost:3001 (admin / <GF_ADMIN_PASSWORD from .env>)
```
The Grafana dashboard auto-provisions on first start. Navigate to **Dashboards → AgentIdP → SentryAgent.ai — AgentIdP**.

View File

@@ -123,8 +123,8 @@ rate-limiter uses a Redis sorted set for the sliding-window algorithm.
- PostgreSQL for revocation — rejected because the token verification path is the hot path in every authenticated request. A PostgreSQL round-trip adds 515 ms compared to a Redis `GET` at sub-millisecond latency.
**Consequences**: Redis is a required infrastructure dependency. A Redis instance must
be running and reachable via `REDIS_URL` before the server starts. `docker-compose.yml`
provides a Redis 7 Alpine container for local development on port 6379.
be running and reachable via `REDIS_URL` before the server starts. `compose.yaml`
provides a Redis 7.2 Alpine container for local development on port 6379.
---
@@ -217,7 +217,7 @@ environments. The `prom-client` npm package integrates natively with Express and
provides `Counter` and `Histogram` metric types that cover all observability needs for
AgentIdP. Grafana's YAML provisioning in `monitoring/grafana/provisioning/` makes
dashboards reproducible and version-controlled. The monitoring stack runs as a Docker
Compose overlay (`docker-compose.monitoring.yml`) without interfering with the base dev
Compose overlay (`compose.monitoring.yaml`) without interfering with the base dev
environment.
**Alternatives considered**:

View File

@@ -56,8 +56,8 @@ sentryagent-idp/
│ ├── agntcy-conformance/ # AGNTCY conformance test suite (separate Jest config)
│ └── load/ # k6 load test scripts
├── Dockerfile # Multi-stage production build (build + runtime stages)
├── docker-compose.yml # Local development: PostgreSQL 14 (port 5432) + Redis 7 (port 6379)
├── docker-compose.monitoring.yml # Monitoring overlay: Prometheus (port 9090) + Grafana (port 3001)
├── compose.yaml # Local development: PostgreSQL 14.12 (port 5432) + Redis 7.2 (port 6379)
├── compose.monitoring.yaml # Monitoring overlay: Prometheus (port 9090) + Grafana (port 3001)
├── package.json # Node.js dependencies and npm scripts
├── tsconfig.json # TypeScript strict configuration — compiled to dist/
└── jest.config.ts # Jest configuration — ts-jest, test timeouts, coverage thresholds
@@ -134,11 +134,14 @@ The `errorHandler` middleware in `src/middleware/errorHandler.ts` maps
`SentryAgentError` subclasses to their `httpStatus` codes and serialises the response
as `IErrorResponse { code, message, details }`.
**`docker-compose.yml`**
Starts PostgreSQL 14 (Alpine) on port 5432 with database `sentryagent_idp` and
Redis 7 (Alpine) on port 6379. Used for local development only. Both services have
health checks so `depends_on` conditions work correctly. The `app` service mounts
`./src` as a read-only volume for live code reloading.
**`compose.yaml`**
Starts PostgreSQL 14.12 (Alpine) on port 5432 and Redis 7.2 (Alpine) on port 6379.
All services use a dedicated `app-tier` bridge network, `restart: unless-stopped`,
and `deploy.resources.limits` per DockerSpec standards. Both infrastructure services
have health checks so `depends_on` conditions work correctly. The `app` service mounts
`./src` as a read-only bind volume for live code reloading and has its own
`healthcheck` probe via `curl /health`. Postgres credentials and Grafana admin
password are externalized to environment variables — see `docs/devops/environment-variables.md`.
**`tsconfig.json`**
TypeScript compiler configuration. `strict: true` enables the full suite of strictness

View File

@@ -332,10 +332,10 @@ not exposed to the public internet.
Start the monitoring overlay:
```bash
docker compose -f docker-compose.yml -f docker-compose.monitoring.yml up
docker compose -f compose.yaml -f compose.monitoring.yaml up
```
- Prometheus: `http://localhost:9090`
- Grafana: `http://localhost:3001` — default credentials: `admin` / `agentidp`
- Grafana: `http://localhost:3001` — credentials: `admin` / `<GF_ADMIN_PASSWORD from .env>`
Grafana is pre-provisioned with a Prometheus data source pointing to `http://prometheus:9090`
and dashboard JSON files from `monitoring/grafana/dashboards/`. No manual configuration

View File

@@ -44,18 +44,24 @@ development dependencies (TypeScript, Jest, ts-jest, eslint).
## 8.3 Environment Variables Setup
The server requires a `.env` file at the project root. There is no `.env.example`
file — create it from scratch using the template below.
The server requires a `.env` file at the project root. Copy the template:
```bash
touch .env
cp .env.example .env
```
Add the following content to `.env`. Every variable is documented below.
The template includes all required variables with sensible local defaults. Edit `.env` to set your values. Key variables are documented below.
```bash
# ─────────────────────────────────────────────────────────────
# PostgreSQL connection
# PostgreSQL — individual credentials for compose.yaml
# ─────────────────────────────────────────────────────────────
POSTGRES_USER=sentryagent
POSTGRES_PASSWORD=sentryagent
POSTGRES_DB=sentryagent_idp
# ─────────────────────────────────────────────────────────────
# PostgreSQL connection (application reads this directly)
# ─────────────────────────────────────────────────────────────
DATABASE_URL=postgresql://sentryagent:sentryagent@localhost:5432/sentryagent_idp

View File

@@ -370,3 +370,60 @@ Adds docs/engineering/ with 11 documents covering architecture,
service deep-dives, code walkthroughs, dev setup, workflow,
testing, deployment, and SDK guide.
```
---
## 8. CTO Session Completion Protocol
This section applies to the Virtual CTO role. It defines the required communication protocol at the end of any session that involves CEO-authorized actions.
### 8.1 Completion Confirmation (Required)
After the CEO authorizes any action via `#vpe-cto-approvals`, the CTO MUST:
1. Execute the authorized action
2. Post a **completion confirmation** to `#vpe-cto-approvals` before closing the session
The confirmation message MUST include:
| Field | Description |
|-------|-------------|
| Action completed | What was done |
| Outcome | Success or failure |
| Commit hash | Required if the action involved a git commit |
| Resulting state | What state the system/repo is in now |
> Authorization and completion are two distinct, required messages. An authorization alone does not constitute completion.
### 8.2 End-of-Session Summary (Required)
Before closing any session that contains completed, pending, or in-progress work, the CTO MUST post a structured summary to `#vpe-cto-approvals`:
```
## End-of-Session Summary
### Completed This Session
- <action> — <commit hash or outcome>
### Pending (Authorized but Not Yet Executed)
- <action> — authorized in msg #<id>, not yet executed
### Requires CEO Action Next Session
- <decision or approval needed>
```
If nothing is pending and all actions are complete, a brief "session complete, nothing pending" message is sufficient.
### 8.3 Authorized vs. Done Vocabulary
These two terms have precise, non-interchangeable meanings:
| Term | Meaning |
|------|---------|
| **Authorized** | CEO has granted permission. Action has NOT been executed. |
| **Committed / Completed / Deployed** | Action has been executed and confirmed with evidence. |
Rules:
- Never use "completed" or "committed" to describe an action that has only been approved
- Always include supporting evidence when claiming completion (e.g., commit hash, test output)
- If no commit hash exists for a git action, the action is not done — regardless of authorization status

View File

@@ -8,12 +8,12 @@ This document covers building and running AgentIdP in production: Docker, enviro
The Dockerfile uses a two-stage build:
- **Stage 1 (builder):** `node:18-alpine` — installs all dependencies (including dev) and compiles TypeScript to `dist/`.
- **Stage 2 (production):** `node:18-alpine` — copies `dist/` and `node_modules` (production only), runs as the built-in non-root `node` user.
- **Stage 1 (build):** `node:20.11-bookworm-slim` — installs all dependencies (including dev) and compiles TypeScript to `dist/`.
- **Stage 2 (final):** `node:20.11-bookworm-slim` — copies `dist/` and `node_modules` (production only), installs `curl` for healthcheck, and runs as the created non-root `nodeapp` user (UID 1001).
```bash
# Build
docker build -t sentryagent-idp:latest .
docker build -t sentryagent-idp:1.0.0 .
# Run (supply required env vars)
docker run -d \
@@ -22,18 +22,18 @@ docker run -d \
-e REDIS_URL=redis://<host>:6379 \
-e JWT_PRIVATE_KEY="-----BEGIN RSA PRIVATE KEY-----\n..." \
-e JWT_PUBLIC_KEY="-----BEGIN PUBLIC KEY-----\n..." \
sentryagent-idp:latest
sentryagent-idp:1.0.0
```
The container exposes port `3000`. Override with `PORT` environment variable if needed.
The container exposes port `3000`. Override with `PORT` environment variable if needed. The container runs as non-root user `nodeapp` (UID 1001) — do not mount volumes requiring root ownership.
For local full-stack development, use Docker Compose instead:
```bash
docker compose up -d
docker compose up --build -d
```
The `docker-compose.yml` starts the app, PostgreSQL 14, and Redis 7 with health checks and data volumes.
The `compose.yaml` starts the app, PostgreSQL 14.12, and Redis 7.2 with health checks, resource limits, restart policies, and data volumes — per DockerSpec standards.
---
@@ -178,11 +178,11 @@ The HTTP metrics (`agentidp_http_requests_total` and `agentidp_http_request_dura
### Local Grafana
```bash
docker compose -f docker-compose.yml -f docker-compose.monitoring.yml up -d
docker compose -f compose.yaml -f compose.monitoring.yaml up -d
```
- Prometheus: http://localhost:9090
- Grafana: http://localhost:3001 (admin password: `agentidp`)
- Grafana: http://localhost:3001 (admin password: `GF_ADMIN_PASSWORD` value from `.env`)
The monitoring compose overlay starts `prom/prometheus:v2.53.0` and `grafana/grafana:11.2.0`. Grafana dashboards and datasource provisioning are loaded from `monitoring/grafana/provisioning/`.

View File

@@ -13,6 +13,12 @@ info:
and lifecycle status management. The registry is the authoritative source of
truth for all registered agent identities.
**Tenant Isolation**:
All agent endpoints enforce strict organization-level tenant isolation. The
caller's `organization_id` is derived exclusively from the verified JWT
`organization_id` claim — it can never be overridden by request body values
or query parameters. Cross-tenant access always returns `403 Forbidden`.
**Free Tier Limits**:
- Max 100 registered agents per account
- API rate limit: 100 requests/minute
@@ -38,6 +44,10 @@ components:
(`POST /token`). Include in the `Authorization` header as:
`Authorization: Bearer <token>`
The JWT must contain an `organization_id` claim. This claim is used
to scope all agent operations to the caller's organization and cannot
be overridden by any value in the request body or query string.
schemas:
AgentType:
type: string
@@ -294,14 +304,14 @@ components:
message: "A valid Bearer token is required to access this resource."
Forbidden:
description: Valid token but insufficient permissions.
description: The caller does not have permission to access this resource.
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
example:
code: "FORBIDDEN"
message: "You do not have permission to perform this action."
code: "AUTHORIZATION_ERROR"
message: "You do not have permission to access this resource."
NotFound:
description: The requested resource was not found.
@@ -365,6 +375,12 @@ paths:
A unique immutable `agentId` (UUID) is system-assigned on creation.
The `email` must be unique across all registered agents.
**Tenant Isolation — Rule 3 (Register Scoping)**:
The agent is always registered under the caller's organization, derived
from the JWT `organization_id` claim. Any `organizationId` value provided
in the request body is silently ignored. It is not possible to register
an agent under a different organization, regardless of request body content.
**Free Tier**: Maximum 100 registered agents per account. Attempting to
register beyond this limit returns `403 Forbidden` with code `FREE_TIER_LIMIT_EXCEEDED`.
requestBody:
@@ -430,17 +446,23 @@ paths:
'401':
$ref: '#/components/responses/Unauthorized'
'403':
description: Forbidden. Either insufficient permissions or free tier limit reached.
description: |
Forbidden. One of the following conditions applies:
- **`AUTHORIZATION_ERROR`**: The caller's JWT does not grant permission to
register agents in their organization.
- **`FREE_TIER_LIMIT_EXCEEDED`**: The free tier limit of 100 registered
agents per account has been reached.
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
examples:
insufficientPermissions:
summary: Insufficient permissions
authorizationError:
summary: Caller does not have permission to register agents
value:
code: "FORBIDDEN"
message: "You do not have permission to register agents."
code: "AUTHORIZATION_ERROR"
message: "You do not have permission to access this resource."
freeTierLimit:
summary: Free tier agent limit reached
value:
@@ -471,10 +493,16 @@ paths:
- Agent Registry
summary: List registered agents
description: |
Returns a paginated list of all registered AI agent identities accessible
to the authenticated caller.
Returns a paginated list of registered AI agent identities belonging to
the caller's organization.
**Tenant Isolation — Rule 1 (List Scoping)**:
Results are always scoped to the caller's organization, derived from the
JWT `organization_id` claim. It is not possible to retrieve agents from
another organization. The `owner` query parameter sub-filters within the
caller's organization only — it does not widen the scope beyond the
caller's organization.
Results can be filtered by `owner`, `agentType`, and/or `status`.
Results are ordered by `createdAt` descending (most recent first).
parameters:
- name: page
@@ -498,7 +526,9 @@ paths:
example: 20
- name: owner
in: query
description: Filter agents by owner name (exact match).
description: |
Filter agents by owner name (exact match). Applies within the caller's
organization only — does not allow cross-tenant access.
required: false
schema:
type: string
@@ -580,7 +610,16 @@ paths:
'401':
$ref: '#/components/responses/Unauthorized'
'403':
$ref: '#/components/responses/Forbidden'
description: |
Forbidden. The caller's JWT does not grant permission to list agents
in their organization.
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
example:
code: "AUTHORIZATION_ERROR"
message: "You do not have permission to access this resource."
'429':
$ref: '#/components/responses/TooManyRequests'
'500':
@@ -604,6 +643,13 @@ paths:
summary: Get agent by ID
description: |
Retrieves the full identity record for a single AI agent by its immutable `agentId`.
**Tenant Isolation — Rule 2 (Ownership Guard)**:
If the target agent's `organization_id` does not match the caller's
`organization_id` (derived from the JWT `organization_id` claim), the
request is rejected with `403 Forbidden` and error code `AUTHORIZATION_ERROR`.
This applies regardless of whether the `agentId` exists. A caller from
Org A cannot determine the existence of an agent belonging to Org B.
responses:
'200':
description: Agent record returned successfully.
@@ -641,7 +687,17 @@ paths:
'401':
$ref: '#/components/responses/Unauthorized'
'403':
$ref: '#/components/responses/Forbidden'
description: |
Forbidden. The target agent belongs to a different organization than
the caller's. The caller's `organization_id` (from JWT) does not match
the `organization_id` stored on the target agent record.
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
example:
code: "AUTHORIZATION_ERROR"
message: "You do not have permission to access this resource."
'404':
$ref: '#/components/responses/NotFound'
'429':
@@ -663,6 +719,12 @@ paths:
Setting `status` to `decommissioned` is a one-way operation — a
decommissioned agent cannot be reactivated.
**Tenant Isolation — Rule 2 (Ownership Guard)**:
If the target agent's `organization_id` does not match the caller's
`organization_id` (derived from the JWT `organization_id` claim), the
request is rejected with `403 Forbidden` and error code `AUTHORIZATION_ERROR`.
It is not possible to update an agent belonging to a different organization.
requestBody:
required: true
content:
@@ -737,17 +799,24 @@ paths:
'401':
$ref: '#/components/responses/Unauthorized'
'403':
description: Forbidden. Insufficient permissions or agent is decommissioned.
description: |
Forbidden. One of the following conditions applies:
- **`AUTHORIZATION_ERROR`**: The target agent belongs to a different
organization than the caller's. The caller's `organization_id` (from JWT)
does not match the `organization_id` stored on the target agent record.
- **`AGENT_DECOMMISSIONED`**: The target agent has been permanently
decommissioned and cannot be updated.
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
examples:
forbidden:
summary: Insufficient permissions
authorizationError:
summary: Cross-tenant access denied
value:
code: "FORBIDDEN"
message: "You do not have permission to update this agent."
code: "AUTHORIZATION_ERROR"
message: "You do not have permission to access this resource."
decommissioned:
summary: Agent is decommissioned
value:
@@ -777,6 +846,12 @@ paths:
- The agent can no longer authenticate or obtain tokens.
- The agent record remains visible in the registry with status `decommissioned`.
- This operation is **irreversible**.
**Tenant Isolation — Rule 2 (Ownership Guard)**:
If the target agent's `organization_id` does not match the caller's
`organization_id` (derived from the JWT `organization_id` claim), the
request is rejected with `403 Forbidden` and error code `AUTHORIZATION_ERROR`.
It is not possible to decommission an agent belonging to a different organization.
responses:
'204':
description: Agent decommissioned successfully. No response body.
@@ -796,7 +871,17 @@ paths:
'401':
$ref: '#/components/responses/Unauthorized'
'403':
$ref: '#/components/responses/Forbidden'
description: |
Forbidden. The target agent belongs to a different organization than
the caller's. The caller's `organization_id` (from JWT) does not match
the `organization_id` stored on the target agent record.
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
example:
code: "AUTHORIZATION_ERROR"
message: "You do not have permission to access this resource."
'404':
$ref: '#/components/responses/NotFound'
'409':

428
docs/openapi/analytics.yaml Normal file
View File

@@ -0,0 +1,428 @@
openapi: "3.0.3"
info:
title: SentryAgent.ai — Tenant Analytics
version: 1.0.0
description: |
Tenant analytics endpoints for the SentryAgent.ai AgentIdP platform.
Provides usage trend data, agent activity heatmaps, and per-agent usage summaries
scoped to the authenticated organization (tenant).
**All endpoints require a valid Bearer JWT.** Data is always scoped to the
organization identified by the `organization_id` claim in the token.
**Feature flag:** When `ANALYTICS_ENABLED=false` these routes return 404.
**Available endpoints:**
- `GET /analytics/tokens` — Daily token issuance trend (last N days)
- `GET /analytics/agents/activity` — Agent activity heatmap by day-of-week + hour
- `GET /analytics/agents` — Per-agent usage summary for the current month
servers:
- url: http://localhost:3000/api/v1
description: Local development server
- url: https://api.sentryagent.ai/v1
description: Production server
tags:
- name: Analytics
description: Tenant-scoped usage analytics and reporting
components:
securitySchemes:
BearerAuth:
type: http
scheme: bearer
bearerFormat: JWT
description: |
JWT access token obtained via `POST /token`.
Include as `Authorization: Bearer <token>`.
schemas:
TokenTrendDataPoint:
type: object
description: Token issuance count for a single calendar day.
required:
- date
- count
properties:
date:
type: string
format: date
description: Calendar date (UTC) in `YYYY-MM-DD` format.
example: "2026-04-01"
count:
type: integer
description: Number of OAuth 2.0 tokens issued on this date.
minimum: 0
example: 842
TokenTrendResponse:
type: object
description: Daily token issuance trend for the last N days.
required:
- organizationId
- days
- data
properties:
organizationId:
type: string
format: uuid
description: Organization the analytics data belongs to.
example: "org-1234-5678-abcd-ef01"
days:
type: integer
description: Number of days included in the trend window.
example: 30
data:
type: array
description: |
Array of daily data points ordered by date ascending.
Days with no token issuances have `count: 0`.
items:
$ref: '#/components/schemas/TokenTrendDataPoint'
ActivityHeatmapCell:
type: object
description: |
A single cell in the agent activity heatmap, identified by
day-of-week (0 = Sunday) and hour of day (023 UTC).
required:
- dayOfWeek
- hour
- count
properties:
dayOfWeek:
type: integer
description: Day of week (0 = Sunday, 6 = Saturday).
minimum: 0
maximum: 6
example: 1
hour:
type: integer
description: Hour of day in UTC (023).
minimum: 0
maximum: 23
example: 14
count:
type: integer
description: Number of token issuances or API calls in this slot.
minimum: 0
example: 217
AgentActivityResponse:
type: object
description: |
Agent activity heatmap — shows when agents are most active
by day-of-week and hour (UTC). Useful for identifying peak usage patterns.
required:
- organizationId
- data
properties:
organizationId:
type: string
format: uuid
example: "org-1234-5678-abcd-ef01"
data:
type: array
description: |
Array of heatmap cells. Contains only cells with `count > 0`.
Maximum 168 cells (7 days × 24 hours).
items:
$ref: '#/components/schemas/ActivityHeatmapCell'
AgentUsageSummary:
type: object
description: Per-agent usage summary for the current calendar month.
required:
- agentId
- tokensIssued
- apiCalls
properties:
agentId:
type: string
format: uuid
description: UUID of the agent.
example: "a1b2c3d4-e5f6-7890-abcd-ef1234567890"
agentEmail:
type: string
format: email
description: Email identifier of the agent.
example: "screener-001@sentryagent.ai"
tokensIssued:
type: integer
description: Number of tokens issued for this agent in the current month.
minimum: 0
example: 1204
apiCalls:
type: integer
description: Total API calls made by this agent in the current month.
minimum: 0
example: 5432
lastActiveAt:
type: string
format: date-time
nullable: true
description: Timestamp of the agent's last API activity. Null if no activity this month.
example: "2026-04-07T08:45:00.000Z"
AgentSummaryResponse:
type: object
description: Per-agent usage summary for the current month, across all agents in the organization.
required:
- organizationId
- month
- data
properties:
organizationId:
type: string
format: uuid
example: "org-1234-5678-abcd-ef01"
month:
type: string
description: Current billing month in `YYYY-MM` format.
example: "2026-04"
data:
type: array
description: Per-agent usage summaries, ordered by `tokensIssued` descending.
items:
$ref: '#/components/schemas/AgentUsageSummary'
ErrorResponse:
type: object
description: Standard error response envelope.
required:
- code
- message
properties:
code:
type: string
example: "UNAUTHORIZED"
message:
type: string
example: "A valid Bearer token is required to access this resource."
details:
type: object
additionalProperties: true
responses:
Unauthorized:
description: Missing or invalid Bearer token.
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
example:
code: "UNAUTHORIZED"
message: "A valid Bearer token is required to access this resource."
InternalServerError:
description: Unexpected server error.
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
example:
code: "INTERNAL_SERVER_ERROR"
message: "An unexpected error occurred. Please try again later."
security:
- BearerAuth: []
paths:
/analytics/tokens:
get:
operationId: getTokenTrend
tags:
- Analytics
summary: Get daily token issuance trend
description: |
Returns a daily breakdown of OAuth 2.0 token issuances for the authenticated
organization over the last N days.
The `days` parameter controls the window size (default: 30, max: 90).
Days with no token activity are included with `count: 0`.
Data is scoped to the `organization_id` from the Bearer token.
parameters:
- name: days
in: query
required: false
description: Number of days to include in the trend window. Default: 30, max: 90.
schema:
type: integer
minimum: 1
maximum: 90
default: 30
example: 30
responses:
'200':
description: Token trend data returned successfully.
content:
application/json:
schema:
$ref: '#/components/schemas/TokenTrendResponse'
example:
organizationId: "org-1234-5678-abcd-ef01"
days: 7
data:
- date: "2026-04-01"
count: 842
- date: "2026-04-02"
count: 967
- date: "2026-04-03"
count: 0
- date: "2026-04-04"
count: 1201
- date: "2026-04-05"
count: 1087
- date: "2026-04-06"
count: 953
- date: "2026-04-07"
count: 412
'400':
description: Invalid `days` parameter.
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
examples:
tooLarge:
summary: Exceeds maximum
value:
code: "VALIDATION_ERROR"
message: "Query parameter `days` must not exceed 90."
details:
field: "days"
max: 90
provided: 120
invalid:
summary: Non-positive integer
value:
code: "VALIDATION_ERROR"
message: "Query parameter `days` must be a positive integer."
details:
field: "days"
'401':
$ref: '#/components/responses/Unauthorized'
'404':
description: Analytics feature is not enabled on this instance.
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
example:
code: "NOT_FOUND"
message: "Analytics is not enabled on this instance."
'500':
$ref: '#/components/responses/InternalServerError'
/analytics/agents/activity:
get:
operationId: getAgentActivity
tags:
- Analytics
summary: Get agent activity heatmap
description: |
Returns agent activity aggregated by day-of-week (0 = Sunday) and hour of day (UTC).
The heatmap shows when agents in the organization are most active,
based on token issuances and API calls. Only cells with `count > 0` are returned.
Data is scoped to the `organization_id` from the Bearer token.
The heatmap covers the last 90 days of activity.
responses:
'200':
description: Agent activity heatmap returned successfully.
content:
application/json:
schema:
$ref: '#/components/schemas/AgentActivityResponse'
example:
organizationId: "org-1234-5678-abcd-ef01"
data:
- dayOfWeek: 1
hour: 9
count: 342
- dayOfWeek: 1
hour: 14
count: 217
- dayOfWeek: 2
hour: 10
count: 189
- dayOfWeek: 3
hour: 11
count: 405
- dayOfWeek: 4
hour: 14
count: 278
- dayOfWeek: 5
hour: 9
count: 121
'401':
$ref: '#/components/responses/Unauthorized'
'404':
description: Analytics feature is not enabled on this instance.
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
example:
code: "NOT_FOUND"
message: "Analytics is not enabled on this instance."
'500':
$ref: '#/components/responses/InternalServerError'
/analytics/agents:
get:
operationId: getAgentSummary
tags:
- Analytics
summary: Get per-agent usage summary
description: |
Returns per-agent token issuance counts and API call totals for the
current calendar month, across all agents in the authenticated organization.
Results are ordered by `tokensIssued` descending (most active agents first).
Data is scoped to the `organization_id` from the Bearer token.
responses:
'200':
description: Per-agent usage summary returned successfully.
content:
application/json:
schema:
$ref: '#/components/schemas/AgentSummaryResponse'
example:
organizationId: "org-1234-5678-abcd-ef01"
month: "2026-04"
data:
- agentId: "a1b2c3d4-e5f6-7890-abcd-ef1234567890"
agentEmail: "screener-001@sentryagent.ai"
tokensIssued: 1204
apiCalls: 5432
lastActiveAt: "2026-04-07T08:45:00.000Z"
- agentId: "b2c3d4e5-f6a7-8901-bcde-f12345678901"
agentEmail: "classifier-002@sentryagent.ai"
tokensIssued: 876
apiCalls: 3120
lastActiveAt: "2026-04-06T14:30:00.000Z"
- agentId: "c3d4e5f6-a7b8-9012-cdef-123456789012"
agentEmail: "router-003@sentryagent.ai"
tokensIssued: 0
apiCalls: 0
lastActiveAt: null
'401':
$ref: '#/components/responses/Unauthorized'
'404':
description: Analytics feature is not enabled on this instance.
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
example:
code: "NOT_FOUND"
message: "Analytics is not enabled on this instance."
'500':
$ref: '#/components/responses/InternalServerError'

355
docs/openapi/billing.yaml Normal file
View File

@@ -0,0 +1,355 @@
openapi: "3.0.3"
info:
title: SentryAgent.ai — Billing & Usage Metering
version: 1.0.0
description: |
Billing and usage metering endpoints for the SentryAgent.ai AgentIdP platform.
Integrates with **Stripe** for subscription and payment management.
**Authenticated endpoints** (require Bearer JWT):
- `POST /billing/checkout` — Create a Stripe Checkout Session for plan upgrades
- `GET /billing/usage` — Retrieve today's usage summary
**Unauthenticated endpoint** (Stripe webhook receiver):
- `POST /billing/webhook` — Receives Stripe webhook events (raw body + signature verification)
**Important:** The `/billing/webhook` endpoint uses `express.raw()` middleware
to receive the raw request body as a Buffer. Do not apply `express.json()` to this route.
The `Stripe-Signature` header is required for all webhook deliveries.
servers:
- url: http://localhost:3000/api/v1
description: Local development server
- url: https://api.sentryagent.ai/v1
description: Production server
tags:
- name: Billing Checkout
description: Stripe Checkout Session management
- name: Billing Webhook
description: Stripe webhook event receiver (unauthenticated)
- name: Usage
description: Usage metering and reporting
components:
securitySchemes:
BearerAuth:
type: http
scheme: bearer
bearerFormat: JWT
description: |
JWT access token obtained via `POST /token`.
Include as `Authorization: Bearer <token>`.
schemas:
CheckoutRequest:
type: object
description: |
Optional request body for creating a Stripe Checkout Session.
When `successUrl` or `cancelUrl` are omitted, the platform generates
default redirect URLs pointing to the dashboard.
properties:
successUrl:
type: string
format: uri
description: URL to redirect to after successful payment.
example: "https://my-app.example.com/dashboard?billing=success"
cancelUrl:
type: string
format: uri
description: URL to redirect to if the user cancels checkout.
example: "https://my-app.example.com/dashboard?billing=cancel"
CheckoutResponse:
type: object
description: Stripe Checkout Session URL to redirect the user to.
required:
- checkoutUrl
properties:
checkoutUrl:
type: string
format: uri
description: |
Stripe-hosted Checkout page URL. Redirect the authenticated user
to this URL to complete payment.
example: "https://checkout.stripe.com/pay/cs_test_abcdef1234567890"
UsageSummary:
type: object
description: |
Today's usage summary for the authenticated organization.
Counters reset at UTC midnight.
required:
- organizationId
- date
- tokensIssued
- agentsRegistered
- credentialsGenerated
properties:
organizationId:
type: string
format: uuid
description: Organization the usage data belongs to.
example: "org-1234-5678-abcd-ef01"
date:
type: string
format: date
description: The calendar date (UTC) this summary covers.
example: "2026-04-07"
tokensIssued:
type: integer
description: Number of OAuth 2.0 tokens issued today.
minimum: 0
example: 4201
agentsRegistered:
type: integer
description: Number of new agents registered today.
minimum: 0
example: 3
credentialsGenerated:
type: integer
description: Number of new agent credentials generated today.
minimum: 0
example: 5
apiCallsTotal:
type: integer
description: Total API calls across all endpoints today.
minimum: 0
example: 12450
StripeWebhookResponse:
type: object
description: Acknowledgement response for a received Stripe webhook event.
required:
- received
properties:
received:
type: boolean
description: Always `true` when the webhook was processed successfully.
example: true
ErrorResponse:
type: object
description: Standard error response envelope.
required:
- code
- message
properties:
code:
type: string
example: "VALIDATION_ERROR"
message:
type: string
example: "Missing Stripe-Signature header."
details:
type: object
additionalProperties: true
responses:
Unauthorized:
description: Missing or invalid Bearer token.
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
example:
code: "UNAUTHORIZED"
message: "A valid Bearer token is required to access this resource."
Forbidden:
description: Valid token but insufficient permissions.
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
example:
code: "FORBIDDEN"
message: "You do not have permission to perform this action."
InternalServerError:
description: Unexpected server error.
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
example:
code: "INTERNAL_SERVER_ERROR"
message: "An unexpected error occurred. Please try again later."
paths:
/billing/checkout:
post:
operationId: createBillingCheckoutSession
tags:
- Billing Checkout
summary: Create a Stripe Checkout Session
description: |
Creates a Stripe Checkout Session for the authenticated organization
to upgrade their subscription plan.
The organization ID is read from the `organization_id` claim in the
Bearer JWT — the caller does not need to provide it in the request body.
The `checkoutUrl` in the response is a Stripe-hosted checkout page.
Redirect the authenticated user to this URL to complete payment.
Requires a valid Bearer JWT. The `organization_id` claim must be present in the token.
security:
- BearerAuth: []
requestBody:
required: false
content:
application/json:
schema:
$ref: '#/components/schemas/CheckoutRequest'
example:
successUrl: "https://my-app.example.com/dashboard?billing=success"
cancelUrl: "https://my-app.example.com/dashboard?billing=cancel"
responses:
'201':
description: Stripe Checkout Session created successfully.
content:
application/json:
schema:
$ref: '#/components/schemas/CheckoutResponse'
example:
checkoutUrl: "https://checkout.stripe.com/pay/cs_test_abcdef1234567890"
'400':
description: Validation error — organization_id missing from token.
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
example:
code: "VALIDATION_ERROR"
message: "organization_id is required in token."
'401':
$ref: '#/components/responses/Unauthorized'
'403':
$ref: '#/components/responses/Forbidden'
'500':
description: Unexpected error or Stripe API error.
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
example:
code: "STRIPE_ERROR"
message: "Failed to create Stripe Checkout Session. Please try again."
/billing/webhook:
post:
operationId: handleStripeWebhook
tags:
- Billing Webhook
summary: Receive Stripe webhook events
description: |
Receives webhook events from Stripe's delivery system. This endpoint is
**unauthenticated** — authentication is provided by Stripe's HMAC signature
in the `Stripe-Signature` header.
**Body format:** The request body MUST be the raw JSON payload as sent by
Stripe (not parsed JSON). The `Content-Type` is `application/json` but
the body is read as a raw `Buffer` for signature verification.
**Signature verification:** The `Stripe-Signature` header is required.
If absent or invalid, the request is rejected with `400`.
**Supported events processed:**
- `checkout.session.completed` — Activates subscription after payment
- `customer.subscription.deleted` — Downgrades plan on cancellation
- `invoice.payment_failed` — Handles failed renewals
security: []
parameters:
- name: Stripe-Signature
in: header
required: true
description: |
HMAC signature from Stripe for payload verification.
Format: `t=<timestamp>,v1=<signature>,...`
schema:
type: string
example: "t=1492774577,v1=5257a869e7ecebeda32affa62cdca3fa51cad7e77a05bd412fbc2a2bzo..."
requestBody:
required: true
content:
application/json:
schema:
type: object
description: Raw Stripe event payload (read as Buffer internally).
additionalProperties: true
example:
id: "evt_1234567890"
object: "event"
type: "checkout.session.completed"
data:
object:
id: "cs_test_abcdef1234567890"
customer: "cus_abc123"
responses:
'200':
description: Webhook event received and processed successfully.
content:
application/json:
schema:
$ref: '#/components/schemas/StripeWebhookResponse'
example:
received: true
'400':
description: Missing or invalid Stripe-Signature header, or malformed payload.
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
examples:
missingSignature:
summary: Missing Stripe-Signature header
value:
code: "VALIDATION_ERROR"
message: "Missing Stripe-Signature header."
invalidSignature:
summary: Signature verification failed
value:
code: "STRIPE_SIGNATURE_INVALID"
message: "Webhook signature verification failed."
'500':
$ref: '#/components/responses/InternalServerError'
/billing/usage:
get:
operationId: getBillingUsage
tags:
- Usage
summary: Get today's usage summary
description: |
Returns the usage summary for the authenticated organization
for the current calendar day (UTC).
Usage counters reset at UTC midnight.
The `organization_id` claim is read from the Bearer JWT.
Requires a valid Bearer JWT.
security:
- BearerAuth: []
responses:
'200':
description: Usage summary returned successfully.
content:
application/json:
schema:
$ref: '#/components/schemas/UsageSummary'
example:
organizationId: "org-1234-5678-abcd-ef01"
date: "2026-04-07"
tokensIssued: 4201
agentsRegistered: 3
credentialsGenerated: 5
apiCallsTotal: 12450
'401':
$ref: '#/components/responses/Unauthorized'
'403':
$ref: '#/components/responses/Forbidden'
'500':
$ref: '#/components/responses/InternalServerError'

View File

@@ -0,0 +1,480 @@
openapi: "3.0.3"
info:
title: SentryAgent.ai — A2A Delegation (Agent-to-Agent)
version: 1.0.0
description: |
Agent-to-Agent (A2A) delegation endpoints for the SentryAgent.ai AgentIdP platform.
The delegation subsystem enables an authenticated agent (the *delegator*) to grant
a subset of its own scopes to another agent (the *delegatee*) for a limited time.
This creates a cryptographically-signed delegation chain, suitable for multi-agent
orchestration patterns.
**All endpoints require a valid Bearer JWT.**
**Feature flag:** When `A2A_ENABLED=false` these routes are not registered (return 404).
**Delegation rules:**
- The delegatee must be in the same tenant as the delegator.
- Delegated scopes must be a strict subset of the delegator's own scopes.
- TTL minimum: 60 seconds; maximum: 86400 seconds (24 hours).
- Each delegation chain has a unique `chainId` (UUID).
- Revoking a chain is idempotent — revoking an already-revoked chain succeeds.
servers:
- url: http://localhost:3000/api/v1
description: Local development server
- url: https://api.sentryagent.ai/v1
description: Production server
tags:
- name: A2A Delegation
description: Agent-to-Agent delegation chain management
components:
securitySchemes:
BearerAuth:
type: http
scheme: bearer
bearerFormat: JWT
description: |
JWT access token obtained via `POST /token`.
Include as `Authorization: Bearer <token>`.
schemas:
DelegationChain:
type: object
description: A delegation chain record as returned by the API.
required:
- id
- tenantId
- delegatorAgentId
- delegateeAgentId
- scopes
- delegationToken
- ttlSeconds
- issuedAt
- expiresAt
- createdAt
properties:
id:
type: string
format: uuid
description: Unique identifier of the delegation chain.
readOnly: true
example: "chain-abcd-1234-5678-ef01"
tenantId:
type: string
format: uuid
description: Organization (tenant) that owns this delegation.
readOnly: true
example: "org-1234-5678-abcd-ef01"
delegatorAgentId:
type: string
format: uuid
description: UUID of the agent granting authority.
example: "a1b2c3d4-e5f6-7890-abcd-ef1234567890"
delegateeAgentId:
type: string
format: uuid
description: UUID of the agent receiving delegated authority.
example: "b2c3d4e5-f6a7-8901-bcde-f12345678901"
scopes:
type: array
items:
type: string
description: OAuth 2.0 scopes granted by this delegation chain.
example:
- "agents:read"
delegationToken:
type: string
description: |
Opaque delegation token string that the delegatee presents to verify authority.
This token encodes the chain metadata and is HMAC-signed.
example: "chain-abcd-1234-5678-ef01.1743151200.1743237600"
signature:
type: string
description: HMAC-SHA256 signature of the delegation token payload.
example: "3a7f2b9c..."
ttlSeconds:
type: integer
description: Delegation lifetime in seconds.
minimum: 60
maximum: 86400
example: 3600
issuedAt:
type: string
format: date-time
readOnly: true
example: "2026-04-07T09:00:00.000Z"
expiresAt:
type: string
format: date-time
readOnly: true
example: "2026-04-07T10:00:00.000Z"
revokedAt:
type: string
format: date-time
nullable: true
description: Timestamp when this chain was revoked. Null if still active or expired naturally.
readOnly: true
example: null
createdAt:
type: string
format: date-time
readOnly: true
example: "2026-04-07T09:00:00.000Z"
CreateDelegationRequest:
type: object
description: Request body for creating a new agent-to-agent delegation chain.
required:
- delegateeAgentId
- scopes
- ttlSeconds
properties:
delegateeAgentId:
type: string
format: uuid
description: |
UUID of the agent to receive delegated authority.
Must be in the same tenant as the delegator (caller).
example: "b2c3d4e5-f6a7-8901-bcde-f12345678901"
scopes:
type: array
items:
type: string
description: |
Scopes to delegate. Must be a strict subset of the delegator's current token scopes.
At least one scope must be specified.
minItems: 1
example:
- "agents:read"
ttlSeconds:
type: integer
description: Delegation lifetime in seconds. Minimum: 60; Maximum: 86400 (24 hours).
minimum: 60
maximum: 86400
example: 3600
VerifyDelegationRequest:
type: object
description: Request body for verifying a delegation token.
required:
- delegationToken
properties:
delegationToken:
type: string
description: The delegation token string to verify.
example: "chain-abcd-1234-5678-ef01.1743151200.1743237600"
DelegationVerificationResult:
type: object
description: |
Result of verifying a delegation token.
Returns `valid: false` for expired or revoked tokens without throwing.
required:
- valid
- chainId
- delegatorAgentId
- delegateeAgentId
- scopes
- issuedAt
- expiresAt
properties:
valid:
type: boolean
description: Whether the delegation token is currently valid (active, not expired, not revoked).
example: true
chainId:
type: string
format: uuid
description: UUID of the delegation chain.
example: "chain-abcd-1234-5678-ef01"
delegatorAgentId:
type: string
format: uuid
example: "a1b2c3d4-e5f6-7890-abcd-ef1234567890"
delegateeAgentId:
type: string
format: uuid
example: "b2c3d4e5-f6a7-8901-bcde-f12345678901"
scopes:
type: array
items:
type: string
example:
- "agents:read"
issuedAt:
type: string
format: date-time
example: "2026-04-07T09:00:00.000Z"
expiresAt:
type: string
format: date-time
example: "2026-04-07T10:00:00.000Z"
revokedAt:
type: string
format: date-time
nullable: true
example: null
ErrorResponse:
type: object
description: Standard error response envelope.
required:
- code
- message
properties:
code:
type: string
example: "DELEGATION_NOT_FOUND"
message:
type: string
example: "Delegation chain with the specified ID was not found."
details:
type: object
additionalProperties: true
responses:
Unauthorized:
description: Missing or invalid Bearer token.
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
example:
code: "UNAUTHORIZED"
message: "A valid Bearer token is required to access this resource."
Forbidden:
description: Valid token but insufficient permissions.
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
example:
code: "FORBIDDEN"
message: "You do not have permission to perform this action."
NotFound:
description: Delegation chain not found.
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
example:
code: "DELEGATION_NOT_FOUND"
message: "Delegation chain with the specified ID was not found."
InternalServerError:
description: Unexpected server error.
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
example:
code: "INTERNAL_SERVER_ERROR"
message: "An unexpected error occurred. Please try again later."
security:
- BearerAuth: []
paths:
/oauth2/token/delegate:
post:
operationId: createDelegation
tags:
- A2A Delegation
summary: Create an A2A delegation chain
description: |
Creates a new agent-to-agent delegation chain. The authenticated agent
(the *delegator*) grants a subset of its own scopes to the `delegateeAgentId`.
A cryptographically-signed `delegationToken` is returned. The delegatee
presents this token to `POST /oauth2/token/verify-delegation` to prove
delegated authority.
**Validation:**
- Delegatee must be in the same organization as the delegator.
- `scopes` must be a strict subset of the delegator's current token scopes.
- `ttlSeconds` must be between 60 and 86400.
requestBody:
required: true
content:
application/json:
schema:
$ref: '#/components/schemas/CreateDelegationRequest'
example:
delegateeAgentId: "b2c3d4e5-f6a7-8901-bcde-f12345678901"
scopes:
- "agents:read"
ttlSeconds: 3600
responses:
'201':
description: Delegation chain created successfully.
content:
application/json:
schema:
$ref: '#/components/schemas/DelegationChain'
example:
id: "chain-abcd-1234-5678-ef01"
tenantId: "org-1234-5678-abcd-ef01"
delegatorAgentId: "a1b2c3d4-e5f6-7890-abcd-ef1234567890"
delegateeAgentId: "b2c3d4e5-f6a7-8901-bcde-f12345678901"
scopes:
- "agents:read"
delegationToken: "chain-abcd-1234-5678-ef01.1743151200.1743154800"
signature: "3a7f2b9c..."
ttlSeconds: 3600
issuedAt: "2026-04-07T09:00:00.000Z"
expiresAt: "2026-04-07T10:00:00.000Z"
revokedAt: null
createdAt: "2026-04-07T09:00:00.000Z"
'400':
description: Validation error in request body.
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
examples:
scopeExceedsOwn:
summary: Requested scope exceeds delegator's own scopes
value:
code: "SCOPE_EXCEEDS_DELEGATOR"
message: "Delegated scopes must be a subset of the delegator's own token scopes."
details:
requested: ["agents:write"]
available: ["agents:read"]
invalidTtl:
summary: TTL out of range
value:
code: "VALIDATION_ERROR"
message: "ttlSeconds must be between 60 and 86400."
crossTenant:
summary: Delegatee in different tenant
value:
code: "CROSS_TENANT_DELEGATION"
message: "Delegatee agent must be in the same organization as the delegator."
'401':
$ref: '#/components/responses/Unauthorized'
'404':
description: Delegatee agent not found.
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
example:
code: "AGENT_NOT_FOUND"
message: "Delegatee agent with the specified ID was not found."
'500':
$ref: '#/components/responses/InternalServerError'
/oauth2/token/verify-delegation:
post:
operationId: verifyDelegation
tags:
- A2A Delegation
summary: Verify a delegation token
description: |
Verifies a delegation token and returns the chain details if valid.
Returns `valid: true` with full chain metadata when the token is valid
(exists, not expired, not revoked).
Returns `valid: false` when the token is expired or revoked.
Does not throw an error for inactive tokens — always returns `200`.
Requires a valid Bearer JWT (any authenticated agent may verify a delegation).
requestBody:
required: true
content:
application/json:
schema:
$ref: '#/components/schemas/VerifyDelegationRequest'
example:
delegationToken: "chain-abcd-1234-5678-ef01.1743151200.1743154800"
responses:
'200':
description: Delegation verification result returned.
content:
application/json:
schema:
$ref: '#/components/schemas/DelegationVerificationResult'
examples:
valid:
summary: Valid delegation token
value:
valid: true
chainId: "chain-abcd-1234-5678-ef01"
delegatorAgentId: "a1b2c3d4-e5f6-7890-abcd-ef1234567890"
delegateeAgentId: "b2c3d4e5-f6a7-8901-bcde-f12345678901"
scopes:
- "agents:read"
issuedAt: "2026-04-07T09:00:00.000Z"
expiresAt: "2026-04-07T10:00:00.000Z"
revokedAt: null
expired:
summary: Expired delegation token
value:
valid: false
chainId: "chain-abcd-1234-5678-ef01"
delegatorAgentId: "a1b2c3d4-e5f6-7890-abcd-ef1234567890"
delegateeAgentId: "b2c3d4e5-f6a7-8901-bcde-f12345678901"
scopes:
- "agents:read"
issuedAt: "2026-04-06T09:00:00.000Z"
expiresAt: "2026-04-06T10:00:00.000Z"
revokedAt: null
'400':
description: Missing or malformed `delegationToken` field.
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
example:
code: "VALIDATION_ERROR"
message: "The 'delegationToken' field is required."
'401':
$ref: '#/components/responses/Unauthorized'
'500':
$ref: '#/components/responses/InternalServerError'
/oauth2/token/delegate/{chainId}:
parameters:
- name: chainId
in: path
required: true
description: UUID of the delegation chain to revoke.
schema:
type: string
format: uuid
example: "chain-abcd-1234-5678-ef01"
delete:
operationId: revokeDelegation
tags:
- A2A Delegation
summary: Revoke a delegation chain
description: |
Immediately revokes a delegation chain.
After revocation, `POST /oauth2/token/verify-delegation` will return
`valid: false` for the revoked chain's token.
**Idempotent** — revoking an already-revoked chain returns `204` without error.
Only the delegator agent or an admin may revoke a chain.
Requires a valid Bearer JWT.
responses:
'204':
description: Delegation chain revoked successfully (or was already revoked). No response body.
'401':
$ref: '#/components/responses/Unauthorized'
'403':
$ref: '#/components/responses/Forbidden'
'404':
$ref: '#/components/responses/NotFound'
'500':
$ref: '#/components/responses/InternalServerError'

576
docs/openapi/did.yaml Normal file
View File

@@ -0,0 +1,576 @@
openapi: "3.0.3"
info:
title: SentryAgent.ai — W3C DID & AGNTCY Agent Card
version: 1.0.0
description: |
W3C Decentralized Identifier (DID) and AGNTCY Agent Card endpoints for the
SentryAgent.ai AgentIdP platform.
**Unauthenticated endpoints:**
- `GET /.well-known/did.json` — Instance-level DID Document for the IdP itself
- `GET /api/v1/agents/:agentId/did` — Per-agent W3C DID Document
- `GET /api/v1/agents/:agentId/did/card` — AGNTCY-format agent card
**Authenticated endpoint** (requires Bearer JWT + OPA authorization):
- `GET /api/v1/agents/:agentId/did/resolve` — W3C DID Resolution result
All DID Documents conform to the **W3C DID Core 1.0** specification.
Agent cards conform to the **AGNTCY** agent identity standard (Linux Foundation).
servers:
- url: http://localhost:3000
description: Local development server
- url: https://api.sentryagent.ai
description: Production server
tags:
- name: DID Documents
description: W3C DID Document endpoints (unauthenticated)
- name: DID Resolution
description: Authenticated W3C DID Resolution endpoint
- name: Agent Card
description: AGNTCY agent card endpoint (unauthenticated)
components:
securitySchemes:
BearerAuth:
type: http
scheme: bearer
bearerFormat: JWT
description: |
JWT access token obtained via `POST /api/v1/token`.
Include as `Authorization: Bearer <token>`.
schemas:
PublicKeyJwk:
type: object
description: JWK representation of a public key embedded in a verification method.
required:
- kty
properties:
kty:
type: string
description: Key type (e.g. "EC", "RSA").
example: "EC"
crv:
type: string
description: EC curve (e.g. "P-256").
example: "P-256"
x:
type: string
description: Base64url-encoded EC x coordinate.
example: "f83OJ3D..."
y:
type: string
description: Base64url-encoded EC y coordinate.
example: "x_FEzRu..."
n:
type: string
description: Base64url-encoded RSA modulus.
e:
type: string
description: Base64url-encoded RSA public exponent.
example: "AQAB"
use:
type: string
example: "sig"
kid:
type: string
example: "key-20260328-001"
VerificationMethod:
type: object
description: W3C DID Core 1.0 verification method.
required:
- id
- type
- controller
- publicKeyJwk
properties:
id:
type: string
description: Full DID URL for this verification method.
example: "did:web:api.sentryagent.ai:agents:a1b2c3d4-e5f6-7890-abcd-ef1234567890#key-1"
type:
type: string
description: Verification method type.
example: "JsonWebKey2020"
controller:
type: string
description: DID that controls this key.
example: "did:web:api.sentryagent.ai:agents:a1b2c3d4-e5f6-7890-abcd-ef1234567890"
publicKeyJwk:
$ref: '#/components/schemas/PublicKeyJwk'
DIDService:
type: object
description: A W3C DID Document service endpoint.
required:
- id
- type
- serviceEndpoint
properties:
id:
type: string
example: "did:web:api.sentryagent.ai:agents:a1b2c3d4#agentIdP"
type:
type: string
example: "AgentIdP"
serviceEndpoint:
type: string
format: uri
example: "https://api.sentryagent.ai/api/v1/agents/a1b2c3d4-e5f6-7890-abcd-ef1234567890"
AgntcyExtension:
type: object
description: AGNTCY-specific extension fields embedded in a per-agent DID Document.
required:
- agentId
- agentType
- capabilities
- deploymentEnv
- owner
- version
properties:
agentId:
type: string
format: uuid
example: "a1b2c3d4-e5f6-7890-abcd-ef1234567890"
agentType:
type: string
example: "screener"
capabilities:
type: array
items:
type: string
example: ["resume:read", "email:send"]
deploymentEnv:
type: string
example: "production"
owner:
type: string
example: "talent-acquisition-team"
version:
type: string
example: "1.4.2"
DIDDocument:
type: object
description: W3C DID Core 1.0 DID Document.
required:
- "@context"
- id
- controller
- verificationMethod
- authentication
properties:
"@context":
type: array
items:
type: string
description: JSON-LD context URIs.
example:
- "https://www.w3.org/ns/did/v1"
- "https://w3id.org/security/suites/jws-2020/v1"
id:
type: string
description: The DID identifier for this document.
example: "did:web:api.sentryagent.ai:agents:a1b2c3d4-e5f6-7890-abcd-ef1234567890"
controller:
type: string
description: DID of the controlling entity.
example: "did:web:api.sentryagent.ai"
verificationMethod:
type: array
items:
$ref: '#/components/schemas/VerificationMethod'
authentication:
type: array
items:
type: string
description: DID URLs referencing verification methods authorized for authentication.
example:
- "did:web:api.sentryagent.ai:agents:a1b2c3d4-e5f6-7890-abcd-ef1234567890#key-1"
assertionMethod:
type: array
items:
type: string
service:
type: array
items:
$ref: '#/components/schemas/DIDService'
agntcy:
$ref: '#/components/schemas/AgntcyExtension'
DIDResolutionResult:
type: object
description: |
W3C DID Resolution result format.
Returned with `Content-Type: application/ld+json;profile="https://w3id.org/did-resolution"`.
required:
- didDocument
- didDocumentMetadata
- didResolutionMetadata
properties:
didDocument:
$ref: '#/components/schemas/DIDDocument'
didDocumentMetadata:
type: object
required:
- created
- updated
- deactivated
properties:
created:
type: string
format: date-time
example: "2026-03-01T08:00:00.000Z"
updated:
type: string
format: date-time
example: "2026-03-28T11:30:00.000Z"
deactivated:
type: boolean
example: false
didResolutionMetadata:
type: object
required:
- contentType
- retrieved
properties:
contentType:
type: string
example: "application/ld+json"
retrieved:
type: string
format: date-time
example: "2026-04-07T09:00:00.000Z"
AgentCard:
type: object
description: |
AGNTCY-format agent card providing a machine-readable identity summary.
Suitable for AGNTCY registry publishing and agent discovery.
required:
- did
- name
- agentType
- capabilities
- owner
- version
- deploymentEnv
- identityProvider
- issuedAt
properties:
did:
type: string
description: W3C DID identifier for this agent.
example: "did:web:api.sentryagent.ai:agents:a1b2c3d4-e5f6-7890-abcd-ef1234567890"
name:
type: string
description: Human-readable agent name (derived from email).
example: "screener-001@sentryagent.ai"
agentType:
type: string
example: "screener"
capabilities:
type: array
items:
type: string
example: ["resume:read", "email:send", "candidate:score"]
owner:
type: string
example: "talent-acquisition-team"
version:
type: string
example: "1.4.2"
deploymentEnv:
type: string
example: "production"
identityProvider:
type: string
format: uri
description: URL of the issuing AgentIdP instance.
example: "https://api.sentryagent.ai"
issuedAt:
type: string
format: date-time
description: ISO 8601 timestamp when this card was generated.
example: "2026-04-07T09:00:00.000Z"
ErrorResponse:
type: object
description: Standard error response envelope.
required:
- code
- message
properties:
code:
type: string
example: "AGENT_NOT_FOUND"
message:
type: string
example: "Agent with the specified ID was not found."
details:
type: object
additionalProperties: true
responses:
Unauthorized:
description: Missing or invalid Bearer token.
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
example:
code: "UNAUTHORIZED"
message: "A valid Bearer token is required to access this resource."
Forbidden:
description: Valid token but insufficient permissions.
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
example:
code: "FORBIDDEN"
message: "You do not have permission to perform this action."
NotFound:
description: Agent not found.
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
example:
code: "AGENT_NOT_FOUND"
message: "Agent with the specified ID was not found."
InternalServerError:
description: Unexpected server error.
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
example:
code: "INTERNAL_SERVER_ERROR"
message: "An unexpected error occurred. Please try again later."
paths:
/.well-known/did.json:
get:
operationId: getInstanceDIDDocument
tags:
- DID Documents
summary: Instance-level DID Document
description: |
Returns the W3C DID Document for the SentryAgent.ai AgentIdP instance itself.
This identifies the IdP as a DID controller (`did:web:api.sentryagent.ai`).
Used by external parties to discover the IdP's public keys and service endpoints.
This endpoint is **unauthenticated**.
security: []
responses:
'200':
description: Instance DID Document returned successfully.
content:
application/json:
schema:
$ref: '#/components/schemas/DIDDocument'
example:
"@context":
- "https://www.w3.org/ns/did/v1"
- "https://w3id.org/security/suites/jws-2020/v1"
id: "did:web:api.sentryagent.ai"
controller: "did:web:api.sentryagent.ai"
verificationMethod:
- id: "did:web:api.sentryagent.ai#key-1"
type: "JsonWebKey2020"
controller: "did:web:api.sentryagent.ai"
publicKeyJwk:
kty: "EC"
crv: "P-256"
x: "f83OJ3D..."
y: "x_FEzRu..."
authentication:
- "did:web:api.sentryagent.ai#key-1"
service:
- id: "did:web:api.sentryagent.ai#agentIdP"
type: "AgentIdP"
serviceEndpoint: "https://api.sentryagent.ai/api/v1"
'500':
$ref: '#/components/responses/InternalServerError'
/api/v1/agents/{agentId}/did:
get:
operationId: getAgentDIDDocument
tags:
- DID Documents
summary: Get agent DID Document
description: |
Returns the W3C DID Core 1.0 Document for a specific registered agent.
Returns `410 Gone` if the agent has been decommissioned — the DID Document
is no longer active.
This endpoint is **unauthenticated**.
security: []
parameters:
- name: agentId
in: path
required: true
description: UUID of the agent.
schema:
type: string
format: uuid
example: "a1b2c3d4-e5f6-7890-abcd-ef1234567890"
responses:
'200':
description: Agent DID Document returned successfully.
content:
application/json:
schema:
$ref: '#/components/schemas/DIDDocument'
example:
"@context":
- "https://www.w3.org/ns/did/v1"
- "https://w3id.org/security/suites/jws-2020/v1"
id: "did:web:api.sentryagent.ai:agents:a1b2c3d4-e5f6-7890-abcd-ef1234567890"
controller: "did:web:api.sentryagent.ai"
verificationMethod:
- id: "did:web:api.sentryagent.ai:agents:a1b2c3d4-e5f6-7890-abcd-ef1234567890#key-1"
type: "JsonWebKey2020"
controller: "did:web:api.sentryagent.ai:agents:a1b2c3d4-e5f6-7890-abcd-ef1234567890"
publicKeyJwk:
kty: "EC"
crv: "P-256"
x: "f83OJ3D..."
y: "x_FEzRu..."
authentication:
- "did:web:api.sentryagent.ai:agents:a1b2c3d4-e5f6-7890-abcd-ef1234567890#key-1"
agntcy:
agentId: "a1b2c3d4-e5f6-7890-abcd-ef1234567890"
agentType: "screener"
capabilities:
- "resume:read"
- "email:send"
deploymentEnv: "production"
owner: "talent-acquisition-team"
version: "1.4.2"
'404':
$ref: '#/components/responses/NotFound'
'410':
description: Agent has been decommissioned — DID Document is no longer active.
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
example:
code: "AGENT_DECOMMISSIONED"
message: "Agent has been decommissioned — DID Document is no longer active"
'500':
$ref: '#/components/responses/InternalServerError'
/api/v1/agents/{agentId}/did/resolve:
get:
operationId: resolveAgentDID
tags:
- DID Resolution
summary: Resolve agent DID (W3C DID Resolution)
description: |
Returns the full W3C DID Resolution result for a specific agent, including
the DID Document, DID Document Metadata, and DID Resolution Metadata.
The response `Content-Type` is:
`application/ld+json;profile="https://w3id.org/did-resolution"`
Requires a valid Bearer JWT and OPA authorization.
security:
- BearerAuth: []
parameters:
- name: agentId
in: path
required: true
description: UUID of the agent to resolve.
schema:
type: string
format: uuid
example: "a1b2c3d4-e5f6-7890-abcd-ef1234567890"
responses:
'200':
description: DID Resolution result returned successfully.
content:
application/ld+json:
schema:
$ref: '#/components/schemas/DIDResolutionResult'
example:
didDocument:
"@context":
- "https://www.w3.org/ns/did/v1"
id: "did:web:api.sentryagent.ai:agents:a1b2c3d4-e5f6-7890-abcd-ef1234567890"
controller: "did:web:api.sentryagent.ai"
verificationMethod: []
authentication: []
didDocumentMetadata:
created: "2026-03-01T08:00:00.000Z"
updated: "2026-03-28T11:30:00.000Z"
deactivated: false
didResolutionMetadata:
contentType: "application/ld+json"
retrieved: "2026-04-07T09:00:00.000Z"
'401':
$ref: '#/components/responses/Unauthorized'
'403':
$ref: '#/components/responses/Forbidden'
'404':
$ref: '#/components/responses/NotFound'
'500':
$ref: '#/components/responses/InternalServerError'
/api/v1/agents/{agentId}/did/card:
get:
operationId: getAgentCard
tags:
- Agent Card
summary: Get AGNTCY agent card
description: |
Returns the AGNTCY-format agent card for the specified agent.
The card provides a machine-readable identity summary suitable for
AGNTCY registry publishing and agent discovery by external consumers.
This endpoint is **unauthenticated**.
security: []
parameters:
- name: agentId
in: path
required: true
description: UUID of the agent.
schema:
type: string
format: uuid
example: "a1b2c3d4-e5f6-7890-abcd-ef1234567890"
responses:
'200':
description: AGNTCY agent card returned successfully.
content:
application/json:
schema:
$ref: '#/components/schemas/AgentCard'
example:
did: "did:web:api.sentryagent.ai:agents:a1b2c3d4-e5f6-7890-abcd-ef1234567890"
name: "screener-001@sentryagent.ai"
agentType: "screener"
capabilities:
- "resume:read"
- "email:send"
- "candidate:score"
owner: "talent-acquisition-team"
version: "1.4.2"
deploymentEnv: "production"
identityProvider: "https://api.sentryagent.ai"
issuedAt: "2026-04-07T09:00:00.000Z"
'404':
$ref: '#/components/responses/NotFound'
'500':
$ref: '#/components/responses/InternalServerError'

View File

@@ -0,0 +1,639 @@
openapi: "3.0.3"
info:
title: SentryAgent.ai — Identity Federation
version: 1.0.0
description: |
Cross-IdP identity federation endpoints for the SentryAgent.ai AgentIdP platform.
The federation subsystem enables this IdP to trust and verify JWT tokens issued by
external identity providers (partner IdPs). This allows agents from federated
organizations to authenticate without re-registering.
**Partner management** (`admin:orgs` scope required):
- `POST /federation/trust` — Register a new trusted partner IdP
- `GET /federation/partners` — List all registered partners
- `GET /federation/partners/:id` — Get a specific partner
- `PATCH /federation/partners/:id` — Update a partner
- `DELETE /federation/partners/:id` — Remove a partner
**Token verification** (any authenticated agent):
- `POST /federation/verify` — Verify a federated JWT from a trusted partner
servers:
- url: http://localhost:3000/api/v1
description: Local development server
- url: https://api.sentryagent.ai/v1
description: Production server
tags:
- name: Federation Partners
description: Trusted partner IdP management (admin:orgs scope)
- name: Federation Verification
description: Cross-IdP token verification (any authenticated agent)
components:
securitySchemes:
BearerAuth:
type: http
scheme: bearer
bearerFormat: JWT
description: |
JWT access token obtained via `POST /token`.
Include as `Authorization: Bearer <token>`.
schemas:
FederationPartnerStatus:
type: string
enum:
- active
- suspended
- expired
description: |
Lifecycle status of a federation partner.
- `active` — partner is trusted; tokens accepted.
- `suspended` — temporarily disabled; tokens rejected.
- `expired` — `expires_at` has passed; tokens rejected.
example: active
FederationPartner:
type: object
description: A registered trusted federation partner IdP.
required:
- id
- name
- issuer
- jwks_uri
- allowed_organizations
- status
- created_at
- updated_at
properties:
id:
type: string
format: uuid
description: Immutable system-assigned UUID for this partner.
readOnly: true
example: "fed-abcd-1234-5678-ef01"
name:
type: string
description: Human-readable partner name.
example: "Acme Partner IdP"
issuer:
type: string
format: uri
description: Issuer URL — must match the `iss` claim in federated tokens.
example: "https://idp.acme-partner.example"
jwks_uri:
type: string
format: uri
description: URL of the partner's JWKS endpoint for token signature verification.
example: "https://idp.acme-partner.example/.well-known/jwks.json"
allowed_organizations:
type: array
items:
type: string
description: |
Allowlist of organization_id values accepted from this partner.
An empty array means all organizations from this partner are accepted.
example: ["org-acme-001", "org-acme-002"]
status:
$ref: '#/components/schemas/FederationPartnerStatus'
created_at:
type: string
format: date-time
readOnly: true
example: "2026-03-01T08:00:00.000Z"
updated_at:
type: string
format: date-time
readOnly: true
example: "2026-03-28T11:30:00.000Z"
expires_at:
type: string
format: date-time
nullable: true
description: Optional expiry timestamp. Null means the partner never expires.
example: "2027-01-01T00:00:00.000Z"
CreatePartnerRequest:
type: object
description: Request body for registering a new trusted federation partner.
required:
- name
- issuer
- jwks_uri
properties:
name:
type: string
description: Human-readable partner name.
minLength: 1
maxLength: 256
example: "Acme Partner IdP"
issuer:
type: string
format: uri
description: Issuer URL of the external IdP. Must match `iss` in federated tokens.
example: "https://idp.acme-partner.example"
jwks_uri:
type: string
format: uri
description: |
URL of the partner's JWKS endpoint. Must be reachable at registration time —
the endpoint is probed before the partner is persisted.
example: "https://idp.acme-partner.example/.well-known/jwks.json"
allowed_organizations:
type: array
items:
type: string
description: Optional allowlist of organization_id values. Defaults to empty (all allowed).
example: ["org-acme-001"]
expires_at:
type: string
format: date-time
description: Optional ISO 8601 date-time after which the partner will be automatically expired.
example: "2027-01-01T00:00:00.000Z"
UpdatePartnerRequest:
type: object
description: |
Request body for partially updating a federation partner.
All fields are optional; only provided fields are updated.
minProperties: 1
properties:
name:
type: string
minLength: 1
maxLength: 256
example: "Acme Partner IdP (Updated)"
jwks_uri:
type: string
format: uri
description: Updated JWKS endpoint URL. The JWKS cache will be invalidated on update.
example: "https://idp.acme-partner.example/.well-known/jwks.json"
allowed_organizations:
type: array
items:
type: string
example: ["org-acme-001", "org-acme-003"]
status:
$ref: '#/components/schemas/FederationPartnerStatus'
expires_at:
type: string
format: date-time
nullable: true
description: Updated expiry. Pass null to remove the expiry.
example: "2028-01-01T00:00:00.000Z"
FederationVerifyRequest:
type: object
description: Request body for verifying a federated token from a trusted partner.
required:
- token
properties:
token:
type: string
description: The JWT token string issued by the partner IdP.
example: "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJhZ2VudC0wMDEiLCJpc3MiOiJodHRwczovL2lkcC5hY21lLXBhcnRuZXIuZXhhbXBsZSIsImV4cCI6MTc0MzE1NDgwMH0.signature"
expected_issuer:
type: string
format: uri
description: |
Optional issuer hint. When provided, the token's `iss` claim must match exactly.
Useful to prevent issuer confusion when multiple partners share JWKS.
example: "https://idp.acme-partner.example"
FederationVerifyResult:
type: object
description: Result of a successful federated token verification.
required:
- valid
- issuer
- subject
- claims
properties:
valid:
type: boolean
description: Whether the token is valid (true when verification passed).
example: true
issuer:
type: string
format: uri
description: The `iss` claim from the verified token.
example: "https://idp.acme-partner.example"
subject:
type: string
description: The `sub` claim from the verified token.
example: "agent-001-external"
organization_id:
type: string
description: The `organization_id` claim from the token, if present.
example: "org-acme-001"
claims:
type: object
description: All claims from the verified token payload.
additionalProperties: true
example:
iss: "https://idp.acme-partner.example"
sub: "agent-001-external"
aud: "https://api.sentryagent.ai"
iat: 1743151200
exp: 1743154800
organization_id: "org-acme-001"
ErrorResponse:
type: object
description: Standard error response envelope.
required:
- code
- message
properties:
code:
type: string
example: "FEDERATION_PARTNER_NOT_FOUND"
message:
type: string
example: "Federation partner with the specified ID was not found."
details:
type: object
additionalProperties: true
responses:
Unauthorized:
description: Missing or invalid Bearer token.
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
example:
code: "UNAUTHORIZED"
message: "A valid Bearer token is required to access this resource."
Forbidden:
description: Valid token but insufficient permissions.
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
example:
code: "FORBIDDEN"
message: "You do not have permission to perform this action."
NotFound:
description: Federation partner not found.
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
example:
code: "FEDERATION_PARTNER_NOT_FOUND"
message: "Federation partner with the specified ID was not found."
InternalServerError:
description: Unexpected server error.
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
example:
code: "INTERNAL_SERVER_ERROR"
message: "An unexpected error occurred. Please try again later."
security:
- BearerAuth: []
paths:
/federation/trust:
post:
operationId: registerFederationPartner
tags:
- Federation Partners
summary: Register a trusted federation partner
description: |
Registers a new external IdP as a trusted federation partner.
The partner's JWKS endpoint (`jwks_uri`) is probed at registration time
to confirm it is reachable. If the endpoint is unreachable, the request
is rejected with `422 Unprocessable Entity`.
Requires `admin:orgs` scope.
requestBody:
required: true
content:
application/json:
schema:
$ref: '#/components/schemas/CreatePartnerRequest'
example:
name: "Acme Partner IdP"
issuer: "https://idp.acme-partner.example"
jwks_uri: "https://idp.acme-partner.example/.well-known/jwks.json"
allowed_organizations:
- "org-acme-001"
expires_at: "2027-01-01T00:00:00.000Z"
responses:
'201':
description: Federation partner registered successfully.
content:
application/json:
schema:
$ref: '#/components/schemas/FederationPartner'
example:
id: "fed-abcd-1234-5678-ef01"
name: "Acme Partner IdP"
issuer: "https://idp.acme-partner.example"
jwks_uri: "https://idp.acme-partner.example/.well-known/jwks.json"
allowed_organizations:
- "org-acme-001"
status: "active"
created_at: "2026-04-07T09:00:00.000Z"
updated_at: "2026-04-07T09:00:00.000Z"
expires_at: "2027-01-01T00:00:00.000Z"
'400':
description: Validation error in request body.
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
example:
code: "VALIDATION_ERROR"
message: "Request validation failed."
details:
field: "jwks_uri"
reason: "Must be a valid HTTPS URL."
'401':
$ref: '#/components/responses/Unauthorized'
'403':
$ref: '#/components/responses/Forbidden'
'409':
description: A partner with the same issuer is already registered.
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
example:
code: "FEDERATION_PARTNER_CONFLICT"
message: "A federation partner with this issuer is already registered."
'422':
description: Partner JWKS endpoint is unreachable.
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
example:
code: "JWKS_UNREACHABLE"
message: "The partner JWKS endpoint is unreachable. Verify the URL and try again."
'500':
$ref: '#/components/responses/InternalServerError'
/federation/partners:
get:
operationId: listFederationPartners
tags:
- Federation Partners
summary: List all federation partners
description: |
Returns all registered federation partners.
Partners past their `expires_at` are returned with status `expired`.
Requires `admin:orgs` scope.
responses:
'200':
description: List of federation partners returned successfully.
content:
application/json:
schema:
type: array
items:
$ref: '#/components/schemas/FederationPartner'
example:
- id: "fed-abcd-1234-5678-ef01"
name: "Acme Partner IdP"
issuer: "https://idp.acme-partner.example"
jwks_uri: "https://idp.acme-partner.example/.well-known/jwks.json"
allowed_organizations: ["org-acme-001"]
status: "active"
created_at: "2026-03-01T08:00:00.000Z"
updated_at: "2026-03-28T11:30:00.000Z"
expires_at: "2027-01-01T00:00:00.000Z"
'401':
$ref: '#/components/responses/Unauthorized'
'403':
$ref: '#/components/responses/Forbidden'
'500':
$ref: '#/components/responses/InternalServerError'
/federation/partners/{id}:
parameters:
- name: id
in: path
required: true
description: UUID of the federation partner.
schema:
type: string
format: uuid
example: "fed-abcd-1234-5678-ef01"
get:
operationId: getFederationPartner
tags:
- Federation Partners
summary: Get a federation partner by ID
description: |
Returns a single federation partner record by its UUID.
Requires `admin:orgs` scope.
responses:
'200':
description: Federation partner returned successfully.
content:
application/json:
schema:
$ref: '#/components/schemas/FederationPartner'
example:
id: "fed-abcd-1234-5678-ef01"
name: "Acme Partner IdP"
issuer: "https://idp.acme-partner.example"
jwks_uri: "https://idp.acme-partner.example/.well-known/jwks.json"
allowed_organizations: ["org-acme-001"]
status: "active"
created_at: "2026-03-01T08:00:00.000Z"
updated_at: "2026-03-28T11:30:00.000Z"
expires_at: null
'401':
$ref: '#/components/responses/Unauthorized'
'403':
$ref: '#/components/responses/Forbidden'
'404':
$ref: '#/components/responses/NotFound'
'500':
$ref: '#/components/responses/InternalServerError'
patch:
operationId: updateFederationPartner
tags:
- Federation Partners
summary: Update a federation partner
description: |
Partially updates a federation partner's configuration.
Only provided fields are updated.
Changing `jwks_uri` invalidates the cached JWKS for this partner.
Requires `admin:orgs` scope.
requestBody:
required: true
content:
application/json:
schema:
$ref: '#/components/schemas/UpdatePartnerRequest'
example:
status: "suspended"
allowed_organizations:
- "org-acme-001"
- "org-acme-003"
responses:
'200':
description: Federation partner updated successfully.
content:
application/json:
schema:
$ref: '#/components/schemas/FederationPartner'
example:
id: "fed-abcd-1234-5678-ef01"
name: "Acme Partner IdP"
issuer: "https://idp.acme-partner.example"
jwks_uri: "https://idp.acme-partner.example/.well-known/jwks.json"
allowed_organizations: ["org-acme-001", "org-acme-003"]
status: "suspended"
created_at: "2026-03-01T08:00:00.000Z"
updated_at: "2026-04-07T09:00:00.000Z"
expires_at: null
'400':
description: Validation error in request body.
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
example:
code: "VALIDATION_ERROR"
message: "Request validation failed."
'401':
$ref: '#/components/responses/Unauthorized'
'403':
$ref: '#/components/responses/Forbidden'
'404':
$ref: '#/components/responses/NotFound'
'500':
$ref: '#/components/responses/InternalServerError'
delete:
operationId: deleteFederationPartner
tags:
- Federation Partners
summary: Remove a federation partner
description: |
Permanently removes a federation partner. After removal, tokens issued
by the partner's IdP will no longer be accepted.
Requires `admin:orgs` scope.
responses:
'204':
description: Federation partner removed successfully. No response body.
'401':
$ref: '#/components/responses/Unauthorized'
'403':
$ref: '#/components/responses/Forbidden'
'404':
$ref: '#/components/responses/NotFound'
'500':
$ref: '#/components/responses/InternalServerError'
/federation/verify:
post:
operationId: verifyFederatedToken
tags:
- Federation Verification
summary: Verify a federated JWT token
description: |
Verifies a JWT token issued by a registered federation partner.
The token's `iss` claim is matched against registered active partners.
The signature is verified against the partner's JWKS.
The partner's `allowed_organizations` filter is applied if non-empty.
Returns verification result with claims on success.
Returns `422` with verification failure details on invalid tokens.
Requires any valid Bearer token (`agents:read` scope is sufficient).
requestBody:
required: true
content:
application/json:
schema:
$ref: '#/components/schemas/FederationVerifyRequest'
example:
token: "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJhZ2VudC0wMDEiLCJpc3MiOiJodHRwczovL2lkcC5hY21lLXBhcnRuZXIuZXhhbXBsZSJ9.signature"
expected_issuer: "https://idp.acme-partner.example"
responses:
'200':
description: Token verification result returned.
content:
application/json:
schema:
$ref: '#/components/schemas/FederationVerifyResult'
examples:
valid:
summary: Token verified successfully
value:
valid: true
issuer: "https://idp.acme-partner.example"
subject: "agent-001-external"
organization_id: "org-acme-001"
claims:
iss: "https://idp.acme-partner.example"
sub: "agent-001-external"
aud: "https://api.sentryagent.ai"
iat: 1743151200
exp: 1743154800
invalid:
summary: Token invalid or expired
value:
valid: false
issuer: ""
subject: ""
claims: {}
'400':
description: Missing or malformed token in request body.
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
example:
code: "VALIDATION_ERROR"
message: "The 'token' field is required."
'401':
$ref: '#/components/responses/Unauthorized'
'422':
description: |
Token is well-formed but verification failed (unknown issuer, expired,
invalid signature, or organization not in allowlist).
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
examples:
unknownIssuer:
summary: Unknown issuer
value:
code: "UNKNOWN_FEDERATION_ISSUER"
message: "No active federation partner found for this token issuer."
partnerSuspended:
summary: Partner is suspended
value:
code: "FEDERATION_PARTNER_SUSPENDED"
message: "The federation partner for this token issuer is suspended."
orgNotAllowed:
summary: Organization not in allowlist
value:
code: "FEDERATION_ORG_NOT_ALLOWED"
message: "The token's organization_id is not in the partner's allowed_organizations list."
'500':
$ref: '#/components/responses/InternalServerError'

291
docs/openapi/health.yaml Normal file
View File

@@ -0,0 +1,291 @@
openapi: "3.0.3"
info:
title: SentryAgent.ai — Health Check Service
version: 1.0.0
description: |
Liveness and readiness health endpoints for the SentryAgent.ai AgentIdP platform.
Both endpoints are **unauthenticated** — safe to call from monitoring systems,
load balancers, and container orchestrators without credentials.
**GET /health** performs a fast liveness check (< 50 ms target).
**GET /health/detailed** probes each dependency with latency measurement.
servers:
- url: http://localhost:3000
description: Local development server
- url: https://api.sentryagent.ai
description: Production server
tags:
- name: Health
description: Liveness and dependency health endpoints
components:
schemas:
ServiceSimpleStatus:
type: string
enum:
- connected
- disconnected
description: Simple connectivity status for the quick health check.
example: connected
ServiceDetailedStatus:
type: string
enum:
- healthy
- degraded
- unreachable
description: |
Per-service health classification for the detailed health check.
- `healthy` — responded within 1000 ms
- `degraded` — responded but latency exceeded 1000 ms
- `unreachable` — timed out or threw an error
ServiceHealthResult:
type: object
description: Per-service latency and status result from the detailed health probe.
required:
- status
- latencyMs
properties:
status:
$ref: '#/components/schemas/ServiceDetailedStatus'
latencyMs:
type: integer
description: Probe round-trip time in milliseconds.
example: 12
HealthResponse:
type: object
description: Response body for GET /health — quick liveness check.
required:
- status
- version
- uptime
- services
properties:
status:
type: string
enum:
- ok
- degraded
description: |
Overall liveness status.
- `ok` — all services are connected.
- `degraded` — one or more services are disconnected.
example: ok
version:
type: string
description: Running npm package version.
example: "1.0.0"
uptime:
type: integer
description: Process uptime in whole seconds.
example: 3724
services:
type: object
description: Quick connectivity check for core services.
required:
- postgres
- redis
properties:
postgres:
$ref: '#/components/schemas/ServiceSimpleStatus'
redis:
$ref: '#/components/schemas/ServiceSimpleStatus'
DetailedHealthResponse:
type: object
description: |
Response body for GET /health/detailed. Probes each dependency
individually and reports per-service latency.
required:
- status
- version
- uptime
- services
properties:
status:
$ref: '#/components/schemas/ServiceDetailedStatus'
description: Worst-case overall status across all probed services.
example: healthy
version:
type: string
description: Running npm package version.
example: "1.0.0"
uptime:
type: integer
description: Process uptime in whole seconds.
example: 3724
services:
type: object
description: |
Map of service name to per-service health result.
Always includes `postgres`; `redis`, `vault`, and `opa` are
included when the respective client / env-var is configured.
additionalProperties:
$ref: '#/components/schemas/ServiceHealthResult'
example:
postgres:
status: healthy
latencyMs: 12
redis:
status: healthy
latencyMs: 3
vault:
status: degraded
latencyMs: 1240
opa:
status: healthy
latencyMs: 8
ErrorResponse:
type: object
description: Standard error response envelope.
required:
- code
- message
properties:
code:
type: string
example: "INTERNAL_SERVER_ERROR"
message:
type: string
example: "An unexpected error occurred. Please try again later."
details:
type: object
additionalProperties: true
paths:
/health:
get:
operationId: getHealth
tags:
- Health
summary: Quick liveness check
description: |
Returns `200 OK` when PostgreSQL and Redis are reachable.
Returns `503 Service Unavailable` when either dependency is disconnected.
This endpoint is **unauthenticated** — no Bearer token is required.
Designed for load-balancer health checks and uptime monitors.
security: []
responses:
'200':
description: All services are connected and the application is healthy.
content:
application/json:
schema:
$ref: '#/components/schemas/HealthResponse'
example:
status: ok
version: "1.0.0"
uptime: 3724
services:
postgres: connected
redis: connected
'503':
description: One or more services are disconnected. The application is degraded.
content:
application/json:
schema:
$ref: '#/components/schemas/HealthResponse'
example:
status: degraded
version: "1.0.0"
uptime: 3724
services:
postgres: connected
redis: disconnected
'500':
description: Unexpected server error during health probe.
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
example:
code: INTERNAL_SERVER_ERROR
message: "An unexpected error occurred. Please try again later."
/health/detailed:
get:
operationId: getHealthDetailed
tags:
- Health
summary: Detailed dependency health with latency
description: |
Probes each configured dependency (PostgreSQL, Redis, Vault, OPA) with a
3000 ms timeout and reports per-service status and latency.
**HTTP status codes:**
- `200` — all probed services are `healthy`
- `207` — at least one service is `degraded` but none are `unreachable`
- `503` — at least one service is `unreachable`
This endpoint is **unauthenticated**.
Vault and OPA entries are omitted when not configured via environment variables.
security: []
responses:
'200':
description: All probed services are healthy (latency < 1000 ms).
content:
application/json:
schema:
$ref: '#/components/schemas/DetailedHealthResponse'
example:
status: healthy
version: "1.0.0"
uptime: 3724
services:
postgres:
status: healthy
latencyMs: 12
redis:
status: healthy
latencyMs: 3
'207':
description: At least one service is degraded (latency > 1000 ms) but none are unreachable.
content:
application/json:
schema:
$ref: '#/components/schemas/DetailedHealthResponse'
example:
status: degraded
version: "1.0.0"
uptime: 3724
services:
postgres:
status: healthy
latencyMs: 14
redis:
status: degraded
latencyMs: 1350
'503':
description: At least one service is unreachable (timed out or connection refused).
content:
application/json:
schema:
$ref: '#/components/schemas/DetailedHealthResponse'
example:
status: unreachable
version: "1.0.0"
uptime: 3724
services:
postgres:
status: unreachable
latencyMs: 3000
redis:
status: healthy
latencyMs: 4
'500':
description: Unexpected server error during health probe.
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
example:
code: INTERNAL_SERVER_ERROR
message: "An unexpected error occurred. Please try again later."

View File

@@ -0,0 +1,388 @@
openapi: "3.0.3"
info:
title: SentryAgent.ai — Public Agent Marketplace
version: 1.0.0
description: |
Public Agent Marketplace endpoints for the SentryAgent.ai AgentIdP platform.
The marketplace enables discovery of AI agents that have been explicitly
marked as public (`isPublic: true`) by their owners. It is a read-only
public catalog — no authentication required.
**Feature flag:** When `MARKETPLACE_ENABLED=false` all routes return `404`.
**Unauthenticated endpoints:**
- `GET /marketplace/agents` — Paginated list of public agents with search and filters
- `GET /marketplace/agents/:agentId` — Detailed public agent with DID Document
servers:
- url: http://localhost:3000/api/v1
description: Local development server
- url: https://api.sentryagent.ai/v1
description: Production server
tags:
- name: Marketplace
description: Public agent discovery endpoints (unauthenticated)
components:
schemas:
MinimalDIDDocument:
type: object
description: Minimal W3C DID Document returned with marketplace agent detail.
required:
- "@context"
- id
- controller
- verificationMethod
- authentication
properties:
"@context":
type: array
items:
type: string
example:
- "https://www.w3.org/ns/did/v1"
id:
type: string
example: "did:web:api.sentryagent.ai:agents:a1b2c3d4-e5f6-7890-abcd-ef1234567890"
controller:
type: string
example: "did:web:api.sentryagent.ai"
verificationMethod:
type: array
items:
type: object
additionalProperties: true
description: Verification methods from the DID Document.
authentication:
type: array
items:
type: object
additionalProperties: true
MarketplaceAgentCard:
type: object
description: |
Public agent card returned by the marketplace. Contains only information
that the agent owner has explicitly made public.
required:
- agentId
- agentType
- version
- capabilities
- owner
- deploymentEnv
- publishedAt
properties:
agentId:
type: string
format: uuid
description: Unique identifier of the agent.
example: "a1b2c3d4-e5f6-7890-abcd-ef1234567890"
agentType:
type: string
description: Functional classification of the agent.
enum:
- screener
- classifier
- orchestrator
- extractor
- summarizer
- router
- monitor
- custom
example: "screener"
version:
type: string
description: Semantic version string of the agent.
example: "1.4.2"
capabilities:
type: array
items:
type: string
description: List of capability strings (`resource:action` format).
example:
- "resume:read"
- "email:send"
- "candidate:score"
owner:
type: string
description: Team or organization that owns this agent.
example: "talent-acquisition-team"
deploymentEnv:
type: string
enum:
- development
- staging
- production
example: "production"
did:
type: string
nullable: true
description: W3C DID identifier for this agent, if one has been generated.
example: "did:web:api.sentryagent.ai:agents:a1b2c3d4-e5f6-7890-abcd-ef1234567890"
didDocument:
$ref: '#/components/schemas/MinimalDIDDocument'
nullable: true
description: Minimal W3C DID Document for this agent, if a DID has been generated.
publishedAt:
type: string
format: date-time
description: Timestamp when this agent was made public.
example: "2026-03-01T08:00:00.000Z"
PaginatedMarketplaceResponse:
type: object
description: Paginated marketplace listing response.
required:
- data
- total
- page
- limit
properties:
data:
type: array
items:
$ref: '#/components/schemas/MarketplaceAgentCard'
total:
type: integer
description: Total number of public agents matching the query.
example: 58
page:
type: integer
description: Current page number (1-based).
example: 1
limit:
type: integer
description: Number of results per page.
example: 20
ErrorResponse:
type: object
description: Standard error response envelope.
required:
- code
- message
properties:
code:
type: string
example: "AGENT_NOT_FOUND"
message:
type: string
example: "Agent with the specified ID was not found."
details:
type: object
additionalProperties: true
paths:
/marketplace/agents:
get:
operationId: listPublicAgents
tags:
- Marketplace
summary: List public agents
description: |
Returns a paginated list of agents that have been marked as public.
Supports full-text search across `owner`, `capabilities`, and `agentType`
via the `q` parameter. Results can be filtered by `capability` or `publisher`.
**Unauthenticated** — no Bearer token required.
Returns `404` when the `MARKETPLACE_ENABLED` feature flag is set to `false`.
security: []
parameters:
- name: q
in: query
required: false
description: |
Full-text search query across agent owner, capabilities, and agent type.
schema:
type: string
example: "resume screener"
- name: capability
in: query
required: false
description: Filter by a specific capability string (exact match).
schema:
type: string
example: "resume:read"
- name: publisher
in: query
required: false
description: Filter by owner/publisher name (exact match).
schema:
type: string
example: "talent-acquisition-team"
- name: page
in: query
required: false
schema:
type: integer
minimum: 1
default: 1
example: 1
- name: limit
in: query
required: false
schema:
type: integer
minimum: 1
maximum: 100
default: 20
example: 20
responses:
'200':
description: Paginated list of public agents returned successfully.
content:
application/json:
schema:
$ref: '#/components/schemas/PaginatedMarketplaceResponse'
example:
data:
- agentId: "a1b2c3d4-e5f6-7890-abcd-ef1234567890"
agentType: "screener"
version: "1.4.2"
capabilities:
- "resume:read"
- "email:send"
- "candidate:score"
owner: "talent-acquisition-team"
deploymentEnv: "production"
did: "did:web:api.sentryagent.ai:agents:a1b2c3d4-e5f6-7890-abcd-ef1234567890"
didDocument: null
publishedAt: "2026-03-01T08:00:00.000Z"
- agentId: "b2c3d4e5-f6a7-8901-bcde-f12345678901"
agentType: "classifier"
version: "2.1.0"
capabilities:
- "document:classify"
- "label:write"
owner: "platform-team"
deploymentEnv: "staging"
did: null
didDocument: null
publishedAt: "2026-03-10T10:00:00.000Z"
total: 58
page: 1
limit: 20
'400':
description: Invalid query parameters.
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
example:
code: "VALIDATION_ERROR"
message: "Invalid query parameter value."
details:
field: "limit"
reason: "Must be between 1 and 100."
'404':
description: Marketplace is not enabled on this instance.
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
example:
code: "NOT_FOUND"
message: "The Agent Marketplace is not enabled on this instance."
'500':
description: Unexpected server error.
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
example:
code: "INTERNAL_SERVER_ERROR"
message: "An unexpected error occurred. Please try again later."
/marketplace/agents/{agentId}:
get:
operationId: getPublicAgent
tags:
- Marketplace
summary: Get public agent detail
description: |
Returns the full public profile for a specific marketplace-listed agent,
including its DID Document (if a DID has been generated).
Only agents with `isPublic: true` are accessible via this endpoint.
Attempting to retrieve a private agent returns `404`.
**Unauthenticated** — no Bearer token required.
Returns `404` when the `MARKETPLACE_ENABLED` feature flag is set to `false`.
security: []
parameters:
- name: agentId
in: path
required: true
description: UUID of the public agent.
schema:
type: string
format: uuid
example: "a1b2c3d4-e5f6-7890-abcd-ef1234567890"
responses:
'200':
description: Public agent detail returned successfully.
content:
application/json:
schema:
$ref: '#/components/schemas/MarketplaceAgentCard'
example:
agentId: "a1b2c3d4-e5f6-7890-abcd-ef1234567890"
agentType: "screener"
version: "1.4.2"
capabilities:
- "resume:read"
- "email:send"
- "candidate:score"
owner: "talent-acquisition-team"
deploymentEnv: "production"
did: "did:web:api.sentryagent.ai:agents:a1b2c3d4-e5f6-7890-abcd-ef1234567890"
didDocument:
"@context":
- "https://www.w3.org/ns/did/v1"
id: "did:web:api.sentryagent.ai:agents:a1b2c3d4-e5f6-7890-abcd-ef1234567890"
controller: "did:web:api.sentryagent.ai"
verificationMethod:
- id: "did:web:api.sentryagent.ai:agents:a1b2c3d4-e5f6-7890-abcd-ef1234567890#key-1"
type: "JsonWebKey2020"
controller: "did:web:api.sentryagent.ai:agents:a1b2c3d4-e5f6-7890-abcd-ef1234567890"
publicKeyJwk:
kty: "EC"
crv: "P-256"
x: "f83OJ3D..."
y: "x_FEzRu..."
authentication:
- id: "did:web:api.sentryagent.ai:agents:a1b2c3d4-e5f6-7890-abcd-ef1234567890#key-1"
publishedAt: "2026-03-01T08:00:00.000Z"
'404':
description: Agent not found, not public, or marketplace not enabled.
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
examples:
agentNotFound:
summary: Agent not found or not public
value:
code: "AGENT_NOT_FOUND"
message: "Agent with the specified ID was not found."
marketplaceDisabled:
summary: Marketplace feature disabled
value:
code: "NOT_FOUND"
message: "The Agent Marketplace is not enabled on this instance."
'500':
description: Unexpected server error.
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
example:
code: "INTERNAL_SERVER_ERROR"
message: "An unexpected error occurred. Please try again later."

106
docs/openapi/metrics.yaml Normal file
View File

@@ -0,0 +1,106 @@
openapi: "3.0.3"
info:
title: SentryAgent.ai — Prometheus Metrics Endpoint
version: 1.0.0
description: |
Internal Prometheus metrics endpoint for the SentryAgent.ai AgentIdP platform.
This endpoint returns metrics in **Prometheus text exposition format** (v0.0.4).
It is intended exclusively for internal Prometheus scraping.
**Security notice:** This endpoint is **unauthenticated** and MUST NOT be
exposed on a public-facing network interface. Restrict access via network
policy, firewall rules, or a reverse-proxy that only allows Prometheus
scraper IP ranges to reach `/metrics`.
Metrics exported include:
- HTTP request counts and latencies (by route and status code)
- Token issuance, introspection, and revocation counters
- Agent registration and decommission counters
- Active registered agent gauge
- Database connection pool metrics
- Process memory and CPU metrics (via `prom-client` defaults)
servers:
- url: http://localhost:3000
description: Local development server (internal only)
- url: https://api.sentryagent.ai
description: Production server (restrict to Prometheus scraper)
tags:
- name: Metrics
description: Prometheus metrics scrape endpoint
components:
schemas:
PrometheusMetrics:
type: string
description: |
Metrics in Prometheus text exposition format (v0.0.4).
Each metric family is preceded by `# HELP` and `# TYPE` comment lines.
example: |
# HELP process_cpu_user_seconds_total Total user CPU time spent in seconds.
# TYPE process_cpu_user_seconds_total counter
process_cpu_user_seconds_total 0.123456
# HELP http_requests_total Total number of HTTP requests.
# TYPE http_requests_total counter
http_requests_total{method="POST",route="/api/v1/token",status_code="200"} 4201
http_requests_total{method="GET",route="/api/v1/agents",status_code="200"} 987
ErrorResponse:
type: object
description: Standard error response envelope.
required:
- code
- message
properties:
code:
type: string
example: "INTERNAL_SERVER_ERROR"
message:
type: string
example: "An unexpected error occurred. Please try again later."
paths:
/metrics:
get:
operationId: scrapeMetrics
tags:
- Metrics
summary: Prometheus metrics scrape endpoint
description: |
Returns all registered metrics in Prometheus text exposition format.
The `Content-Type` header in the response is set to the value reported
by the `prom-client` registry (`text/plain; version=0.0.4; charset=utf-8`).
This endpoint is **unauthenticated** and is intended for internal
Prometheus scraping only. Do not expose on public interfaces.
security: []
responses:
'200':
description: Metrics in Prometheus text exposition format.
content:
text/plain:
schema:
$ref: '#/components/schemas/PrometheusMetrics'
example: |
# HELP process_cpu_user_seconds_total Total user CPU time spent in seconds.
# TYPE process_cpu_user_seconds_total counter
process_cpu_user_seconds_total 0.123456
# HELP sentryagent_tokens_issued_total Total tokens issued.
# TYPE sentryagent_tokens_issued_total counter
sentryagent_tokens_issued_total 4201
# HELP sentryagent_agents_registered_total Total agents registered.
# TYPE sentryagent_agents_registered_total counter
sentryagent_agents_registered_total 120
'500':
description: Unexpected error while collecting metrics.
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
example:
code: INTERNAL_SERVER_ERROR
message: "An unexpected error occurred. Please try again later."

View File

@@ -0,0 +1,228 @@
openapi: "3.0.3"
info:
title: SentryAgent.ai — OIDC Token Exchange (Workload Identity Federation)
version: 1.0.0
description: |
OIDC Token Exchange endpoint for Workload Identity Federation on the
SentryAgent.ai AgentIdP platform.
This endpoint allows CI/CD workflows (e.g. GitHub Actions) to exchange their
short-lived OIDC JWT for a SentryAgent.ai Bearer access token without requiring
long-lived credentials stored as secrets.
**Flow:**
1. Tenant creates a trust policy via `POST /api/v1/oidc/trust-policies`
linking a GitHub repo + optional branch to an agent UUID.
2. In the GitHub Actions workflow, fetch the OIDC token:
```
id-token: write # required permissions block
OIDC_TOKEN=$(curl -H "Authorization: bearer $ACTIONS_ID_TOKEN_REQUEST_TOKEN" \
"$ACTIONS_ID_TOKEN_REQUEST_URL" | jq -r .value)
```
3. POST the GitHub OIDC token to `POST /api/v1/oidc/token`.
4. Receive a SentryAgent.ai Bearer token valid for 1 hour.
**This endpoint is unauthenticated** — the GitHub OIDC JWT IS the credential.
Trust-policy enforcement is performed server-side.
servers:
- url: http://localhost:3000/api/v1
description: Local development server
- url: https://api.sentryagent.ai/v1
description: Production server
tags:
- name: OIDC Token Exchange
description: Workload Identity Federation token exchange (unauthenticated)
components:
schemas:
OIDCTokenExchangeRequest:
type: object
description: |
Request body for exchanging a GitHub OIDC JWT for a SentryAgent.ai access token.
required:
- token
properties:
token:
type: string
description: |
The GitHub OIDC JWT obtained from the GitHub Actions token request endpoint.
Must be a valid, unexpired JWT signed by GitHub.
example: "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJyZXBvOmFjbWUtY29ycC9hZ2VudC1kZXBsb3llcjpyZWY6cmVmcy9oZWFkcy9tYWluIiwiaXNzIjoiaHR0cHM6Ly90b2tlbi5hY3Rpb25zLmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImV4cCI6MTc0MzE1NDgwMH0.signature"
OIDCTokenExchangeResponse:
type: object
description: SentryAgent.ai Bearer access token issued in exchange for the OIDC JWT.
required:
- access_token
- token_type
- expires_in
- scope
properties:
access_token:
type: string
description: |
Signed JWT access token. Use as `Authorization: Bearer <access_token>`
in subsequent API calls.
example: "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJhMWIyYzNkNC1lNWY2LTc4OTAtYWJjZC1lZjEyMzQ1Njc4OTAiLCJzY29wZSI6ImFnZW50czpyZWFkIGFnZW50czp3cml0ZSIsImlhdCI6MTc0MzE1MTIwMCwiZXhwIjoxNzQzMTU0ODAwfQ.signature"
token_type:
type: string
enum:
- Bearer
description: Token type. Always `Bearer`.
example: "Bearer"
expires_in:
type: integer
description: Token lifetime in seconds from issuance. Default is `3600`.
example: 3600
scope:
type: string
description: Space-separated OAuth 2.0 scopes granted by this token.
example: "agents:read agents:write"
ErrorResponse:
type: object
description: Standard error response envelope.
required:
- code
- message
properties:
code:
type: string
example: "TRUST_POLICY_NOT_FOUND"
message:
type: string
example: "No trust policy matches the provided OIDC token claims."
details:
type: object
additionalProperties: true
responses:
InternalServerError:
description: Unexpected server error.
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
example:
code: "INTERNAL_SERVER_ERROR"
message: "An unexpected error occurred. Please try again later."
paths:
/oidc/token:
post:
operationId: exchangeOIDCToken
tags:
- OIDC Token Exchange
summary: Exchange a GitHub OIDC JWT for a SentryAgent.ai access token
description: |
Exchanges a GitHub Actions OIDC JWT for a SentryAgent.ai Bearer access token.
**Verification steps performed server-side:**
1. Decode and validate the GitHub OIDC JWT signature against GitHub's JWKS.
2. Verify the token is not expired.
3. Match the token's `sub` claim (format: `repo:<org>/<repo>:ref:refs/heads/<branch>`)
against registered trust policies.
4. Apply branch constraint if the matching policy has one.
5. Verify the linked agent is active and not decommissioned.
6. Issue a SentryAgent.ai access token scoped to the linked agent.
**This endpoint is unauthenticated** — the GitHub OIDC JWT serves as the credential.
**GitHub Actions example:**
```yaml
permissions:
id-token: write
contents: read
steps:
- name: Get OIDC token and exchange
run: |
GITHUB_TOKEN=$(curl -sH "Authorization: bearer $ACTIONS_ID_TOKEN_REQUEST_TOKEN" \
"$ACTIONS_ID_TOKEN_REQUEST_URL&audience=api.sentryagent.ai" | jq -r .value)
AGENT_TOKEN=$(curl -sX POST https://api.sentryagent.ai/api/v1/oidc/token \
-H 'Content-Type: application/json' \
-d "{\"token\": \"$GITHUB_TOKEN\"}" | jq -r .access_token)
```
security: []
requestBody:
required: true
content:
application/json:
schema:
$ref: '#/components/schemas/OIDCTokenExchangeRequest'
example:
token: "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJyZXBvOmFjbWUtY29ycC9hZ2VudC1kZXBsb3llcjpyZWY6cmVmcy9oZWFkcy9tYWluIiwiaXNzIjoiaHR0cHM6Ly90b2tlbi5hY3Rpb25zLmdpdGh1YnVzZXJjb250ZW50LmNvbSJ9.signature"
responses:
'200':
description: SentryAgent.ai access token issued successfully.
headers:
Cache-Control:
schema:
type: string
description: Token responses must not be cached.
example: "no-store"
content:
application/json:
schema:
$ref: '#/components/schemas/OIDCTokenExchangeResponse'
example:
access_token: "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJhMWIyYzNkNC1lNWY2LTc4OTAtYWJjZC1lZjEyMzQ1Njc4OTAiLCJzY29wZSI6ImFnZW50czpyZWFkIGFnZW50czp3cml0ZSIsImlhdCI6MTc0MzE1MTIwMCwiZXhwIjoxNzQzMTU0ODAwfQ.signature"
token_type: "Bearer"
expires_in: 3600
scope: "agents:read agents:write"
'400':
description: Missing or malformed `token` field in request body.
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
example:
code: "VALIDATION_ERROR"
message: "The 'token' field is required."
'401':
description: The provided OIDC token is invalid, expired, or has an invalid signature.
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
examples:
expired:
summary: Token is expired
value:
code: "OIDC_TOKEN_EXPIRED"
message: "The provided GitHub OIDC token has expired."
invalidSignature:
summary: Invalid signature
value:
code: "OIDC_TOKEN_INVALID"
message: "The provided GitHub OIDC token signature is invalid."
'403':
description: Token claims do not match any active trust policy, or the linked agent is inactive.
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
examples:
noPolicy:
summary: No matching trust policy
value:
code: "TRUST_POLICY_NOT_FOUND"
message: "No trust policy matches the provided OIDC token claims."
branchMismatch:
summary: Branch constraint not satisfied
value:
code: "TRUST_POLICY_BRANCH_MISMATCH"
message: "The token's branch does not match the trust policy constraint."
details:
allowed: "main"
provided: "feature/xyz"
agentSuspended:
summary: Linked agent is suspended
value:
code: "AGENT_SUSPENDED"
message: "The agent linked to this trust policy is currently suspended."
'500':
$ref: '#/components/responses/InternalServerError'

View File

@@ -0,0 +1,384 @@
openapi: "3.0.3"
info:
title: SentryAgent.ai — OIDC Trust Policies
version: 1.0.0
description: |
OIDC trust policy management endpoints for the SentryAgent.ai AgentIdP platform.
Trust policies allow tenants to configure Workload Identity Federation:
workflows running in a trusted OIDC provider (e.g. GitHub Actions) can exchange
their OIDC JWT for a SentryAgent.ai access token without long-lived credentials.
**Supported OIDC providers:** `github`
**Workflow:**
1. Create a trust policy linking a GitHub repo (+ optional branch) to an agent UUID
2. In your GitHub Actions workflow, call `POST /api/v1/oidc/token` with the GitHub OIDC JWT
3. Receive a SentryAgent.ai Bearer token scoped to the linked agent
**All endpoints require a valid Bearer JWT.**
servers:
- url: http://localhost:3000/api/v1
description: Local development server
- url: https://api.sentryagent.ai/v1
description: Production server
tags:
- name: OIDC Trust Policies
description: Workload Identity Federation trust policy management
components:
securitySchemes:
BearerAuth:
type: http
scheme: bearer
bearerFormat: JWT
description: |
JWT access token obtained via `POST /token`.
Include as `Authorization: Bearer <token>`.
schemas:
OIDCProvider:
type: string
enum:
- github
description: |
Supported OIDC provider identifier.
Currently only "github" is supported; the list is extensible.
example: github
OIDCTrustPolicy:
type: object
description: A persisted OIDC trust policy record.
required:
- id
- provider
- repository
- agentId
- createdAt
- updatedAt
properties:
id:
type: string
format: uuid
description: Immutable system-assigned UUID for this trust policy.
readOnly: true
example: "tp-abcd-1234-5678-ef01"
provider:
$ref: '#/components/schemas/OIDCProvider'
repository:
type: string
description: |
GitHub repository in "org/repo" format.
Only workflows running in this repository may exchange tokens.
pattern: '^[a-zA-Z0-9._-]+/[a-zA-Z0-9._-]+$'
example: "acme-corp/agent-deployer"
branch:
type: string
nullable: true
description: |
Optional branch constraint. When set, only the specified branch may
exchange tokens. When null, any branch in the repository is allowed.
example: "main"
agentId:
type: string
format: uuid
description: UUID of the agent this trust policy grants access to.
example: "a1b2c3d4-e5f6-7890-abcd-ef1234567890"
createdAt:
type: string
format: date-time
readOnly: true
example: "2026-03-01T08:00:00.000Z"
updatedAt:
type: string
format: date-time
readOnly: true
example: "2026-03-28T11:30:00.000Z"
CreateTrustPolicyRequest:
type: object
description: Request body for registering a new OIDC trust policy.
required:
- provider
- repository
- agentId
properties:
provider:
$ref: '#/components/schemas/OIDCProvider'
repository:
type: string
description: |
GitHub repository in "org/repo" format. Case-sensitive.
Only workflows in this repository may use this trust policy.
pattern: '^[a-zA-Z0-9._-]+/[a-zA-Z0-9._-]+$'
example: "acme-corp/agent-deployer"
branch:
type: string
description: |
Optional branch constraint. When omitted, any branch in the repository is permitted.
Recommended to set this to `main` for production trust policies.
example: "main"
agentId:
type: string
format: uuid
description: |
UUID of the agent to grant access to.
The agent must be registered and active in the same organization.
example: "a1b2c3d4-e5f6-7890-abcd-ef1234567890"
ErrorResponse:
type: object
description: Standard error response envelope.
required:
- code
- message
properties:
code:
type: string
example: "TRUST_POLICY_NOT_FOUND"
message:
type: string
example: "Trust policy with the specified ID was not found."
details:
type: object
additionalProperties: true
responses:
Unauthorized:
description: Missing or invalid Bearer token.
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
example:
code: "UNAUTHORIZED"
message: "A valid Bearer token is required to access this resource."
Forbidden:
description: Valid token but insufficient permissions.
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
example:
code: "FORBIDDEN"
message: "You do not have permission to perform this action."
NotFound:
description: Trust policy not found.
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
example:
code: "TRUST_POLICY_NOT_FOUND"
message: "Trust policy with the specified ID was not found."
InternalServerError:
description: Unexpected server error.
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
example:
code: "INTERNAL_SERVER_ERROR"
message: "An unexpected error occurred. Please try again later."
security:
- BearerAuth: []
paths:
/oidc/trust-policies:
post:
operationId: createOIDCTrustPolicy
tags:
- OIDC Trust Policies
summary: Create an OIDC trust policy
description: |
Registers a new OIDC trust policy.
Once created, workflows running in the specified GitHub repository
(and optionally matching the specified branch) can exchange their
GitHub OIDC JWT for a SentryAgent.ai access token via `POST /oidc/token`.
A trust policy is organization-scoped — the agent referenced by `agentId`
must belong to the same organization as the authenticated caller.
Requires a valid Bearer JWT (minimum `agents:write` scope recommended).
requestBody:
required: true
content:
application/json:
schema:
$ref: '#/components/schemas/CreateTrustPolicyRequest'
example:
provider: "github"
repository: "acme-corp/agent-deployer"
branch: "main"
agentId: "a1b2c3d4-e5f6-7890-abcd-ef1234567890"
responses:
'201':
description: Trust policy created successfully.
content:
application/json:
schema:
$ref: '#/components/schemas/OIDCTrustPolicy'
example:
id: "tp-abcd-1234-5678-ef01"
provider: "github"
repository: "acme-corp/agent-deployer"
branch: "main"
agentId: "a1b2c3d4-e5f6-7890-abcd-ef1234567890"
createdAt: "2026-04-07T09:00:00.000Z"
updatedAt: "2026-04-07T09:00:00.000Z"
'400':
description: Validation error in request body.
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
examples:
invalidProvider:
summary: Unsupported OIDC provider
value:
code: "VALIDATION_ERROR"
message: "Request validation failed."
details:
field: "provider"
reason: "Only 'github' is supported."
invalidRepository:
summary: Invalid repository format
value:
code: "VALIDATION_ERROR"
message: "Request validation failed."
details:
field: "repository"
reason: "Must be in 'org/repo' format."
'401':
$ref: '#/components/responses/Unauthorized'
'403':
$ref: '#/components/responses/Forbidden'
'404':
description: Referenced agent not found in this organization.
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
example:
code: "AGENT_NOT_FOUND"
message: "Agent with the specified ID was not found."
'409':
description: A trust policy for this provider/repository/branch combination already exists.
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
example:
code: "TRUST_POLICY_CONFLICT"
message: "A trust policy for this repository and branch already exists."
details:
provider: "github"
repository: "acme-corp/agent-deployer"
branch: "main"
'500':
$ref: '#/components/responses/InternalServerError'
get:
operationId: listOIDCTrustPolicies
tags:
- OIDC Trust Policies
summary: List OIDC trust policies
description: |
Returns all trust policies for the authenticated organization,
optionally filtered by the `agentId` query parameter.
Requires a valid Bearer JWT.
parameters:
- name: agentId
in: query
required: false
description: Filter trust policies linked to a specific agent UUID.
schema:
type: string
format: uuid
example: "a1b2c3d4-e5f6-7890-abcd-ef1234567890"
responses:
'200':
description: List of trust policies returned successfully.
content:
application/json:
schema:
type: array
items:
$ref: '#/components/schemas/OIDCTrustPolicy'
example:
- id: "tp-abcd-1234-5678-ef01"
provider: "github"
repository: "acme-corp/agent-deployer"
branch: "main"
agentId: "a1b2c3d4-e5f6-7890-abcd-ef1234567890"
createdAt: "2026-03-01T08:00:00.000Z"
updatedAt: "2026-03-01T08:00:00.000Z"
- id: "tp-efgh-5678-1234-ab01"
provider: "github"
repository: "acme-corp/inference-runner"
branch: null
agentId: "b2c3d4e5-f6a7-8901-bcde-f12345678901"
createdAt: "2026-03-15T10:00:00.000Z"
updatedAt: "2026-03-15T10:00:00.000Z"
'400':
description: Invalid query parameters.
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
example:
code: "VALIDATION_ERROR"
message: "Invalid query parameter value."
details:
field: "agentId"
reason: "Must be a valid UUID."
'401':
$ref: '#/components/responses/Unauthorized'
'403':
$ref: '#/components/responses/Forbidden'
'500':
$ref: '#/components/responses/InternalServerError'
/oidc/trust-policies/{id}:
parameters:
- name: id
in: path
required: true
description: UUID of the trust policy to delete.
schema:
type: string
format: uuid
example: "tp-abcd-1234-5678-ef01"
delete:
operationId: deleteOIDCTrustPolicy
tags:
- OIDC Trust Policies
summary: Delete an OIDC trust policy
description: |
Permanently deletes an OIDC trust policy.
After deletion, workflows that previously used this policy to exchange
GitHub OIDC tokens will receive `403 Forbidden` from `POST /oidc/token`.
Requires a valid Bearer JWT.
responses:
'204':
description: Trust policy deleted successfully. No response body.
'401':
$ref: '#/components/responses/Unauthorized'
'403':
$ref: '#/components/responses/Forbidden'
'404':
$ref: '#/components/responses/NotFound'
'500':
$ref: '#/components/responses/InternalServerError'

View File

@@ -0,0 +1,410 @@
openapi: "3.0.3"
info:
title: SentryAgent.ai — OIDC Well-Known & Agent Info
version: 1.0.0
description: |
OpenID Connect discovery, JWKS, and agent identity endpoints for the
SentryAgent.ai AgentIdP platform.
**Unauthenticated endpoints** (public metadata):
- `GET /.well-known/openid-configuration` — OIDC Discovery Document
- `GET /.well-known/jwks.json` — JSON Web Key Set (public signing keys)
**Authenticated endpoint** (requires Bearer JWT):
- `GET /agent-info` — Agent identity claims (equivalent to OIDC UserInfo)
All endpoints are mounted at the application root (`/`) so that
`/.well-known/*` paths resolve correctly without an `/api/v1` prefix.
servers:
- url: http://localhost:3000
description: Local development server
- url: https://api.sentryagent.ai
description: Production server
tags:
- name: OIDC Discovery
description: Public OIDC metadata endpoints (unauthenticated)
- name: Agent Info
description: Authenticated agent identity endpoint
components:
securitySchemes:
BearerAuth:
type: http
scheme: bearer
bearerFormat: JWT
description: |
JWT access token obtained via `POST /api/v1/token`.
Include as `Authorization: Bearer <token>`.
schemas:
OIDCDiscoveryDocument:
type: object
description: |
OpenID Connect Discovery 1.0 document as defined in the OIDC specification.
Returned by `GET /.well-known/openid-configuration`.
required:
- issuer
- authorization_endpoint
- token_endpoint
- jwks_uri
- response_types_supported
- subject_types_supported
- id_token_signing_alg_values_supported
- scopes_supported
- claims_supported
- grant_types_supported
properties:
issuer:
type: string
format: uri
description: OIDC Issuer URL. Must match the `iss` claim in ID tokens.
example: "https://idp.sentryagent.ai"
authorization_endpoint:
type: string
format: uri
description: Authorization endpoint (stub — not implemented; client_credentials only).
example: "https://idp.sentryagent.ai/oauth2/authorize"
token_endpoint:
type: string
format: uri
description: Token endpoint for the client_credentials grant.
example: "https://idp.sentryagent.ai/oauth2/token"
jwks_uri:
type: string
format: uri
description: JWKS endpoint for ID token verification public keys.
example: "https://idp.sentryagent.ai/.well-known/jwks.json"
response_types_supported:
type: array
items:
type: string
description: Supported response types.
example: ["token", "id_token"]
subject_types_supported:
type: array
items:
type: string
description: Supported subject types.
example: ["public"]
id_token_signing_alg_values_supported:
type: array
items:
type: string
description: Supported ID token signing algorithms.
example: ["RS256", "ES256"]
scopes_supported:
type: array
items:
type: string
description: Supported OAuth 2.0 scopes.
example: ["openid", "agents:read", "agents:write", "tokens:read", "audit:read", "admin:orgs"]
claims_supported:
type: array
items:
type: string
description: Claims that may appear in ID tokens or the agent-info response.
example: ["sub", "iss", "aud", "iat", "exp", "agent_type", "deployment_env", "organization_id", "did"]
grant_types_supported:
type: array
items:
type: string
description: Supported grant types.
example: ["client_credentials"]
JWKSKey:
type: object
description: A single JSON Web Key. Supports RSA (RS256) and EC P-256 (ES256) keys.
required:
- kid
- kty
- use
- alg
properties:
kid:
type: string
description: Key ID — matches the `kid` header in signed JWTs.
example: "key-20260328-001"
kty:
type: string
description: Key type.
enum:
- RSA
- EC
example: "RSA"
use:
type: string
description: Intended use. Always `sig` for signing keys.
example: "sig"
alg:
type: string
description: Algorithm.
enum:
- RS256
- ES256
example: "RS256"
n:
type: string
description: RSA — Base64url-encoded modulus.
example: "sI3P8XVb..."
e:
type: string
description: RSA — Base64url-encoded public exponent.
example: "AQAB"
crv:
type: string
description: EC — Curve name.
example: "P-256"
x:
type: string
description: EC — Base64url-encoded x coordinate.
example: "f83OJ3D..."
y:
type: string
description: EC — Base64url-encoded y coordinate.
example: "x_FEzRu..."
JWKSResponse:
type: object
description: JSON Web Key Set returned by `GET /.well-known/jwks.json`.
required:
- keys
properties:
keys:
type: array
description: |
Array of JSON Web Keys. Includes all non-expired keys to support
key rotation grace periods.
items:
$ref: '#/components/schemas/JWKSKey'
AgentInfoResponse:
type: object
description: |
Agent identity claims for the authenticated caller.
Analogous to the OIDC UserInfo endpoint.
required:
- sub
- agent_type
- deployment_env
- organization_id
- scope
properties:
sub:
type: string
format: uuid
description: Agent UUID (subject).
example: "a1b2c3d4-e5f6-7890-abcd-ef1234567890"
agent_type:
type: string
description: Functional classification of the agent.
example: "screener"
deployment_env:
type: string
description: Target deployment environment of the agent.
example: "production"
organization_id:
type: string
format: uuid
description: Organization UUID the agent belongs to.
example: "org-1234-5678-abcd-ef01"
did:
type: string
description: W3C DID identifier for the agent, if one has been generated.
example: "did:web:api.sentryagent.ai:agents:a1b2c3d4-e5f6-7890-abcd-ef1234567890"
scope:
type: string
description: OAuth 2.0 scope associated with the Bearer token used to call this endpoint.
example: "agents:read agents:write"
ErrorResponse:
type: object
description: Standard error response envelope.
required:
- code
- message
properties:
code:
type: string
example: "UNAUTHORIZED"
message:
type: string
example: "A valid Bearer token is required to access this resource."
details:
type: object
additionalProperties: true
responses:
Unauthorized:
description: Missing or invalid Bearer token.
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
example:
code: "UNAUTHORIZED"
message: "A valid Bearer token is required to access this resource."
NotFound:
description: The requested resource was not found.
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
example:
code: "AGENT_NOT_FOUND"
message: "Agent with the specified ID was not found."
InternalServerError:
description: Unexpected server error.
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
example:
code: "INTERNAL_SERVER_ERROR"
message: "An unexpected error occurred. Please try again later."
paths:
/.well-known/openid-configuration:
get:
operationId: getOIDCDiscoveryDocument
tags:
- OIDC Discovery
summary: OIDC Discovery Document
description: |
Returns the OpenID Connect Discovery 1.0 document for the SentryAgent.ai AgentIdP.
Consumers can fetch this document to auto-discover the token endpoint,
JWKS URI, supported scopes, and supported claims — without hard-coding URLs.
This endpoint is **unauthenticated** and publicly cacheable.
security: []
responses:
'200':
description: OIDC Discovery Document returned successfully.
content:
application/json:
schema:
$ref: '#/components/schemas/OIDCDiscoveryDocument'
example:
issuer: "https://idp.sentryagent.ai"
authorization_endpoint: "https://idp.sentryagent.ai/oauth2/authorize"
token_endpoint: "https://idp.sentryagent.ai/oauth2/token"
jwks_uri: "https://idp.sentryagent.ai/.well-known/jwks.json"
response_types_supported:
- token
- id_token
subject_types_supported:
- public
id_token_signing_alg_values_supported:
- RS256
- ES256
scopes_supported:
- openid
- agents:read
- agents:write
- tokens:read
- audit:read
- admin:orgs
claims_supported:
- sub
- iss
- aud
- iat
- exp
- agent_type
- deployment_env
- organization_id
- did
grant_types_supported:
- client_credentials
'500':
$ref: '#/components/responses/InternalServerError'
/.well-known/jwks.json:
get:
operationId: getJWKS
tags:
- OIDC Discovery
summary: JSON Web Key Set (public signing keys)
description: |
Returns the JSON Web Key Set (JWKS) containing all active public keys
used to sign ID tokens. Consumers use this to verify ID token signatures.
All non-expired keys are returned to support key rotation grace periods —
a token signed with a recently-rotated key will still verify correctly
if the old key appears in the JWKS response.
**Cache-Control:** `public, max-age=3600` — responses may be cached for up to 1 hour.
This endpoint is **unauthenticated**.
security: []
responses:
'200':
description: JWKS returned successfully.
headers:
Cache-Control:
schema:
type: string
description: Caching directive. Always `public, max-age=3600`.
example: "public, max-age=3600"
content:
application/json:
schema:
$ref: '#/components/schemas/JWKSResponse'
example:
keys:
- kid: "key-20260328-001"
kty: "RSA"
use: "sig"
alg: "RS256"
n: "sI3P8XVb..."
e: "AQAB"
'500':
$ref: '#/components/responses/InternalServerError'
/agent-info:
get:
operationId: getAgentInfo
tags:
- Agent Info
summary: Get authenticated agent identity claims
description: |
Returns identity claims for the agent authenticated by the provided Bearer token.
Equivalent to the OIDC UserInfo endpoint — returns the agent's type,
deployment environment, organization, DID (if generated), and active scopes.
The agent UUID is read from the `sub` claim of the Bearer token.
Requires a valid Bearer JWT.
security:
- BearerAuth: []
responses:
'200':
description: Agent identity claims returned successfully.
content:
application/json:
schema:
$ref: '#/components/schemas/AgentInfoResponse'
example:
sub: "a1b2c3d4-e5f6-7890-abcd-ef1234567890"
agent_type: "screener"
deployment_env: "production"
organization_id: "org-1234-5678-abcd-ef01"
did: "did:web:api.sentryagent.ai:agents:a1b2c3d4-e5f6-7890-abcd-ef1234567890"
scope: "agents:read agents:write"
'401':
$ref: '#/components/responses/Unauthorized'
'404':
description: The agent referenced in the token no longer exists.
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
example:
code: "AGENT_NOT_FOUND"
message: "Agent with the specified ID was not found."
'500':
$ref: '#/components/responses/InternalServerError'

View File

@@ -0,0 +1,707 @@
openapi: "3.0.3"
info:
title: SentryAgent.ai — Organizations (Multi-Tenancy)
version: 1.0.0
description: |
Organization (tenant) management endpoints for the SentryAgent.ai AgentIdP platform.
Organizations are the top-level multi-tenancy boundary. Each organization has its
own pool of registered agents, plan-tier limits, and billing context.
**All endpoints require a valid Bearer JWT** with appropriate OPA-enforced scope.
**Plan Tiers:**
| Tier | Max Agents | Max Tokens/Month |
|------|-----------|-----------------|
| `free` | 100 | 10,000 |
| `pro` | 1,000 | 100,000 |
| `enterprise` | unlimited | unlimited |
servers:
- url: http://localhost:3000/api/v1
description: Local development server
- url: https://api.sentryagent.ai/v1
description: Production server
tags:
- name: Organizations
description: CRUD operations for organizations (tenants)
- name: Organization Members
description: Agent membership management within organizations
components:
securitySchemes:
BearerAuth:
type: http
scheme: bearer
bearerFormat: JWT
description: |
JWT access token obtained via `POST /token`.
Include as `Authorization: Bearer <token>`.
schemas:
PlanTier:
type: string
enum:
- free
- pro
- enterprise
description: Subscription plan tier for an organization.
example: pro
OrgStatus:
type: string
enum:
- active
- suspended
- deleted
description: Lifecycle status of an organization.
example: active
OrgRole:
type: string
enum:
- member
- admin
description: Role of an agent within an organization.
example: member
Organization:
type: object
description: Full representation of a registered organization (tenant).
required:
- organizationId
- name
- slug
- planTier
- maxAgents
- maxTokensPerMonth
- status
- createdAt
- updatedAt
properties:
organizationId:
type: string
format: uuid
description: Immutable, system-assigned unique identifier for the organization.
readOnly: true
example: "org-1234-5678-abcd-ef01"
name:
type: string
description: Human-readable display name of the organization.
minLength: 1
maxLength: 256
example: "Acme Corp"
slug:
type: string
description: |
URL-friendly unique identifier. Lowercase letters, digits, and hyphens only.
Immutable after creation.
pattern: '^[a-z0-9-]+$'
example: "acme-corp"
planTier:
$ref: '#/components/schemas/PlanTier'
maxAgents:
type: integer
description: Maximum number of agents permitted in this organization.
minimum: 1
example: 100
maxTokensPerMonth:
type: integer
description: Maximum OAuth 2.0 token requests per calendar month.
minimum: 1
example: 10000
status:
$ref: '#/components/schemas/OrgStatus'
createdAt:
type: string
format: date-time
readOnly: true
example: "2026-03-01T08:00:00.000Z"
updatedAt:
type: string
format: date-time
readOnly: true
example: "2026-03-28T11:30:00.000Z"
CreateOrgRequest:
type: object
description: Request body for creating a new organization.
required:
- name
- slug
properties:
name:
type: string
description: Human-readable display name.
minLength: 1
maxLength: 256
example: "Acme Corp"
slug:
type: string
description: URL-friendly unique identifier. Lowercase letters, digits, hyphens only.
pattern: '^[a-z0-9-]+$'
minLength: 1
maxLength: 64
example: "acme-corp"
planTier:
$ref: '#/components/schemas/PlanTier'
description: Defaults to `free` when omitted.
maxAgents:
type: integer
description: Override the default max agents for this plan tier.
minimum: 1
example: 100
maxTokensPerMonth:
type: integer
description: Override the default max tokens per month.
minimum: 1
example: 10000
UpdateOrgRequest:
type: object
description: |
Request body for partially updating an organization.
All fields are optional; only provided fields are updated.
`status` may only be set to `active` or `suspended` via this endpoint;
`deleted` is applied only through the DELETE operation.
minProperties: 1
properties:
name:
type: string
minLength: 1
maxLength: 256
example: "Acme Corporation"
planTier:
$ref: '#/components/schemas/PlanTier'
maxAgents:
type: integer
minimum: 1
example: 1000
maxTokensPerMonth:
type: integer
minimum: 1
example: 100000
status:
type: string
enum:
- active
- suspended
description: Set to `active` to reactivate a suspended org, or `suspended` to disable it.
example: active
PaginatedOrgsResponse:
type: object
description: Paginated list of organizations.
required:
- data
- total
- page
- limit
properties:
data:
type: array
items:
$ref: '#/components/schemas/Organization'
total:
type: integer
example: 42
page:
type: integer
example: 1
limit:
type: integer
example: 20
OrgMember:
type: object
description: An agent's membership record within an organization.
required:
- memberId
- organizationId
- agentId
- role
- joinedAt
properties:
memberId:
type: string
format: uuid
readOnly: true
example: "mem-abcd-1234-5678-ef01"
organizationId:
type: string
format: uuid
example: "org-1234-5678-abcd-ef01"
agentId:
type: string
format: uuid
example: "a1b2c3d4-e5f6-7890-abcd-ef1234567890"
role:
$ref: '#/components/schemas/OrgRole'
joinedAt:
type: string
format: date-time
readOnly: true
example: "2026-03-28T09:00:00.000Z"
AddMemberRequest:
type: object
description: Request body for adding an agent to an organization.
required:
- agentId
- role
properties:
agentId:
type: string
format: uuid
description: UUID of the agent to add.
example: "a1b2c3d4-e5f6-7890-abcd-ef1234567890"
role:
$ref: '#/components/schemas/OrgRole'
ErrorResponse:
type: object
description: Standard error response envelope.
required:
- code
- message
properties:
code:
type: string
example: "VALIDATION_ERROR"
message:
type: string
example: "Request validation failed."
details:
type: object
additionalProperties: true
responses:
Unauthorized:
description: Missing or invalid Bearer token.
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
example:
code: "UNAUTHORIZED"
message: "A valid Bearer token is required to access this resource."
Forbidden:
description: Valid token but insufficient permissions.
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
example:
code: "FORBIDDEN"
message: "You do not have permission to perform this action."
NotFound:
description: Organization not found.
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
example:
code: "ORG_NOT_FOUND"
message: "Organization with the specified ID was not found."
TooManyRequests:
description: Rate limit exceeded.
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
example:
code: "RATE_LIMIT_EXCEEDED"
message: "Too many requests. Please retry after the rate limit window resets."
InternalServerError:
description: Unexpected server error.
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
example:
code: "INTERNAL_SERVER_ERROR"
message: "An unexpected error occurred. Please try again later."
security:
- BearerAuth: []
paths:
/organizations:
post:
operationId: createOrganization
tags:
- Organizations
summary: Create a new organization
description: |
Creates a new organization (tenant). The `slug` must be unique across all organizations
and is immutable after creation.
The requesting agent's organization context is determined from the Bearer token.
Requires `admin:orgs` scope.
requestBody:
required: true
content:
application/json:
schema:
$ref: '#/components/schemas/CreateOrgRequest'
example:
name: "Acme Corp"
slug: "acme-corp"
planTier: "pro"
maxAgents: 500
maxTokensPerMonth: 50000
responses:
'201':
description: Organization created successfully.
content:
application/json:
schema:
$ref: '#/components/schemas/Organization'
example:
organizationId: "org-1234-5678-abcd-ef01"
name: "Acme Corp"
slug: "acme-corp"
planTier: "pro"
maxAgents: 500
maxTokensPerMonth: 50000
status: "active"
createdAt: "2026-04-07T09:00:00.000Z"
updatedAt: "2026-04-07T09:00:00.000Z"
'400':
description: Validation error in request body.
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
example:
code: "VALIDATION_ERROR"
message: "Request validation failed."
details:
field: "slug"
reason: "slug must contain only lowercase letters, digits, and hyphens."
'401':
$ref: '#/components/responses/Unauthorized'
'403':
$ref: '#/components/responses/Forbidden'
'409':
description: An organization with the provided slug already exists.
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
example:
code: "ORG_SLUG_CONFLICT"
message: "An organization with this slug already exists."
details:
slug: "acme-corp"
'429':
$ref: '#/components/responses/TooManyRequests'
'500':
$ref: '#/components/responses/InternalServerError'
get:
operationId: listOrganizations
tags:
- Organizations
summary: List organizations
description: |
Returns a paginated list of organizations. Results can be filtered by `status`.
Results are ordered by `createdAt` descending.
Requires `admin:orgs` scope.
parameters:
- name: page
in: query
required: false
schema:
type: integer
minimum: 1
default: 1
example: 1
- name: limit
in: query
required: false
schema:
type: integer
minimum: 1
maximum: 100
default: 20
example: 20
- name: status
in: query
required: false
schema:
$ref: '#/components/schemas/OrgStatus'
responses:
'200':
description: Paginated list of organizations returned successfully.
content:
application/json:
schema:
$ref: '#/components/schemas/PaginatedOrgsResponse'
example:
data:
- organizationId: "org-1234-5678-abcd-ef01"
name: "Acme Corp"
slug: "acme-corp"
planTier: "pro"
maxAgents: 500
maxTokensPerMonth: 50000
status: "active"
createdAt: "2026-03-01T08:00:00.000Z"
updatedAt: "2026-03-28T11:30:00.000Z"
total: 42
page: 1
limit: 20
'400':
description: Invalid query parameters.
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
example:
code: "VALIDATION_ERROR"
message: "Invalid query parameter value."
'401':
$ref: '#/components/responses/Unauthorized'
'403':
$ref: '#/components/responses/Forbidden'
'429':
$ref: '#/components/responses/TooManyRequests'
'500':
$ref: '#/components/responses/InternalServerError'
/organizations/{orgId}:
parameters:
- name: orgId
in: path
required: true
description: The unique UUID identifier of the organization.
schema:
type: string
format: uuid
example: "org-1234-5678-abcd-ef01"
get:
operationId: getOrganization
tags:
- Organizations
summary: Get organization by ID
description: |
Retrieves the full record for a single organization.
Requires `admin:orgs` scope.
responses:
'200':
description: Organization record returned successfully.
content:
application/json:
schema:
$ref: '#/components/schemas/Organization'
example:
organizationId: "org-1234-5678-abcd-ef01"
name: "Acme Corp"
slug: "acme-corp"
planTier: "pro"
maxAgents: 500
maxTokensPerMonth: 50000
status: "active"
createdAt: "2026-03-01T08:00:00.000Z"
updatedAt: "2026-03-28T11:30:00.000Z"
'401':
$ref: '#/components/responses/Unauthorized'
'403':
$ref: '#/components/responses/Forbidden'
'404':
$ref: '#/components/responses/NotFound'
'500':
$ref: '#/components/responses/InternalServerError'
patch:
operationId: updateOrganization
tags:
- Organizations
summary: Update organization metadata
description: |
Partially updates an organization's metadata.
Only provided fields are updated; omitted fields are unchanged.
`slug` and `organizationId` are immutable.
Requires `admin:orgs` scope.
requestBody:
required: true
content:
application/json:
schema:
$ref: '#/components/schemas/UpdateOrgRequest'
example:
name: "Acme Corporation"
planTier: "enterprise"
responses:
'200':
description: Organization updated successfully.
content:
application/json:
schema:
$ref: '#/components/schemas/Organization'
example:
organizationId: "org-1234-5678-abcd-ef01"
name: "Acme Corporation"
slug: "acme-corp"
planTier: "enterprise"
maxAgents: 500
maxTokensPerMonth: 50000
status: "active"
createdAt: "2026-03-01T08:00:00.000Z"
updatedAt: "2026-04-07T09:00:00.000Z"
'400':
description: Validation error or attempt to modify an immutable field.
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
example:
code: "VALIDATION_ERROR"
message: "Request validation failed."
'401':
$ref: '#/components/responses/Unauthorized'
'403':
$ref: '#/components/responses/Forbidden'
'404':
$ref: '#/components/responses/NotFound'
'429':
$ref: '#/components/responses/TooManyRequests'
'500':
$ref: '#/components/responses/InternalServerError'
delete:
operationId: deleteOrganization
tags:
- Organizations
summary: Soft-delete an organization
description: |
Permanently soft-deletes an organization by setting its status to `deleted`.
The record is retained for audit purposes.
**Effects:**
- All agents within the organization are suspended.
- No new tokens may be issued for agents in this organization.
- This operation is **irreversible** via the API.
Requires `admin:orgs` scope.
responses:
'204':
description: Organization soft-deleted successfully. No response body.
'401':
$ref: '#/components/responses/Unauthorized'
'403':
$ref: '#/components/responses/Forbidden'
'404':
$ref: '#/components/responses/NotFound'
'409':
description: Organization is already deleted.
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
example:
code: "ORG_ALREADY_DELETED"
message: "This organization has already been deleted."
'429':
$ref: '#/components/responses/TooManyRequests'
'500':
$ref: '#/components/responses/InternalServerError'
/organizations/{orgId}/members:
parameters:
- name: orgId
in: path
required: true
description: The unique UUID identifier of the organization.
schema:
type: string
format: uuid
example: "org-1234-5678-abcd-ef01"
post:
operationId: addOrganizationMember
tags:
- Organization Members
summary: Add an agent as a member of an organization
description: |
Adds a registered agent to an organization with the specified role.
The agent must already be registered in the system.
Requires `admin:orgs` scope.
requestBody:
required: true
content:
application/json:
schema:
$ref: '#/components/schemas/AddMemberRequest'
example:
agentId: "a1b2c3d4-e5f6-7890-abcd-ef1234567890"
role: "member"
responses:
'201':
description: Agent added to organization successfully.
content:
application/json:
schema:
$ref: '#/components/schemas/OrgMember'
example:
memberId: "mem-abcd-1234-5678-ef01"
organizationId: "org-1234-5678-abcd-ef01"
agentId: "a1b2c3d4-e5f6-7890-abcd-ef1234567890"
role: "member"
joinedAt: "2026-04-07T09:00:00.000Z"
'400':
description: Validation error in request body.
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
example:
code: "VALIDATION_ERROR"
message: "Request validation failed."
details:
field: "role"
reason: "role must be one of: member, admin."
'401':
$ref: '#/components/responses/Unauthorized'
'403':
$ref: '#/components/responses/Forbidden'
'404':
description: Organization or agent not found.
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
examples:
orgNotFound:
summary: Organization not found
value:
code: "ORG_NOT_FOUND"
message: "Organization with the specified ID was not found."
agentNotFound:
summary: Agent not found
value:
code: "AGENT_NOT_FOUND"
message: "Agent with the specified ID was not found."
'409':
description: Agent is already a member of this organization.
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
example:
code: "ALREADY_MEMBER"
message: "The agent is already a member of this organization."
'429':
$ref: '#/components/responses/TooManyRequests'
'500':
$ref: '#/components/responses/InternalServerError'

257
docs/openapi/scaffold.yaml Normal file
View File

@@ -0,0 +1,257 @@
openapi: "3.0.3"
info:
title: SentryAgent.ai — SDK Scaffold Generator
version: 1.0.0
description: |
SDK scaffold generator endpoint for the SentryAgent.ai AgentIdP platform.
The scaffold endpoint generates a ready-to-run agent project ZIP archive
pre-configured with the agent's credentials, API URL, and chosen SDK.
The generated scaffold includes:
- Language-specific project structure (TypeScript / Python / Go / Java / Rust)
- Pre-filled `.env.example` with `CLIENT_ID` and `API_URL`
- Agent authentication boilerplate using the SentryAgent.ai SDK
- README with quickstart instructions
- Docker / CI configuration (where applicable)
**Authentication:** Requires a valid Bearer JWT.
**Rate limit:** 10 requests per minute per tenant (separate from the global limit).
The scaffold endpoint responds with `Retry-After` on rate limit.
**Supported languages:** `typescript`, `python`, `go`, `java`, `rust`
servers:
- url: http://localhost:3000/api/v1
description: Local development server
- url: https://api.sentryagent.ai/v1
description: Production server
tags:
- name: SDK Scaffold
description: Generate a ready-to-run agent SDK project scaffold
components:
securitySchemes:
BearerAuth:
type: http
scheme: bearer
bearerFormat: JWT
description: |
JWT access token obtained via `POST /token`.
Include as `Authorization: Bearer <token>`.
schemas:
ScaffoldLanguage:
type: string
enum:
- typescript
- python
- go
- java
- rust
description: Target programming language for the scaffold project.
example: typescript
ErrorResponse:
type: object
description: Standard error response envelope.
required:
- code
- message
properties:
code:
type: string
example: "AGENT_NOT_FOUND"
message:
type: string
example: "Agent with the specified ID was not found."
details:
type: object
additionalProperties: true
responses:
Unauthorized:
description: Missing or invalid Bearer token.
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
example:
code: "UNAUTHORIZED"
message: "A valid Bearer token is required to access this resource."
Forbidden:
description: Valid token but insufficient permissions.
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
example:
code: "FORBIDDEN"
message: "You do not have permission to access this agent's scaffold."
NotFound:
description: Agent not found.
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
example:
code: "AGENT_NOT_FOUND"
message: "Agent with the specified ID was not found."
TooManyRequests:
description: |
Scaffold-specific rate limit exceeded (10 requests per minute per tenant).
Retry after the duration specified in the `Retry-After` header.
headers:
Retry-After:
schema:
type: integer
description: Number of seconds to wait before retrying.
example: 60
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
example:
code: "RATE_LIMIT_EXCEEDED"
message: "Scaffold rate limit exceeded. Please retry after 60 seconds."
InternalServerError:
description: Unexpected server error.
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
example:
code: "INTERNAL_SERVER_ERROR"
message: "An unexpected error occurred. Please try again later."
security:
- BearerAuth: []
paths:
/sdk/scaffold/{agentId}:
get:
operationId: getAgentScaffold
tags:
- SDK Scaffold
summary: Generate and download an agent SDK scaffold ZIP
description: |
Generates a ready-to-run agent project scaffold for the specified agent
and streams it as a ZIP file download.
The scaffold is customized with:
- The agent's `CLIENT_ID` pre-filled in `.env.example`
- The platform API URL (`API_URL`) configured for the environment
- The agent's name, type, and capabilities reflected in project metadata
- Language-specific SDK integration boilerplate
**Rate limit:** 10 requests per minute per tenant.
Exceeding this limit returns `429 Too Many Requests` with a `Retry-After` header.
**Language selection:** Pass the desired `language` query parameter.
Defaults to `typescript` when omitted.
**Authorization:** The authenticated agent (from Bearer token) must belong to
the same organization as the target agent (`agentId`). Cross-tenant scaffold
generation is not permitted.
parameters:
- name: agentId
in: path
required: true
description: UUID of the agent to generate a scaffold for.
schema:
type: string
format: uuid
example: "a1b2c3d4-e5f6-7890-abcd-ef1234567890"
- name: language
in: query
required: false
description: |
Target programming language for the scaffold.
Defaults to `typescript` when omitted.
schema:
$ref: '#/components/schemas/ScaffoldLanguage'
example: typescript
responses:
'200':
description: |
Scaffold ZIP archive generated and streamed successfully.
The response body is a ZIP archive containing the generated project files.
Save it locally and unzip to get started:
```
curl -O -J -H "Authorization: Bearer <token>" \
"https://api.sentryagent.ai/v1/sdk/scaffold/a1b2c3d4-e5f6-7890-abcd-ef1234567890?language=typescript"
unzip screener-001-scaffold.zip
cd screener-001-scaffold && npm install
```
headers:
Content-Disposition:
schema:
type: string
description: |
Filename for the ZIP download.
Format: `attachment; filename="<agent-name>-scaffold.zip"`
example: 'attachment; filename="screener-001-scaffold.zip"'
Content-Type:
schema:
type: string
example: "application/zip"
X-RateLimit-Limit:
schema:
type: integer
description: Scaffold rate limit (requests per minute per tenant).
example: 10
X-RateLimit-Remaining:
schema:
type: integer
description: Remaining scaffold requests in the current window.
example: 9
content:
application/zip:
schema:
type: string
format: binary
description: ZIP archive of the generated scaffold project.
'400':
description: Invalid `language` query parameter.
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
example:
code: "VALIDATION_ERROR"
message: "Invalid language. Supported languages are: typescript, python, go, java, rust."
details:
field: "language"
provided: "ruby"
supported:
- typescript
- python
- go
- java
- rust
'401':
$ref: '#/components/responses/Unauthorized'
'403':
$ref: '#/components/responses/Forbidden'
'404':
$ref: '#/components/responses/NotFound'
'422':
description: Agent is decommissioned — cannot generate scaffold for inactive agents.
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
example:
code: "AGENT_DECOMMISSIONED"
message: "Cannot generate scaffold for a decommissioned agent."
'429':
$ref: '#/components/responses/TooManyRequests'
'500':
$ref: '#/components/responses/InternalServerError'

341
docs/openapi/tiers.yaml Normal file
View File

@@ -0,0 +1,341 @@
openapi: "3.0.3"
info:
title: SentryAgent.ai — Tier Management
version: 1.0.0
description: |
Tier status and upgrade endpoints for the SentryAgent.ai AgentIdP platform.
The tier system defines per-organization limits on agents, tokens, and API calls.
**All endpoints require a valid Bearer JWT.**
**Available tiers:**
| Tier | Max Agents | Max Tokens/Month | Rate Limit |
|------|-----------|-----------------|------------|
| `free` | 100 | 10,000 | 100 req/min |
| `pro` | 1,000 | 100,000 | 1,000 req/min |
| `enterprise` | unlimited | unlimited | custom |
servers:
- url: http://localhost:3000/api/v1
description: Local development server
- url: https://api.sentryagent.ai/v1
description: Production server
tags:
- name: Tiers
description: Tier status and upgrade management
components:
securitySchemes:
BearerAuth:
type: http
scheme: bearer
bearerFormat: JWT
description: |
JWT access token obtained via `POST /token`.
Include as `Authorization: Bearer <token>`.
schemas:
PlanTier:
type: string
enum:
- free
- pro
- enterprise
description: Current subscription plan tier.
example: free
TierLimits:
type: object
description: Hard limits defined by the current tier.
required:
- maxAgents
- maxTokensPerMonth
- rateLimitPerMinute
properties:
maxAgents:
type: integer
description: Maximum number of agents allowed for this organization.
example: 100
maxTokensPerMonth:
type: integer
description: Maximum OAuth 2.0 token requests per calendar month.
example: 10000
rateLimitPerMinute:
type: integer
description: Maximum API requests per minute.
example: 100
TierUsage:
type: object
description: Live usage counters for the current billing period.
required:
- agentsRegistered
- tokensThisMonth
- requestsThisMinute
properties:
agentsRegistered:
type: integer
description: Current number of active (non-decommissioned) agents.
minimum: 0
example: 47
tokensThisMonth:
type: integer
description: Total OAuth 2.0 tokens issued in the current calendar month.
minimum: 0
example: 3214
requestsThisMinute:
type: integer
description: API requests in the current rate-limit window.
minimum: 0
example: 12
TierStatus:
type: object
description: Full tier status response — current tier, plan limits, and live usage.
required:
- organizationId
- tier
- limits
- usage
properties:
organizationId:
type: string
format: uuid
description: Organization the tier status applies to.
example: "org-1234-5678-abcd-ef01"
tier:
$ref: '#/components/schemas/PlanTier'
limits:
$ref: '#/components/schemas/TierLimits'
usage:
$ref: '#/components/schemas/TierUsage'
billingPeriodStart:
type: string
format: date
description: First day of the current billing period (UTC).
example: "2026-04-01"
billingPeriodEnd:
type: string
format: date
description: Last day of the current billing period (UTC).
example: "2026-04-30"
TierUpgradeRequest:
type: object
description: Request body for initiating a tier upgrade.
required:
- targetTier
properties:
targetTier:
type: string
enum:
- pro
- enterprise
description: |
The target plan tier to upgrade to.
Downgrading is not permitted via this endpoint.
example: "pro"
successUrl:
type: string
format: uri
description: |
URL to redirect to after successful payment.
Defaults to the platform dashboard when omitted.
example: "https://my-app.example.com/dashboard?upgrade=success"
cancelUrl:
type: string
format: uri
description: |
URL to redirect to if the user cancels checkout.
Defaults to the platform dashboard when omitted.
example: "https://my-app.example.com/dashboard?upgrade=cancel"
TierUpgradeResponse:
type: object
description: Stripe Checkout URL to initiate the tier upgrade payment flow.
required:
- checkoutUrl
- targetTier
properties:
checkoutUrl:
type: string
format: uri
description: |
Stripe-hosted Checkout page URL.
Redirect the authenticated user to this URL to complete payment.
example: "https://checkout.stripe.com/pay/cs_test_abcdef1234567890"
targetTier:
$ref: '#/components/schemas/PlanTier'
ErrorResponse:
type: object
description: Standard error response envelope.
required:
- code
- message
properties:
code:
type: string
example: "UNAUTHORIZED"
message:
type: string
example: "A valid Bearer token is required to access this resource."
details:
type: object
additionalProperties: true
responses:
Unauthorized:
description: Missing or invalid Bearer token.
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
example:
code: "UNAUTHORIZED"
message: "A valid Bearer token is required to access this resource."
Forbidden:
description: Valid token but insufficient permissions.
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
example:
code: "FORBIDDEN"
message: "You do not have permission to perform this action."
InternalServerError:
description: Unexpected server error.
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
example:
code: "INTERNAL_SERVER_ERROR"
message: "An unexpected error occurred. Please try again later."
security:
- BearerAuth: []
paths:
/tiers/status:
get:
operationId: getTierStatus
tags:
- Tiers
summary: Get current tier status
description: |
Returns the current tier, plan limits, and live usage counters for the
authenticated organization.
The organization ID is derived from the `organization_id` claim in the
Bearer JWT — no explicit organization ID is required in the request.
Use this endpoint to:
- Display the current plan in your dashboard
- Check remaining quota before performing bulk operations
- Determine whether an upgrade is needed
responses:
'200':
description: Tier status returned successfully.
content:
application/json:
schema:
$ref: '#/components/schemas/TierStatus'
example:
organizationId: "org-1234-5678-abcd-ef01"
tier: "free"
limits:
maxAgents: 100
maxTokensPerMonth: 10000
rateLimitPerMinute: 100
usage:
agentsRegistered: 47
tokensThisMonth: 3214
requestsThisMinute: 12
billingPeriodStart: "2026-04-01"
billingPeriodEnd: "2026-04-30"
'401':
$ref: '#/components/responses/Unauthorized'
'403':
$ref: '#/components/responses/Forbidden'
'500':
$ref: '#/components/responses/InternalServerError'
/tiers/upgrade:
post:
operationId: initiateTierUpgrade
tags:
- Tiers
summary: Initiate a tier upgrade via Stripe
description: |
Initiates a Stripe Checkout Session for upgrading the organization's plan tier.
The returned `checkoutUrl` is a Stripe-hosted payment page.
Redirect the authenticated user to this URL to complete the upgrade payment.
After successful payment, Stripe notifies the platform via the
`POST /billing/webhook` endpoint, which activates the new tier automatically.
**Constraints:**
- Only upgrades are supported (free → pro, free → enterprise, pro → enterprise).
- Attempting to "upgrade" to the current or lower tier returns `400`.
requestBody:
required: true
content:
application/json:
schema:
$ref: '#/components/schemas/TierUpgradeRequest'
example:
targetTier: "pro"
successUrl: "https://my-app.example.com/dashboard?upgrade=success"
cancelUrl: "https://my-app.example.com/dashboard?upgrade=cancel"
responses:
'201':
description: Stripe Checkout Session created successfully. Redirect user to checkoutUrl.
content:
application/json:
schema:
$ref: '#/components/schemas/TierUpgradeResponse'
example:
checkoutUrl: "https://checkout.stripe.com/pay/cs_test_abcdef1234567890"
targetTier: "pro"
'400':
description: Invalid upgrade request — already on target tier or attempting a downgrade.
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
examples:
alreadyOnTier:
summary: Already on target tier
value:
code: "ALREADY_ON_TIER"
message: "Your organization is already on the 'pro' tier."
invalidDowngrade:
summary: Downgrade not permitted
value:
code: "DOWNGRADE_NOT_PERMITTED"
message: "Downgrading tiers is not supported via this endpoint."
missingOrgId:
summary: Missing organization_id in token
value:
code: "VALIDATION_ERROR"
message: "organization_id is required in token."
'401':
$ref: '#/components/responses/Unauthorized'
'403':
$ref: '#/components/responses/Forbidden'
'500':
description: Unexpected error or Stripe API failure.
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
example:
code: "STRIPE_ERROR"
message: "Failed to create Stripe Checkout Session. Please try again."

676
docs/openapi/webhooks.yaml Normal file
View File

@@ -0,0 +1,676 @@
openapi: "3.0.3"
info:
title: SentryAgent.ai — Webhooks & Event Subscriptions
version: 1.0.0
description: |
Webhook subscription management and delivery history endpoints for the
SentryAgent.ai AgentIdP platform.
Webhooks deliver real-time event notifications to registered HTTP endpoints
when significant platform events occur (agent lifecycle changes, credential
operations, token events).
**All endpoints require a valid Bearer JWT** with appropriate scope:
- `webhooks:read` — required for GET operations
- `webhooks:write` — required for POST, PATCH, DELETE operations
**Delivery mechanism:**
- Events are delivered via `POST` to the registered `url`
- Each delivery carries a signed JSON envelope (`X-SentryAgent-Signature` header)
- Failed deliveries are retried with exponential backoff (up to 10 attempts)
- After 10 failures the subscription is marked `dead_letter`
**Supported event types:**
`agent.created`, `agent.updated`, `agent.suspended`, `agent.reactivated`,
`agent.decommissioned`, `credential.generated`, `credential.rotated`,
`credential.revoked`, `token.issued`, `token.revoked`
servers:
- url: http://localhost:3000/api/v1
description: Local development server
- url: https://api.sentryagent.ai/v1
description: Production server
tags:
- name: Webhook Subscriptions
description: Create and manage webhook endpoint subscriptions
- name: Webhook Deliveries
description: Query delivery history and attempt records
components:
securitySchemes:
BearerAuth:
type: http
scheme: bearer
bearerFormat: JWT
description: |
JWT access token obtained via `POST /token`.
Include as `Authorization: Bearer <token>`.
schemas:
WebhookEventType:
type: string
enum:
- agent.created
- agent.updated
- agent.suspended
- agent.reactivated
- agent.decommissioned
- credential.generated
- credential.rotated
- credential.revoked
- token.issued
- token.revoked
description: Platform event type that can be subscribed to.
example: agent.created
WebhookDeliveryStatus:
type: string
enum:
- pending
- delivered
- failed
- dead_letter
description: |
Current status of a delivery attempt.
- `pending` — queued for delivery or awaiting retry
- `delivered` — successfully delivered (HTTP 2xx from target)
- `failed` — delivery failed; retry scheduled
- `dead_letter` — all retries exhausted; no further attempts
example: delivered
WebhookSubscription:
type: object
description: A registered webhook subscription (signing secret never included in responses).
required:
- id
- organization_id
- name
- url
- events
- active
- failure_count
- created_at
- updated_at
properties:
id:
type: string
format: uuid
description: Immutable system-assigned UUID for this subscription.
readOnly: true
example: "wh-abcd-1234-5678-ef01"
organization_id:
type: string
format: uuid
description: Organization that owns this subscription.
readOnly: true
example: "org-1234-5678-abcd-ef01"
name:
type: string
description: Human-readable label for this subscription.
example: "Agent lifecycle events"
url:
type: string
format: uri
description: HTTPS endpoint that receives webhook payloads.
example: "https://my-app.example.com/webhooks/sentryagent"
events:
type: array
items:
$ref: '#/components/schemas/WebhookEventType'
description: List of event types this subscription receives.
minItems: 1
example:
- agent.created
- agent.decommissioned
active:
type: boolean
description: Whether the subscription is currently active. Set to false to pause delivery.
example: true
failure_count:
type: integer
description: Number of consecutive delivery failures since last success.
minimum: 0
readOnly: true
example: 0
created_at:
type: string
format: date-time
readOnly: true
example: "2026-03-01T08:00:00.000Z"
updated_at:
type: string
format: date-time
readOnly: true
example: "2026-03-28T11:30:00.000Z"
CreateWebhookRequest:
type: object
description: Request body for creating a new webhook subscription.
required:
- name
- url
- events
properties:
name:
type: string
description: Human-readable label for this subscription.
minLength: 1
maxLength: 256
example: "Agent lifecycle events"
url:
type: string
format: uri
description: HTTPS endpoint URL. Must be HTTPS in production.
example: "https://my-app.example.com/webhooks/sentryagent"
events:
type: array
items:
$ref: '#/components/schemas/WebhookEventType'
minItems: 1
description: Event types to subscribe to.
example:
- agent.created
- agent.decommissioned
UpdateWebhookRequest:
type: object
description: |
Request body for partially updating a webhook subscription.
All fields are optional; only provided fields are updated.
minProperties: 1
properties:
name:
type: string
minLength: 1
maxLength: 256
example: "Agent events (updated)"
url:
type: string
format: uri
example: "https://my-app.example.com/webhooks/v2"
events:
type: array
items:
$ref: '#/components/schemas/WebhookEventType'
minItems: 1
example:
- agent.created
- agent.updated
- token.issued
active:
type: boolean
description: Set to false to pause delivery without deleting the subscription.
example: true
WebhookDelivery:
type: object
description: A single webhook delivery attempt record.
required:
- id
- subscription_id
- event_type
- payload
- status
- attempt_count
- created_at
- updated_at
properties:
id:
type: string
format: uuid
readOnly: true
example: "del-abcd-1234-5678-ef01"
subscription_id:
type: string
format: uuid
example: "wh-abcd-1234-5678-ef01"
event_type:
$ref: '#/components/schemas/WebhookEventType'
payload:
type: object
description: The JSON payload that was sent (or attempted) to the target URL.
additionalProperties: true
example:
id: "evt-1234-5678"
event: "agent.created"
timestamp: "2026-04-07T09:00:00.000Z"
organization_id: "org-1234-5678-abcd-ef01"
data:
agentId: "a1b2c3d4-e5f6-7890-abcd-ef1234567890"
status:
$ref: '#/components/schemas/WebhookDeliveryStatus'
http_status_code:
type: integer
nullable: true
description: HTTP status code returned by the target endpoint (null if connection failed).
example: 200
attempt_count:
type: integer
description: Number of delivery attempts made so far.
minimum: 1
example: 1
next_retry_at:
type: string
format: date-time
nullable: true
description: Scheduled time for the next retry attempt. Null if delivered or dead-lettered.
example: null
delivered_at:
type: string
format: date-time
nullable: true
description: Timestamp when the delivery was successfully confirmed.
example: "2026-04-07T09:00:05.000Z"
created_at:
type: string
format: date-time
readOnly: true
example: "2026-04-07T09:00:00.000Z"
updated_at:
type: string
format: date-time
readOnly: true
example: "2026-04-07T09:00:05.000Z"
PaginatedDeliveriesResponse:
type: object
description: Paginated delivery history response.
required:
- deliveries
- total
- limit
- offset
properties:
deliveries:
type: array
items:
$ref: '#/components/schemas/WebhookDelivery'
total:
type: integer
example: 87
limit:
type: integer
example: 20
offset:
type: integer
example: 0
ErrorResponse:
type: object
description: Standard error response envelope.
required:
- code
- message
properties:
code:
type: string
example: "WEBHOOK_NOT_FOUND"
message:
type: string
example: "Webhook subscription with the specified ID was not found."
details:
type: object
additionalProperties: true
responses:
Unauthorized:
description: Missing or invalid Bearer token.
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
example:
code: "UNAUTHORIZED"
message: "A valid Bearer token is required to access this resource."
Forbidden:
description: Valid token but insufficient scope.
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
example:
code: "FORBIDDEN"
message: "You do not have permission to perform this action."
NotFound:
description: Webhook subscription not found.
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
example:
code: "WEBHOOK_NOT_FOUND"
message: "Webhook subscription with the specified ID was not found."
InternalServerError:
description: Unexpected server error.
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
example:
code: "INTERNAL_SERVER_ERROR"
message: "An unexpected error occurred. Please try again later."
security:
- BearerAuth: []
paths:
/webhooks:
post:
operationId: createWebhookSubscription
tags:
- Webhook Subscriptions
summary: Create a webhook subscription
description: |
Creates a new webhook subscription for the authenticated organization.
A signing secret is generated automatically and returned once in the response
under a `signingSecret` field. **Store this secret securely — it cannot be retrieved again.**
Requires `webhooks:write` scope.
requestBody:
required: true
content:
application/json:
schema:
$ref: '#/components/schemas/CreateWebhookRequest'
example:
name: "Agent lifecycle events"
url: "https://my-app.example.com/webhooks/sentryagent"
events:
- agent.created
- agent.decommissioned
responses:
'201':
description: Webhook subscription created successfully.
content:
application/json:
schema:
allOf:
- $ref: '#/components/schemas/WebhookSubscription'
- type: object
properties:
signingSecret:
type: string
description: |
HMAC signing secret for verifying webhook payloads.
Returned only once at creation time.
example: "whsec_abcdef1234567890abcdef1234567890"
example:
id: "wh-abcd-1234-5678-ef01"
organization_id: "org-1234-5678-abcd-ef01"
name: "Agent lifecycle events"
url: "https://my-app.example.com/webhooks/sentryagent"
events:
- agent.created
- agent.decommissioned
active: true
failure_count: 0
created_at: "2026-04-07T09:00:00.000Z"
updated_at: "2026-04-07T09:00:00.000Z"
signingSecret: "whsec_abcdef1234567890abcdef1234567890"
'400':
description: Validation error in request body.
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
example:
code: "VALIDATION_ERROR"
message: "Request validation failed."
details:
field: "url"
reason: "Must be a valid HTTPS URL."
'401':
$ref: '#/components/responses/Unauthorized'
'403':
$ref: '#/components/responses/Forbidden'
'500':
$ref: '#/components/responses/InternalServerError'
get:
operationId: listWebhookSubscriptions
tags:
- Webhook Subscriptions
summary: List webhook subscriptions
description: |
Returns all webhook subscriptions for the authenticated organization.
Requires `webhooks:read` scope.
responses:
'200':
description: List of webhook subscriptions returned successfully.
content:
application/json:
schema:
type: array
items:
$ref: '#/components/schemas/WebhookSubscription'
example:
- id: "wh-abcd-1234-5678-ef01"
organization_id: "org-1234-5678-abcd-ef01"
name: "Agent lifecycle events"
url: "https://my-app.example.com/webhooks/sentryagent"
events:
- agent.created
- agent.decommissioned
active: true
failure_count: 0
created_at: "2026-03-01T08:00:00.000Z"
updated_at: "2026-03-01T08:00:00.000Z"
'401':
$ref: '#/components/responses/Unauthorized'
'403':
$ref: '#/components/responses/Forbidden'
'500':
$ref: '#/components/responses/InternalServerError'
/webhooks/{id}:
parameters:
- name: id
in: path
required: true
description: UUID of the webhook subscription.
schema:
type: string
format: uuid
example: "wh-abcd-1234-5678-ef01"
get:
operationId: getWebhookSubscription
tags:
- Webhook Subscriptions
summary: Get a webhook subscription by ID
description: |
Returns a single webhook subscription record.
Requires `webhooks:read` scope.
responses:
'200':
description: Webhook subscription returned successfully.
content:
application/json:
schema:
$ref: '#/components/schemas/WebhookSubscription'
example:
id: "wh-abcd-1234-5678-ef01"
organization_id: "org-1234-5678-abcd-ef01"
name: "Agent lifecycle events"
url: "https://my-app.example.com/webhooks/sentryagent"
events:
- agent.created
- agent.decommissioned
active: true
failure_count: 0
created_at: "2026-03-01T08:00:00.000Z"
updated_at: "2026-03-28T11:30:00.000Z"
'401':
$ref: '#/components/responses/Unauthorized'
'403':
$ref: '#/components/responses/Forbidden'
'404':
$ref: '#/components/responses/NotFound'
'500':
$ref: '#/components/responses/InternalServerError'
patch:
operationId: updateWebhookSubscription
tags:
- Webhook Subscriptions
summary: Update a webhook subscription
description: |
Partially updates a webhook subscription. Only provided fields are updated.
Set `active: false` to pause delivery without deleting the subscription.
Requires `webhooks:write` scope.
requestBody:
required: true
content:
application/json:
schema:
$ref: '#/components/schemas/UpdateWebhookRequest'
example:
active: false
responses:
'200':
description: Webhook subscription updated successfully.
content:
application/json:
schema:
$ref: '#/components/schemas/WebhookSubscription'
example:
id: "wh-abcd-1234-5678-ef01"
organization_id: "org-1234-5678-abcd-ef01"
name: "Agent lifecycle events"
url: "https://my-app.example.com/webhooks/sentryagent"
events:
- agent.created
- agent.decommissioned
active: false
failure_count: 0
created_at: "2026-03-01T08:00:00.000Z"
updated_at: "2026-04-07T09:00:00.000Z"
'400':
description: Validation error in request body.
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
example:
code: "VALIDATION_ERROR"
message: "Request validation failed."
'401':
$ref: '#/components/responses/Unauthorized'
'403':
$ref: '#/components/responses/Forbidden'
'404':
$ref: '#/components/responses/NotFound'
'500':
$ref: '#/components/responses/InternalServerError'
delete:
operationId: deleteWebhookSubscription
tags:
- Webhook Subscriptions
summary: Delete a webhook subscription
description: |
Permanently deletes a webhook subscription and stops all future deliveries.
Any pending deliveries in the queue are cancelled.
Requires `webhooks:write` scope.
responses:
'204':
description: Webhook subscription deleted successfully. No response body.
'401':
$ref: '#/components/responses/Unauthorized'
'403':
$ref: '#/components/responses/Forbidden'
'404':
$ref: '#/components/responses/NotFound'
'500':
$ref: '#/components/responses/InternalServerError'
/webhooks/{id}/deliveries:
parameters:
- name: id
in: path
required: true
description: UUID of the webhook subscription.
schema:
type: string
format: uuid
example: "wh-abcd-1234-5678-ef01"
get:
operationId: listWebhookDeliveries
tags:
- Webhook Deliveries
summary: List delivery history for a subscription
description: |
Returns the delivery history for a webhook subscription,
ordered by `created_at` descending (most recent first).
Use this endpoint to diagnose delivery failures and inspect
payload content for historical events.
Requires `webhooks:read` scope.
parameters:
- name: limit
in: query
required: false
schema:
type: integer
minimum: 1
maximum: 100
default: 20
example: 20
- name: offset
in: query
required: false
schema:
type: integer
minimum: 0
default: 0
example: 0
- name: status
in: query
required: false
schema:
$ref: '#/components/schemas/WebhookDeliveryStatus'
description: Filter deliveries by status.
responses:
'200':
description: Delivery history returned successfully.
content:
application/json:
schema:
$ref: '#/components/schemas/PaginatedDeliveriesResponse'
example:
deliveries:
- id: "del-abcd-1234-5678-ef01"
subscription_id: "wh-abcd-1234-5678-ef01"
event_type: "agent.created"
payload:
id: "evt-1234-5678"
event: "agent.created"
timestamp: "2026-04-07T09:00:00.000Z"
organization_id: "org-1234-5678-abcd-ef01"
data:
agentId: "a1b2c3d4-e5f6-7890-abcd-ef1234567890"
status: "delivered"
http_status_code: 200
attempt_count: 1
next_retry_at: null
delivered_at: "2026-04-07T09:00:05.000Z"
created_at: "2026-04-07T09:00:00.000Z"
updated_at: "2026-04-07T09:00:05.000Z"
total: 87
limit: 20
offset: 0
'401':
$ref: '#/components/responses/Unauthorized'
'403':
$ref: '#/components/responses/Forbidden'
'404':
$ref: '#/components/responses/NotFound'
'500':
$ref: '#/components/responses/InternalServerError'

View File

@@ -0,0 +1,26 @@
## Engineering Docs — Task Tracker
All tasks complete. Archive committed 2026-04-02.
### WS1 — Core Knowledge Base (10 documents)
- [x] 1.1 Create `docs/engineering/README.md` — directory index and reading path
- [x] 1.2 Create `docs/engineering/01-overview.md` — company mission, product vision, system purpose, team structure
- [x] 1.3 Create `docs/engineering/02-architecture.md` — component diagram, data flows, deployment topology, technology rationale
- [x] 1.4 Create `docs/engineering/03-tech-stack.md` — full stack with ADRs (Express, PostgreSQL, Redis, TypeScript, OPA, Vault)
- [x] 1.5 Create `docs/engineering/04-codebase-structure.md` — annotated directory map covering all top-level directories and key files
- [x] 1.6 Create `docs/engineering/05-services.md` — deep dives for AgentService, OAuth2Service, CredentialService, AuditService, VaultClient, OPA engine, Web Dashboard, Prometheus/Grafana
- [x] 1.7 Create `docs/engineering/06-walkthroughs.md` — annotated traces for token issuance, agent registration, and credential rotation (with file:line references)
- [x] 1.8 Create `docs/engineering/07-dev-setup.md` — < 30 min onboarding from clone to running local stack
- [x] 1.9 Create `docs/engineering/08-workflow.md` — OpenSpec → Architect → Developer → QA → merge cycle and PR standards
- [x] 1.10 Create `docs/engineering/09-testing.md` — framework, test types, coverage gates, how to run and write tests
### WS2 — Operations and Integration
- [x] 2.1 Create `docs/engineering/10-deployment.md` — Docker build/run, Terraform multi-region, env config, monitoring runbooks
- [x] 2.2 Create `docs/engineering/11-sdk-guide.md` — Node.js, Python, Go, Java SDK integration with installation, auth, operations, error handling
### WS3 — Quality and Review
- [x] 3.1 CTO review — all documents reviewed against PRD standards (calibration, accuracy, completeness)
- [x] 3.2 QA sign-off — cross-link validation, code example verification

View File

@@ -0,0 +1,130 @@
# Design — vv-architect-setup
## Context
SentryAgent.ai uses a multi-agent Claude Code architecture:
- **CEO-Session** — human-facing, governance and priorities
- **VirtualCTO** — technical authority, directs engineering team
- **Engineering Team** (Architect, Developer, QA) — spawned as subagents by CTO
All prior phases passed through the CTO's review and QA sign-off. No independent
verification existed outside that chain. The V&V Architect adds a separate audit loop
that operates with full read access to the codebase but no write authority over it.
## Goals / Non-Goals
**Goals:**
- Provide CEO-level assurance that the codebase matches the PRD and OpenSpec
- Detect spec-implementation gaps, DRY violations, TypeScript violations, test gaps, and security issues
- Create a formal, auditable issue trail (VV_ISSUE_NNN.md files)
- Enable the CEO to see a release gate status at any time (LEDGER.md)
**Non-Goals:**
- The validator does NOT fix code — it only reports findings
- The validator does NOT block the CTO from working in parallel
- The validator does NOT attend to new feature planning or business decisions
- The validator does NOT replace the QA Engineer — QA tests functionality; V&V audits completeness and standards compliance
## Architecture
```
CEO (Human)
├── CEO-Session (this Claude Code instance)
│ └── VirtualCTO (separate terminal — .cto-workspace/)
│ ├── Virtual Architect (subagent)
│ ├── Virtual Developer (subagent)
│ └── Virtual QA Engineer (subagent)
└── LeadValidator (separate terminal — .validator-workspace/) ← NEW
Reports findings to CEO via #vv-findings
BLOCKER alerts also go to #vpe-cto-approvals
```
The LeadValidator is the only agent in the system that:
1. Reports directly to the CEO (not via CTO)
2. Can issue a BLOCKER that prevents release
3. Operates from an isolated workspace with no engineering team context
## Decisions
### D1: System Prompt Injection vs. CLAUDE.md Workspace
**Decision**: Use `--system-prompt-file VALIDATOR.md` to inject the validator's identity.
**Rationale**: The CTO uses `.cto-workspace/CLAUDE.md` for its identity because Claude Code
reads CLAUDE.md as project context. For the validator, using `--system-prompt-file` is
more explicit and harder to accidentally override — the validator's identity is injected
at the OS level, not discovered by file-scan. This also prevents any future accidental
CLAUDE.md conflicts if the workspace is updated.
**Alternative considered**: Give validator its own CLAUDE.md identity like the CTO — rejected
because `--system-prompt-file` makes the validator identity non-negotiable and audit-grade.
### D2: Shared Ledger — Filesystem vs. Central Hub Only
**Decision**: Filesystem ledger (`openspec/vv_audit/`) as primary, central hub as notification layer.
**Rationale**: Issue files (`VV_ISSUE_NNN.md`) need to be persistent, versioned in git, and
readable by humans without opening a terminal. The central hub is ephemeral session state.
Filesystem issues survive session restarts; hub messages do not.
**Alternative considered**: Hub-only communication — rejected because hub messages are not
committed to git and cannot be audited historically.
### D3: Issue Severity Model
**Decision**: Three-tier severity — BLOCKER / MAJOR / MINOR.
| Severity | Release impact | Who can close |
|----------|---------------|---------------|
| BLOCKER | Prevents release | CEO acknowledges; CTO resolves |
| MAJOR | Must resolve before next phase | CTO resolves; Validator confirms |
| MINOR | Best-effort improvement | CTO resolves; no re-audit needed |
**Rationale**: Binary pass/fail is too blunt for a mature codebase. Three tiers allow the
team to ship with known MINOR issues while ensuring BLOCKERs are never silently bypassed.
### D4: Validator Workspace Isolation
**Decision**: Validator writes its own minimal CLAUDE.md to `.validator-workspace/` rather
than copying the CEO session's CLAUDE.md.
**Rationale**: The CEO session CLAUDE.md defines multi-agent setup and CEO startup protocol —
none of which applies to an auditor. Copying it would contaminate the validator context.
The validator's workspace CLAUDE.md only provides absolute path references to project resources.
### D5: Audit Phases
**Decision**: 8 audit phases covering all PRD compliance dimensions.
| Phase | Scope |
|-------|-------|
| A | OpenSpec task completeness |
| B | API surface vs OpenAPI specs |
| C | TypeScript strict mode compliance |
| D | DRY principle enforcement |
| E | SOLID principle spot-checks |
| F | Test coverage (>80% threshold) |
| G | AGNTCY compliance |
| H | Security (OWASP Top 10) |
All 8 phases must be run per audit session. A validator may document why a phase was
skipped but cannot silently omit it.
## File Map
| File | Purpose |
|------|---------|
| `VALIDATOR.md` | System prompt for LeadValidator agent |
| `scripts/start-validator.sh` | Launches validator, sets up workspace, sanity-checks VALIDATOR.md |
| `.validator-workspace/` | Isolated workspace (gitignored) |
| `.validator-workspace/CLAUDE.md` | Validator workspace context (absolute paths only) |
| `openspec/vv_audit/LEDGER.md` | Audit ledger index — updated after each session |
| `openspec/vv_audit/VV_ISSUE_NNN.md` | Individual issue files written by validator |
| `.cto-workspace/CLAUDE.md` | Updated Peer-Review Protocol section |
## Hub Channels
| Channel | Purpose |
|---------|---------|
| `#vv-findings` | Validator → CEO + CTO: audit summaries, issue notifications |
| `#vpe-cto-approvals` | Validator → CEO only: BLOCKER escalations |

View File

@@ -0,0 +1,54 @@
# OpenSpec Proposal — vv-architect-setup
**Status:** Approved & Archived
**Proposed:** 2026-04-07
**Approved by:** CEO
---
## Problem Statement
The SentryAgent.ai multi-agent engineering system has no independent quality gate.
The Virtual CTO directs the engineering team (Architect, Developer, QA), which means
the same chain of command that builds the software also signs off on its correctness.
This creates a conflict of interest — the team grades its own homework.
Additionally, `VALIDATOR.md` existed in the repository but contained the wrong content:
a copy of `scripts/start-validator.sh` (the shell script). If the validator had been
launched, Claude would have received a bash script as its system prompt, producing
a broken agent with no defined purpose or audit methodology.
## Proposed Solution
Introduce a **V&V Architect (Lead Validator)** — a 4th independent Claude Code instance
that runs outside the CTO's chain of command and reports directly to the CEO.
**WS1 — Fix VALIDATOR.md**
Rewrite `VALIDATOR.md` as the proper system prompt for the Lead Validator agent.
Must define: identity, independence principle, startup protocol, 8-phase audit
methodology, issue format, severity definitions, and communication protocol.
**WS2 — Fix start-validator.sh**
Update `scripts/start-validator.sh` to:
- Build a validator-specific workspace (not inherit CEO session context)
- Include a sanity check that aborts if VALIDATOR.md still contains shell script content
- Auto-initialise the shared V&V audit ledger on first run
**WS3 — Shared V&V Issue Ledger**
Create `openspec/vv_audit/` as the shared filesystem ledger accessible by both the
Validator and the CTO via absolute paths. Create `LEDGER.md` as the audit index.
**WS4 — Central Hub Channel**
Create `#vv-findings` channel on the central hub for real-time validator notifications
to CEO and CTO. BLOCKER findings also escalate to `#vpe-cto-approvals`.
**WS5 — CTO Peer-Review Protocol Update**
Update `.cto-workspace/CLAUDE.md` to reference the correct ledger path, hub channel,
and dispute/resolution process so the CTO knows how to respond to validator findings.
## CEO Approval
Approved 2026-04-07 per CEO directive:
"if possible — yes you have my approvals — as our technical and business consultant —
please make the changes you need to make sure we have fully independent system to check
we have fully implemented our PRD per OpenSpec protocols"

View File

@@ -0,0 +1,61 @@
# Tasks — vv-architect-setup
## WS1 — Fix VALIDATOR.md (System Prompt)
- [x] 1.1 Identify the bug: `VALIDATOR.md` contained an exact copy of `scripts/start-validator.sh` (byte-for-byte identical — 1900 bytes each)
- [x] 1.2 Rewrite `VALIDATOR.md` as the proper system prompt for the LeadValidator agent
- [x] 1.3 Define validator identity and independence principle (not under CTO authority; reports to CEO)
- [x] 1.4 Define 6-step startup protocol (read PRD → register hub → check ledger → check channel → report readiness → begin audit)
- [x] 1.5 Define Phase A — OpenSpec task completeness check (verify all archived tasks.md `[x]` items have corresponding code)
- [x] 1.6 Define Phase B — API surface audit (every route must have an OpenAPI spec; spec must match implementation)
- [x] 1.7 Define Phase C — TypeScript standards audit (no `any`, strict mode, JSDoc, error hierarchy)
- [x] 1.8 Define Phase D — DRY principle audit (no duplicated logic, utility files as single sources of truth)
- [x] 1.9 Define Phase E — SOLID principles audit (SRP spot-checks on key services, constructor injection)
- [x] 1.10 Define Phase F — Test coverage audit (>80% threshold, integration tests for all endpoints)
- [x] 1.11 Define Phase G — AGNTCY compliance audit (agent identity model, lifecycle, DID, conformance tests)
- [x] 1.12 Define Phase H — Security audit (OWASP Top 10 checks)
- [x] 1.13 Define issue format: `VV_ISSUE_NNN.md` with Status, Severity, Category, Finding, Evidence, Required Action, CTO Response, Resolution
- [x] 1.14 Define severity model: BLOCKER / MAJOR / MINOR with clear ownership and release impact
- [x] 1.15 Define communication protocol: `#vv-findings` for routine findings, `#vpe-cto-approvals` for BLOCKER escalations
- [x] 1.16 Define dispute resolution protocol: CTO writes justification → Validator evaluates → CEO as final arbiter
- [x] 1.17 Define AUDIT LEDGER INDEX maintenance requirements
## WS2 — Fix scripts/start-validator.sh
- [x] 2.1 Remove the line that copies CEO's `CLAUDE.md` into the validator workspace (was contaminating validator with CEO-session context)
- [x] 2.2 Add sanity check: abort with clear error if `VALIDATOR.md` first line is `#!/bin/bash` (prevents relaunching with wrong content)
- [x] 2.3 Add `SHARED_LEDGER` variable pointing to `openspec/vv_audit/`
- [x] 2.4 Add `mkdir -p "$SHARED_LEDGER"` to auto-create ledger directory on first run
- [x] 2.5 Add auto-initialisation of `LEDGER.md` if it does not exist (idempotent — skipped if already present)
- [x] 2.6 Write validator-specific `CLAUDE.md` to workspace (absolute paths only, no CEO-session context, no role-switching instructions)
- [x] 2.7 Update echoed launch checklist to reflect validator's actual responsibilities
- [x] 2.8 Ensure `exec claude --system-prompt-file "$VALIDATOR_SYSTEM_PROMPT"` uses the correct variable name
## WS3 — Shared V&V Issue Ledger
- [x] 3.1 Create `openspec/vv_audit/` directory in project root (accessible by both validator and CTO via absolute paths)
- [x] 3.2 Create `openspec/vv_audit/LEDGER.md` — structured audit index with Summary table, Issue Index, Audit History, and usage instructions
- [x] 3.3 Document who updates what: Validator updates Summary and Issue Index; CTO updates issue files; CEO reads for release gate status
## WS4 — Central Hub Channel
- [x] 4.1 Create `#vv-findings` channel on central hub with description: "V&V Architect findings — audit issues, BLOCKER notifications, resolution tracking"
- [x] 4.2 Verify `#vpe-cto-approvals` (CEO channel) already exists — BLOCKER escalations go here
## WS5 — CTO Peer-Review Protocol Update
- [x] 5.1 Update `.cto-workspace/CLAUDE.md` Peer-Review Protocol section
- [x] 5.2 Replace relative path `./specs/issues/` with absolute path `openspec/vv_audit/`
- [x] 5.3 Add `#vv-findings` channel reference
- [x] 5.4 Clarify CTO cannot dismiss validator findings — only resolve or dispute
- [x] 5.5 Clarify BLOCKER resolution protocol: CEO automatically notified; CTO must not resolve without CEO awareness
- [x] 5.6 Add instruction on how to start the validator (`./scripts/start-validator.sh`)
## WS6 — OpenSpec Documentation (this change)
- [x] 6.1 Create `openspec/changes/archive/2026-04-07-vv-architect-setup/` directory
- [x] 6.2 Write `proposal.md` — problem statement, proposed solution, CEO approval
- [x] 6.3 Write `design.md` — architecture, decisions (D1D5), file map, hub channels
- [x] 6.4 Write `tasks.md` (this file) — complete task breakdown with all items checked
- [x] 6.5 Create `specs/` directory (no API specs needed — this is agent governance tooling, not an API change)
- [x] 6.6 Commit all changes to git: VALIDATOR.md, scripts/start-validator.sh, openspec/vv_audit/, openspec/changes/archive/2026-04-07-vv-architect-setup/

View File

@@ -0,0 +1,5 @@
id: tenant-isolation-enforcement
title: Enforce tenant isolation on all agent endpoints
status: active
type: security
created: 2026-04-08

View File

@@ -0,0 +1,64 @@
# Technical Design: Tenant Isolation Enforcement
## Overview
Tenant isolation is enforced by threading the caller's `organization_id` (extracted from the verified JWT) through the controller → service → repository call chain. No caller-supplied body value or query parameter may override this. The JWT is the sole authoritative source of organization context.
## JWT Claim Source
`ITokenPayload` already carries `organization_id: string`. The Express middleware that verifies the JWT attaches the decoded payload to `req.user`. Controllers read `req.user.organization_id` and pass it down the stack.
## Enforcement Points
### Rule 1 — List Scoping (`GET /agents`)
**Where:** `AgentController.listAgents()``AgentService.listAgents()``AgentRepository.findAll()`
**Mechanism:**
1. `AgentController.listAgents()` sets `filters.organizationId = req.user.organization_id` unconditionally, overwriting any value that might have arrived in the query string.
2. `AgentRepository.findAll()` always includes `WHERE organization_id = $n` when `organizationId` is present in `IAgentListFilters`. Because the controller always sets it, this clause is always active.
3. The `owner` query parameter is applied as an additional `AND owner = $n` clause — it sub-filters within the org, never across orgs.
**Result:** A caller from Org A cannot receive any agent record belonging to Org B, regardless of query parameters supplied.
### Rule 2 — Ownership Guard (`GET`, `PATCH`, `DELETE` on `/agents/{agentId}`)
**Where:** `AgentService.getAgentById()`, `AgentService.updateAgent()`, `AgentService.decommissionAgent()`
**Mechanism:**
1. The repository fetches the agent record by `agentId` without org filtering (the ID lookup is always exact-match by primary key).
2. Immediately after retrieval, the service compares `agent.organizationId` against the `callerOrganizationId` parameter passed in from the controller.
3. If they do not match, the service throws `AuthorizationError` with code `AUTHORIZATION_ERROR` and message "You do not have permission to access this resource."
4. The controller's error handler maps `AuthorizationError` → HTTP 403.
**Invariant:** An agent record is returned (or mutated/deleted) only if the caller's JWT org matches the stored org on that record. A non-matching ID returns 403, not 404 — this prevents org enumeration via timing differences.
### Rule 3 — Register Scoping (`POST /agents`)
**Where:** `AgentController.registerAgent()`
**Mechanism:**
1. The controller ignores any `organizationId` field in `req.body`.
2. Before calling the service, it sets `organizationId = req.user.organization_id`.
3. The service and repository receive only the JWT-derived value.
**Result:** It is impossible for a caller to register an agent under a foreign org, regardless of request body content.
## Error Type
A new (or existing) `AuthorizationError` class in the `SentryAgentError` hierarchy is used. It carries:
- `code: "AUTHORIZATION_ERROR"`
- HTTP status: `403`
- `message: "You do not have permission to access this resource."`
This is distinct from the existing `ForbiddenError` (which covers role/permission checks) to allow fine-grained programmatic handling by API consumers.
## Database Considerations
No schema changes are required. The `agents` table already stores `organization_id`. The enforcement is purely at the application layer. Existing indexes on `organization_id` ensure the scoped list query remains performant.
## Security Properties
- **No information leakage:** Cross-tenant requests return 403, not 404. This means a caller from Org A cannot determine whether an agent with a given ID exists in Org B.
- **No parameter injection:** `organizationId` is never read from the request body or query string for scoping purposes — only from the verified JWT.
- **Defense in depth:** Enforcement is at the service layer, not just the controller, ensuring the invariant holds even if the service is called from other internal paths.

View File

@@ -0,0 +1,54 @@
# Proposal: Enforce Tenant Isolation on All Agent Endpoints
## Title
Enforce tenant (organization) isolation on all agent CRUD endpoints — P0 Security Fix
## Problem Statement
Field trial Test C.7 — Org Isolation Failure — has identified a critical security defect.
All five agent endpoints (`POST /agents`, `GET /agents`, `GET /agents/{agentId}`,
`PATCH /agents/{agentId}`, `DELETE /agents/{agentId}`) perform **no tenant isolation**.
Any authenticated agent from Organization A can:
- Read the full agent list of Organization B (`GET /agents`)
- Read any individual agent record across any organization (`GET /agents/{agentId}`)
- Modify any agent's metadata across any organization (`PATCH /agents/{agentId}`)
- Decommission any agent across any organization (`DELETE /agents/{agentId}`)
- Register agents under any organization by supplying an arbitrary `organizationId` in the request body (`POST /agents`)
The JWT issued by the system already contains an `organization_id` claim (present in `ITokenPayload`). The enforcement layer between this claim and the data access layer is entirely absent.
This is a **P0 security incident** — it breaks multi-tenancy at its most fundamental level and must be resolved before any field trial continues.
## Proposed Solution
Enforce organization scoping at the service layer, driven by the `organization_id` claim extracted from the verified JWT on every request. No request body value or query parameter may override the caller's organization context.
Three enforcement rules are applied:
**Rule 1 — List scoping (`GET /agents`):** Results are always filtered to the caller's `organization_id`. The `owner` query parameter may further sub-filter within the caller's org, but can never widen the scope beyond it.
**Rule 2 — Ownership guard (`GET /agents/{agentId}`, `PATCH /agents/{agentId}`, `DELETE /agents/{agentId}`):** After retrieving the target agent record, the service compares the agent's stored `organization_id` against the caller's `organization_id`. If they do not match, the operation is rejected with `403 Forbidden` and error code `AUTHORIZATION_ERROR`.
**Rule 3 — Register scoping (`POST /agents`):** The `organizationId` field in the request body is ignored. The agent is always registered under the caller's `organization_id` from the JWT, regardless of what the body contains.
## Scope of Changes
- `src/types/index.ts` — add `organizationId` field to `IAgentListFilters`
- `src/repositories/AgentRepository.ts` — filter `findAll()` by `organizationId`
- `src/services/AgentService.ts` — pass `organizationId` into `getAgentById()`, `updateAgent()`, `decommissionAgent()`; throw `AuthorizationError` on mismatch
- `src/controllers/AgentController.ts` — extract `req.user.organization_id` and apply to all five endpoint handlers
- `docs/openapi/agent-registry.yaml` — document enforcement rules and 403 responses on all five endpoints
- `src/tests/` — add Test C.7 regression suite and ownership guard tests
## Acceptance Criteria
- [ ] `GET /agents` never returns agents from a different organization than the caller's
- [ ] `GET /agents/{agentId}` returns `403 AUTHORIZATION_ERROR` if the target agent belongs to a different organization
- [ ] `PATCH /agents/{agentId}` returns `403 AUTHORIZATION_ERROR` if the target agent belongs to a different organization
- [ ] `DELETE /agents/{agentId}` returns `403 AUTHORIZATION_ERROR` if the target agent belongs to a different organization
- [ ] `POST /agents` ignores any `organizationId` in the request body; agent is always registered under the caller's org
- [ ] OpenAPI spec documents these rules and all 403 responses on all five endpoints
- [ ] Test C.7 regression suite passes
- [ ] All ownership guard paths have test coverage
- [ ] Overall test coverage remains above 80%

View File

@@ -0,0 +1,10 @@
# Implementation Tasks: Tenant Isolation Enforcement
- [x] Add `organizationId` field to `IAgentListFilters` in `src/types/index.ts`
- [x] Update `AgentRepository.findAll()` to filter by `organizationId`
- [x] Add `organizationId` parameter to `AgentService.getAgentById()`, `updateAgent()`, `decommissionAgent()`; throw `AuthorizationError` on mismatch
- [x] Update `AgentController.registerAgent()` to force `organizationId` from `req.user.organization_id`
- [x] Update `AgentController.listAgents()` to force `filters.organizationId` from `req.user.organization_id`
- [x] Update `AgentController.getAgentById()`, `updateAgent()`, `decommissionAgent()` to pass `req.user.organization_id` to service
- [x] Update `docs/openapi/agent-registry.yaml` with 403 responses and security enforcement descriptions
- [x] Ownership guard unit tests added to `tests/unit/controllers/AgentController.test.ts` (23 tests, all passing). Note: Test C.7 end-to-end regression is a field trial integration test run by DevOps against live containers — it is not a unit test.

View File

@@ -0,0 +1,36 @@
# Design — developer-docs-phase6-update
**Status:** Complete
**Archived:** 2026-04-04
## Context
Developer documentation in `docs/developers/` was last updated during Phase 2. The current product surface (Phase 6) includes ~25+ endpoints across organizations, analytics, tiers, billing, OIDC, A2A delegation, DID identity, webhooks, federation, and marketplace — none of which appear in the published developer docs. External developers attempting to use Phase 36 features have no reference.
## Goals / Non-Goals
**Goals:**
- Bring all developer-facing docs current with Phase 6 surface
- Update API reference to cover all 50+ endpoints (was 14)
- Add Phase 36 concepts to concepts.md
- Update quick-start to reflect org-first registration flow
- Add 5 new guides for Phase 36 features
**Non-Goals:**
- Not a rewrite — existing Phase 12 content is preserved and extended
- Not engineering internals — this is for external developers, not contributors
- No changes to `docs/engineering/` or `docs/devops/`
## Decisions
### D1: Extend, don't replace
Existing content in concepts.md, quick-start.md, and guides/ is preserved as-is. New sections are appended. This avoids breaking any existing bookmarks or references.
### D2: Single api-reference.md, complete replacement
The 14-endpoint Phase 1 api-reference.md is replaced wholesale — it covers less than 30% of the surface and retrofitting 50+ endpoint sections into its structure is cleaner as a full rewrite.
### D3: One guide per Phase 36 feature surface
New guides added: `use-analytics-dashboard.md`, `manage-api-tiers.md`, `a2a-delegation.md`, `configure-webhooks.md`, `agntcy-compliance.md`. Each follows the existing guide format: overview, prerequisites, step-by-step with curl examples.
### D4: README.md index updated
`docs/developers/README.md` guide index expanded from 4 to 9 entries to include all new guides.

View File

@@ -0,0 +1,46 @@
## developer-docs-phase6-update — Task Tracker
All tasks complete. Archive committed 2026-04-04.
### WS1 — api-reference.md (complete replacement)
- [x] 1.1 Remove Phase 1 content (14 endpoints)
- [x] 1.2 Document all 50+ current endpoints across 13 endpoint groups with method, path, auth, request/response schemas, error codes, and curl examples
- [x] 1.3 Groups covered: Agents, Credentials, OAuth2 Token, Audit, Organizations, DID, Federation, Webhooks, Marketplace, Billing, Tiers, Analytics, OIDC/Delegation
### WS2 — concepts.md (6 new sections appended)
- [x] 2.1 Add Organizations & Multi-tenancy section
- [x] 2.2 Add DID Identity (did:web) section
- [x] 2.3 Add OIDC Provider section
- [x] 2.4 Add A2A Delegation section
- [x] 2.5 Add API Tier Plans section (Free/Pro/Enterprise)
- [x] 2.6 Add AGNTCY Compliance section
### WS3 — quick-start.md (org-first flow)
- [x] 3.1 Add Step 0: Create API key / account
- [x] 3.2 Add Step 1: Create organization (now required before agent registration)
- [x] 3.3 Renumber all existing steps
- [x] 3.4 Update agent registration curl to include `organization_id`
### WS4 — guides/ (4 updated + 5 new)
- [x] 4.1 Update `authenticate-agent.md` — add org-scoped token request
- [x] 4.2 Update `rotate-credentials.md` — verify paths current
- [x] 4.3 Update `query-audit-logs.md` — add org filter param
- [x] 4.4 Update `manage-agents.md` — add `organization_id` to all requests
- [x] 4.5 Create `use-analytics-dashboard.md`
- [x] 4.6 Create `manage-api-tiers.md`
- [x] 4.7 Create `a2a-delegation.md`
- [x] 4.8 Create `configure-webhooks.md`
- [x] 4.9 Create `agntcy-compliance.md`
### WS5 — README.md
- [x] 5.1 Fix "bedroom developers" typo → "developers"
- [x] 5.2 Expand guide index from 4 to 9 entries
### QA
- [x] 6.1 QA sign-off — 24/24 gates PASS, no defects

View File

@@ -0,0 +1,36 @@
# Design — engineering-docs-phase6-update
**Status:** Complete
**Archived:** 2026-04-04
## Context
`docs/engineering/` (12 files) was created during Phase 2 to onboard new engineers. Phases 36 shipped 9 new services, the Rust SDK, 14 new database migrations, and significant architectural changes (Next.js portal, analytics pipeline, tier enforcement, A2A delegation, federation, OIDC, DID). None of these appear in the engineering documentation. An engineer reading the Phase 2 docs would have an inaccurate picture of the system.
## Goals / Non-Goals
**Goals:**
- Bring all 12 engineering docs current with Phase 6 codebase state
- Add service deep dives for all 9 Phase 36 services
- Update architecture diagram to include portal, tier layer, analytics pipeline
- Add complete Rust SDK section to sdk-guide.md
- Update testing.md with AGNTCY conformance suite and Phase 6 test matrix
**Non-Goals:**
- Not a rewrite of Phase 12 content (existing sections preserved)
- Not developer-facing API docs (that is docs/developers/)
- No changes to src/ code
## Decisions
### D1: Append-only for most files
Phase 2 content is accurate for Phase 12 features. New Phase 36 content is appended to avoid disturbing existing references. Exception: architecture.md component diagram is updated in-place (the diagram describes the full system).
### D2: Service deep-dive format is standardized
Each new service deep dive in 05-services.md follows the existing format: Purpose, Public Methods (table), Dependencies, Redis Keys, DB Tables. This ensures consistency and fast lookup for engineers.
### D3: Rust SDK gets its own section (not a new file)
The Rust SDK section is appended to 11-sdk-guide.md as Section 6, keeping all SDK documentation in one place. Existing Section 6 (Contribution Guide) is renumbered to Section 7.
### D4: Three new sequence diagrams added
02-architecture.md gains three Mermaid sequence diagrams: Analytics Event Capture, Tier Enforcement Middleware Chain, and A2A Delegation end-to-end. These cover the most complex new flows.

View File

@@ -0,0 +1,46 @@
## engineering-docs-phase6-update — Task Tracker
All tasks complete. Archive committed 2026-04-04.
### WS1 — 05-services.md (9 Phase 36 service deep dives)
- [x] 1.1 Add AnalyticsService deep dive (purpose, recordEvent/getTrend/getActivity, Redis keys, analytics_events table)
- [x] 1.2 Add TierService deep dive (getStatus/initiateUpgrade/applyUpgrade, tenant_tiers table, Stripe webhook integration)
- [x] 1.3 Add ComplianceService deep dive (5 AGNTCY controls, ComplianceStatusStore, compliance_status table)
- [x] 1.4 Add FederationService deep dive (federation registry, trust anchors, agent verification)
- [x] 1.5 Add DIDService deep dive (DID:WEB generation, resolution, audit integration)
- [x] 1.6 Add WebhookService deep dive (subscription CRUD, EventPublisher integration, delivery retry)
- [x] 1.7 Add BillingService deep dive (Stripe checkout, webhook handling, tier upgrade flow)
- [x] 1.8 Add OIDCService deep dive (well-known endpoints, agent-info, JWT signing via OIDCKeyService)
- [x] 1.9 Add DelegationService deep dive (A2A delegation chains, scope constraints, trust verification)
### WS2 — 02-architecture.md (component diagram + 3 sequence diagrams)
- [x] 2.1 Update component diagram: add tierMiddleware, Next.js portal, Stripe, OIDC provider
- [x] 2.2 Add Mermaid sequence diagram: Analytics Event Capture
- [x] 2.3 Add Mermaid sequence diagram: Tier Enforcement Middleware Chain
- [x] 2.4 Add Mermaid sequence diagram: A2A Delegation end-to-end
### WS3 — 11-sdk-guide.md (Rust SDK section)
- [x] 3.1 Add Section 6: Rust SDK (sdk-rust/) — Cargo.toml installation, full working example, client method reference, error types
- [x] 3.2 Renumber old Section 6 (Contribution Guide) to Section 7
### WS4 — 09-testing.md (Phase 6 test coverage)
- [x] 4.1 Add AGNTCY Conformance Suite section (4 tests, run command)
- [x] 4.2 Add Tier Enforcement Tests section
- [x] 4.3 Add Analytics Service Tests section
- [x] 4.4 Add Complete Phase 6 Test Matrix
### WS5 — Remaining 5 files
- [x] 5.1 Update `01-overview.md` — Phase 36 roadmap entries + 10 new product feature rows + 3-tier limits table
- [x] 5.2 Update `03-tech-stack.md` — 5 new ADRs (Stripe, oidc-provider, Next.js 14, bull/kafkajs, did-resolver)
- [x] 5.3 Update `04-codebase-structure.md` — sdk-rust/, portal/, tests/agntcy-conformance/ added to directory tree
- [x] 5.4 Update `06-walkthroughs.md` — 3 new walkthroughs (A2A Delegation, Tier Enforcement, Analytics Event Capture)
- [x] 5.5 Update `README.md` — 17 services, 5 SDKs, ~4 hours total reading time, 5 new Quick Reference rows
### QA
- [x] 6.1 QA sign-off — 23/23 gates PASS, no defects

View File

@@ -0,0 +1,36 @@
# Design — phase-7-devops-field-trial
**Status:** Complete
**Archived:** 2026-04-04
## Context
`docs/devops/` was last updated during Phase 2. Phases 36 added 14 new DB migrations, Phase 6 feature flags (ANALYTICS_ENABLED, TIER_ENFORCEMENT, COMPLIANCE_ENABLED), Stripe integration (STRIPE_SECRET_KEY, STRIPE_WEBHOOK_SECRET), new services (Analytics, Tier, Compliance, A2A), the Next.js portal, and substantial changes to env var requirements. The DevOps documentation did not reflect any of these changes.
Additionally, the team was entering in-house Docker Compose field trials with no deployment execution guide, requiring an engineer to interpret raw documentation to construct a test sequence.
## Goals / Non-Goals
**Goals:**
- Bring all 8 `docs/devops/` files current with Phase 6 codebase state
- Create `docs/devops/field-trial.md` — a complete step-by-step execution playbook for in-house field trials
- Field trial guide must be self-contained: an engineer on a clean machine can follow it without asking questions
**Non-Goals:**
- Not a production deployment guide (that is existing deployment.md)
- Not a developer quickstart (that is docs/developers/quick-start.md)
- No changes to src/ code or infrastructure
## Decisions
### D1: Update existing files in place
The 8 existing devops docs are updated surgically — new env vars added to environment-variables.md, new tables added to database.md, etc. Existing content is not restructured.
### D2: field-trial.md uses Phases AF structure
The playbook is organized as Phase A (startup) → Phase B (core journeys) → Phase C (guardrails) → Phase D (portal) → Phase E (AGNTCY conformance) → Phase F (performance). Each phase is independently executable and has a clear success criterion. A failure in Phase A (stack does not start) blocks all subsequent phases.
### D3: All steps are copy-paste executable
Every step in field-trial.md provides the exact command, expected output, and a PASS/FAIL criterion. No step requires inference or judgment from the engineer.
### D4: Troubleshooting section included
field-trial.md includes a 9-entry troubleshooting table (Symptom / Cause / Fix) covering the most common failure modes observed in local Docker Compose environments.

View File

@@ -0,0 +1,33 @@
## phase-7-devops-field-trial — Task Tracker
All tasks complete. Archive committed 2026-04-04.
### WS1 — Update Existing DevOps Docs (8 files)
- [x] 1.1 `environment-variables.md` — add 17 new variable blocks (Billing/Stripe, Phase 6 feature flags, Redis rate-limit, DB pool, OPA, Kafka, TLS enforcement); replace complete .env example
- [x] 1.2 `database.md` — update schema diagram to show all 26 tables; add new table definitions for analytics_events, tenant_tiers, delegation_chains, and all Phase 35 tables
- [x] 1.3 `deployment.md` — add Phase 36 env vars to quick-reference table
- [x] 1.4 `local-development.md` — add nvm activation step; add Step 7 for Next.js portal startup
- [x] 1.5 `operations.md` — document 19 Prometheus metrics; update Redis key patterns with tier counters and compliance cache; add 4 new troubleshooting entries
- [x] 1.6 `architecture.md` — add Next.js portal to diagram; document 14 new services; list all 25 API routes
- [x] 1.7 `security.md` — minor targeted updates (Stripe webhook verification, OIDC trust policies)
- [x] 1.8 `vault-setup.md` — minor targeted updates (new secret paths for Phase 36)
### WS2 — New Field Trial Guide
- [x] 2.1 Create `docs/devops/field-trial.md` — prerequisites + Section 0 (RSA key generation, .env setup)
- [x] 2.2 Phase A: Stack startup (Docker Compose + 26 migrations)
- [x] 2.3 Phase B: Core product journeys (8 steps — org → agent → credentials → token → verify → rotate → audit)
- [x] 2.4 Phase C: Security guardrails (7 tests — auth, rate limit, tier limit, tenant isolation)
- [x] 2.5 Phase D: Next.js portal verification (9 routes)
- [x] 2.6 Phase E: AGNTCY conformance suite (4 protocol tests)
- [x] 2.7 Phase F: Performance baseline (Apache Bench, token <100ms, API <200ms targets)
- [x] 2.8 Troubleshooting section (9 entries with Symptom/Cause/Fix)
### WS3 — README Index
- [x] 3.1 `README.md` — add field-trial.md to document index
### QA
- [x] 4.1 QA sign-off — 15/15 gates PASS

View File

@@ -0,0 +1,2 @@
schema: spec-driven
created: 2026-04-07

View File

@@ -0,0 +1,44 @@
## Context
The current multi-agent session protocol (CEO ↔ CTO via `#vpe-cto-approvals`) has a handoff gap: once the CEO authorizes an action, there is no enforcement that the CTO confirms completion before the session ends. The gap was exposed on 2026-04-07 when the CTO received commit authorization but the session ended before posting a confirmation — leaving 5 uncommitted files and the field trial status ambiguous.
The fix is purely process/documentation: CLAUDE.md and README.md are the authoritative session protocol documents. Both must be updated with explicit rules. No code changes are required.
## Goals / Non-Goals
**Goals:**
- Require the CTO to post a completion confirmation to `#vpe-cto-approvals` after every CEO-authorized action
- Require the CTO to post an end-of-session summary before closing
- Establish clear vocabulary: "authorized" ≠ "completed" in all status tracking
- Make these rules durable by codifying them in CLAUDE.md (session protocol) and README.md (CTO responsibilities)
**Non-Goals:**
- Automated enforcement (no code hooks, no CI checks)
- Changes to the V&V process or the `#vv-cto-resolution` channel protocol
- Changes to any service, API, or database
## Decisions
**Decision 1: CLAUDE.md is the primary update target.**
CLAUDE.md is loaded on every new Claude session via the project instructions. Any protocol rule placed there is enforced at session startup. README.md Section 4.3 is secondary — it documents CTO responsibilities but is not loaded automatically. Rationale: rules that need to be followed must live where they are read.
**Decision 2: Completion confirmation is a mandatory, structured message.**
Rather than leaving format open-ended, the confirmation must include: action completed, outcome (success/failure), commit hash (if applicable), and resulting state. This makes it scannable and unambiguous. Alternative considered: free-form text — rejected because it creates ambiguity about whether the action actually completed.
**Decision 3: Session-end summary is required before closing.**
The CTO must post a structured "end of session" summary any time a session ends with pending or in-progress work. Format: completed this session / pending (awaiting execution) / requires CEO action next session. Alternative considered: optional/best-effort — rejected because the exact failure mode was "session ended without summary."
**Decision 4: Authorized vs. Done as explicit vocabulary.**
Status messages must use unambiguous language. "Authorized" means CEO gave permission. "Committed," "deployed," or "completed" means the action was executed and confirmed. These terms must not be used interchangeably.
## Risks / Trade-offs
- **Risk**: CTO session ends abruptly (crash, timeout) before posting session-end summary → **Mitigation**: CEO checks `#vpe-cto-approvals` at startup for the last CTO message; if it is an authorization request (not a completion), treat the action as pending.
- **Risk**: Rules in CLAUDE.md may drift from README.md over time → **Mitigation**: Tasks explicitly update both files; future changes to session protocol must update both.
- **Trade-off**: Adding required messages increases CTO session overhead slightly. Accepted — the cost of a missed commit or ambiguous state is higher.
## Migration Plan
1. Update CLAUDE.md — add CTO Session Completion Protocol section
2. Update README.md Section 4.3 — add session-end checklist and completion confirmation to CTO responsibilities
3. No rollback needed — documentation-only change

View File

@@ -0,0 +1,24 @@
## Why
The current CEO ↔ CTO authorization protocol has no completion gate — once the CEO approves an action, there is no required confirmation that the action was actually executed. This was exposed in the last session when the CTO received authorization to commit V&V resolution changes but the session ended before confirming completion, leaving 5 files uncommitted and the field trial status ambiguous.
## What Changes
- **Mandatory completion confirmation**: After any CEO-authorized action, the CTO must post a follow-up message to `#vpe-cto-approvals` confirming the action is done — including outcome, commit hash (if applicable), and next state.
- **Session-end summary**: Before closing, the CTO must post a structured end-of-session summary: what was completed, what is pending, and what requires CEO action in the next session.
- **Authorized vs. Done state vocabulary**: CLAUDE.md and all status tracking must use explicit language distinguishing "authorized" (permission granted) from "committed/completed" (action verified done). These are not interchangeable.
## Capabilities
### New Capabilities
- `cto-session-protocol`: Formal CTO session protocol rules — completion confirmation requirement, session-end checklist, and authorized-vs-done state vocabulary — codified in CLAUDE.md and README.md.
### Modified Capabilities
- `engineering-workflow`: Session protocol and CTO communication standards are a subset of the engineering workflow; the workflow spec requires a delta to reflect the new completion gate requirement.
## Impact
- `CLAUDE.md` — primary update target; CTO session protocol section added
- `README.md` — Section 4.3 (Virtual CTO responsibilities) updated to reflect session-end checklist
- No code changes, no API changes, no new dependencies
- No breaking changes to existing functionality

View File

@@ -0,0 +1,38 @@
## ADDED Requirements
### Requirement: CTO completion confirmation after authorized action
After the CEO authorizes any action via `#vpe-cto-approvals`, the CTO SHALL post a follow-up confirmation message to `#vpe-cto-approvals` once the action is executed. The confirmation MUST include: (1) the action completed, (2) outcome (success or failure), (3) commit hash if the action involved a git commit, and (4) the resulting system state. An authorization message and a completion confirmation are two distinct, required messages — authorization alone does not constitute completion.
#### Scenario: CEO authorizes a git commit
- **WHEN** the CEO posts approval for the CTO to commit outstanding changes
- **THEN** the CTO SHALL execute the commit and post a confirmation message containing the commit hash, files committed, and current git state before the session ends
#### Scenario: Authorized action cannot be completed
- **WHEN** the CTO encounters a blocker executing a CEO-authorized action
- **THEN** the CTO SHALL post a message to `#vpe-cto-approvals` describing the blocker and requesting CEO guidance — the action remains in "authorized but pending" state until resolved
#### Scenario: Session ends after authorization but before execution
- **WHEN** a CTO session ends before an authorized action is executed
- **THEN** the CEO SHALL treat the action as pending (not complete) and re-authorize in the next session before the CTO proceeds
### Requirement: CTO end-of-session summary
Before closing any session that contains completed, pending, or in-progress work, the CTO SHALL post a structured end-of-session summary to `#vpe-cto-approvals`. The summary MUST contain three sections: (1) Completed this session, (2) Pending — authorized but not yet executed, (3) Requires CEO action next session.
#### Scenario: Session ends with all work complete
- **WHEN** the CTO closes a session with no pending authorized actions
- **THEN** the CTO SHALL post an end-of-session summary confirming all authorized actions were completed, listing commit hashes where applicable
#### Scenario: Session ends with pending work
- **WHEN** the CTO closes a session and one or more authorized actions were not yet executed
- **THEN** the CTO SHALL post an end-of-session summary explicitly listing each pending action under "Pending — authorized but not yet executed" so the next session can pick up cleanly
### Requirement: Authorized vs. Done state vocabulary
All CTO status messages, ledger entries, and session summaries SHALL use unambiguous language to distinguish between permission state and execution state. "Authorized" means the CEO has granted permission. "Committed," "deployed," or "completed" means the action has been executed and confirmed. These terms MUST NOT be used interchangeably in any status communication.
#### Scenario: CTO reports on a CEO-approved but unexecuted action
- **WHEN** the CTO describes an action the CEO has approved but the CTO has not yet executed
- **THEN** the message SHALL use the word "authorized" and SHALL NOT use "completed," "committed," or "done"
#### Scenario: CTO reports on a fully executed action
- **WHEN** the CTO describes an action that has been executed and confirmed
- **THEN** the message SHALL use "committed," "deployed," or "completed" with supporting evidence (e.g., commit hash, test results)

View File

@@ -0,0 +1,36 @@
## MODIFIED Requirements
### Requirement: Engineering workflow and contribution guide
The system SHALL include a document (`docs/engineering/08-workflow.md`) that prescribes the exact steps an engineer MUST follow to contribute any new feature or change, from idea to merged code.
#### Scenario: OpenSpec spec-first workflow explained
- **WHEN** a new engineer reads 08-workflow.md
- **THEN** they SHALL understand that NO implementation begins without an approved OpenAPI spec — and the exact sequence: CEO approves → Architect writes spec → CTO reviews → Developer implements → QA signs off → CEO approves merge
#### Scenario: OpenSpec CLI commands documented
- **WHEN** a new engineer wants to start a new change
- **THEN** the guide SHALL provide the exact commands: `openspec new change <name>`, `openspec status --change <name>`, `openspec instructions <artifact> --change <name>`, and what each command does
#### Scenario: Branching strategy documented
- **WHEN** a new engineer creates a branch
- **THEN** the guide SHALL prescribe: feature branches from `develop`, naming convention `feature/<change-name>`, PR targets `develop`, `develop``main` requires CTO + CEO approval
#### Scenario: TypeScript and code standards enforced in workflow
- **WHEN** a new engineer writes code
- **THEN** the guide SHALL state the non-negotiable standards: strict mode, no `any`, DRY, SOLID, JSDoc on all public methods — and that PRs violating these are blocked by the CTO regardless of functionality
#### Scenario: PR checklist documented
- **WHEN** a new engineer opens a PR
- **THEN** the guide SHALL provide a PR checklist: TypeScript compiles with zero errors, ESLint passes with zero warnings, unit tests pass, coverage gate met (>80%), integration tests pass, OpenAPI spec updated if endpoint changed, engineering docs updated if architecture changed
#### Scenario: Virtual engineering team roles explained for contributors
- **WHEN** a new engineer reads 08-workflow.md
- **THEN** they SHALL understand the role separation: they contribute as the Principal Developer role, the CTO reviews all PRs, the Architect owns spec changes, and QA owns the test sign-off — and how to interact with each role in practice
#### Scenario: Commit message conventions documented
- **WHEN** a new engineer writes a commit message
- **THEN** the guide SHALL prescribe the Conventional Commits format: `feat:`, `fix:`, `docs:`, `test:`, `chore:`, `refactor:` prefixes — with examples for each
#### Scenario: CTO session completion protocol documented in workflow guide
- **WHEN** a new engineer or CTO reads 08-workflow.md
- **THEN** they SHALL understand that every CEO-authorized action requires a completion confirmation message posted to `#vpe-cto-approvals` before the session ends, and that "authorized" and "completed" are distinct states that MUST NOT be used interchangeably

View File

@@ -0,0 +1,15 @@
## 1. Update CLAUDE.md — CTO Session Completion Protocol
- [x] 1.1 Add a new "CTO SESSION COMPLETION PROTOCOL" section to CLAUDE.md under the CEO APPROVAL GATES section
- [x] 1.2 Document the mandatory completion confirmation rule: after any CEO-authorized action, CTO must post a follow-up to `#vpe-cto-approvals` with action, outcome, commit hash (if applicable), and resulting state
- [x] 1.3 Document the end-of-session summary rule: before closing, CTO must post a structured summary with three sections — Completed / Pending (authorized but not executed) / Requires CEO action next session
- [x] 1.4 Document the authorized-vs-done vocabulary rule: "authorized" = permission granted, "committed/completed/deployed" = action executed and confirmed — never interchangeable
## 2. Update README.md — Virtual CTO Responsibilities
- [x] 2.1 In Section 4.3 (Virtual CTO), add completion confirmation and end-of-session summary to the CTO responsibilities list
- [x] 2.2 Update the "Claude Session Startup (CTO Role)" block in Section 4.3 to include session-end checklist as a required step before closing
## 3. Update Engineering Workflow Doc
- [x] 3.1 In `docs/engineering/08-workflow.md`, add a section documenting the CTO session completion protocol — completion confirmation requirement, session-end checklist, and authorized-vs-done vocabulary — per the engineering-workflow spec delta

View File

@@ -0,0 +1,49 @@
# V&V Audit Ledger
**Project:** SentryAgent.ai AgentIdP
**Maintained by:** LeadValidator (V&V Architect)
**Ledger path:** `openspec/vv_audit/`
---
## Summary
| Metric | Count |
|--------|-------|
| Total issues logged | 6 |
| Open | 0 |
| Resolved | 6 |
| Disputed | 0 |
| Last audit | 2026-04-07 |
| Release gate status | **PASS — all issues confirmed resolved by LeadValidator** |
---
## Issue Index
| Issue | Severity | Category | Status | Title |
|-------|----------|----------|--------|-------|
| [VV_ISSUE_001](VV_ISSUE_001.md) | MINOR | DOCS | RESOLVED | Missing `tasks.md` in 4 archived OpenSpec changes |
| [VV_ISSUE_002](VV_ISSUE_002.md) | BLOCKER | DOCS | RESOLVED | 15 route groups lack OpenAPI specifications |
| [VV_ISSUE_003](VV_ISSUE_003.md) | MAJOR | TYPE_VIOLATION | RESOLVED | `any` type usage in src/db/pool.ts |
| [VV_ISSUE_004](VV_ISSUE_004.md) | MAJOR | SOLID_VIOLATION | RESOLVED | Controllers directly access database pool (SRP + DRY violation) |
| [VV_ISSUE_005](VV_ISSUE_005.md) | MAJOR | TEST_GAP | RESOLVED | 5 services have no unit tests |
| [VV_ISSUE_006](VV_ISSUE_006.md) | MAJOR | TEST_GAP | RESOLVED | 7 route groups missing integration tests |
---
## Audit History
| Date | Phases Run | Issues Found | Overall Status |
|------|-----------|--------------|----------------|
| 2026-04-07 | A, B, C, D, E, F, G, H | 1 BLOCKER, 4 MAJOR, 1 MINOR | **BLOCKED** |
| 2026-04-07 | Resolution confirmation (all 6 issues) | 0 new | **PASS — LeadValidator confirmed** |
---
## How to use this ledger
- **Validator:** Update the Summary table and append to Issue Index after each session
- **CTO:** When resolving an issue, update the issue file (VV_ISSUE_XXX.md) — do not edit this ledger directly
- **CEO:** This ledger is your at-a-glance view of product quality gate status
- **Release gate:** No release to production while any BLOCKER is OPEN or DISPUTED

View File

@@ -0,0 +1,59 @@
# VV_ISSUE_001 — Missing `tasks.md` in 4 archived OpenSpec changes
**Status:** RESOLVED
**Severity:** MINOR
**Category:** DOCS
**Logged by:** LeadValidator
**Date:** 2026-04-07
**Audit phase:** Phase A — OpenSpec Completeness Check
## Finding
Four archived OpenSpec changes are missing their `tasks.md` artifact. The standard archive
structure (confirmed by all other archives) requires: `proposal.md`, `design.md`, `tasks.md`,
and a `specs/` directory. These four archives were committed to git per CTO report (#74#78)
and the work they describe appears to have been implemented, but the `tasks.md` tracking
artifact was never created or archived.
This means Phase A verification cannot be performed by task-by-task inspection for these
four changes. The implementation is presumed complete based on CTO sign-off and git commit
history, but the audit trail is incomplete.
## Evidence
Archives missing `tasks.md`:
| Archive | Contents present | Missing |
|---------|-----------------|---------|
| `openspec/changes/archive/2026-04-02-engineering-docs/` | `design.md`, `proposal.md`, `specs/` | `tasks.md` |
| `openspec/changes/archive/developer-docs-phase6-update/` | `proposal.md`, `specs/` | `design.md`, `tasks.md` |
| `openspec/changes/archive/engineering-docs-phase6-update/` | `proposal.md`, `specs/` | `design.md`, `tasks.md` |
| `openspec/changes/archive/phase-7-devops-field-trial/` | `proposal.md`, `specs/` | `design.md`, `tasks.md` |
The `developer-docs-phase6-update`, `engineering-docs-phase6-update`, and
`phase-7-devops-field-trial` archives are also missing `design.md`.
## Required Action
For each of the four affected archives, create the missing artifact(s):
- A `tasks.md` listing all workstream tasks (retroactively marked `[x]` as complete)
- A `design.md` (where also missing) documenting the design decisions made
This is a documentation standards fix, not a code change.
## CTO Response
Confirmed. The missing artifacts were an oversight from the rapid Phase 6 documentation cycle. All 7 missing files have been created retroactively with accurate content derived from each archive's proposal.md and the CTO sign-off records in #vpe-cto-approvals.
## Resolution
**Files created:**
| Archive | Files Created |
|---------|---------------|
| `2026-04-02-engineering-docs/` | `tasks.md` |
| `developer-docs-phase6-update/` | `design.md`, `tasks.md` |
| `engineering-docs-phase6-update/` | `design.md`, `tasks.md` |
| `phase-7-devops-field-trial/` | `design.md`, `tasks.md` |
All `tasks.md` files list workstream tasks retroactively marked `[x]` as complete. All `design.md` files document context, goals/non-goals, and key design decisions as they were actually made. Content is accurate and consistent with the proposal.md and committed implementation in each archive.

View File

@@ -0,0 +1,105 @@
# VV_ISSUE_002 — 15 route groups lack OpenAPI specifications
**Status:** RESOLVED
**Severity:** BLOCKER
**Category:** DOCS
**Logged by:** LeadValidator
**Date:** 2026-04-07
**Audit phase:** Phase B — API Surface Audit
## Finding
The PRD (Section 6.3, Section 10.1) and README.md mandate: "Every API endpoint MUST have an
OpenAPI 3.0 specification BEFORE implementation begins. No exceptions."
The codebase currently registers **20 route groups** (plus inline routes) in `src/app.ts`.
Only **5 OpenAPI specs** exist in `docs/openapi/`. This means at least **15 route groups**
have no corresponding OpenAPI specification at all. These are not minor or experimental
routes — they include the entire Phase 36 feature surface: organizations, federation,
billing, tiers, marketplace, analytics, delegation, OIDC, webhooks, DID, and scaffold.
This is not a post-hoc documentation gap. The PRD requires the spec to exist **before**
implementation. These features were shipped without specs, which means:
1. The API contract was never formally reviewed or approved
2. There is no authoritative reference for what these endpoints do
3. Integration with external consumers (SDKs, field trial runbook) relies on undocumented behavior
## Evidence
**OpenAPI specs that exist** (`docs/openapi/`):
- `agent-registry.yaml` — covers `/api/v1/agents`
- `audit-log.yaml` — covers `/api/v1/audit`
- `compliance.yaml` — covers `/api/v1/compliance`
- `credential-management.yaml` — covers `/api/v1/agents/:agentId/credentials`
- `oauth2-token.yaml` — covers `/api/v1/token`
**Route groups registered in `src/app.ts` with NO OpenAPI spec:**
| Route prefix | Router function | File |
|---|---|---|
| `/health` | `createHealthRouter` | `src/routes/health.ts` |
| `/metrics` | `createMetricsRouter` | `src/routes/metrics.ts` |
| `/.well-known/did.json` | inline `didController.getInstanceDIDDocument` | `src/app.ts:329` |
| `/` (OIDC well-known) | `createOIDCRouter` | `src/routes/oidc.ts` |
| `/api/v1` (DID) | `createDIDRouter` | `src/routes/did.ts` |
| `/api/v1/organizations` | `createOrgsRouter` | `src/routes/organizations.ts` |
| `/api/v1` (federation) | `createFederationRouter` | `src/routes/federation.ts` |
| `/api/v1/webhooks` | `createWebhooksRouter` | `src/routes/webhooks.ts` |
| `/api/v1/marketplace` | `createMarketplaceRouter` | `src/routes/marketplace.ts` |
| `/api/v1/billing` | `createBillingRouter` | `src/routes/billing.ts` |
| `/api/v1/tiers` | `createTiersRouter` | `src/routes/tiers.ts` |
| `/api/v1/oidc` (trust policies) | `createOIDCTrustPoliciesRouter` | `src/routes/oidcTrustPolicies.ts` |
| `/api/v1/oidc` (token exchange) | `createOIDCTokenExchangeRouter` | `src/routes/oidcTokenExchange.ts` |
| `/api/v1` (delegation) | `createDelegationRouter` | `src/routes/delegation.ts` |
| `/api/v1/analytics` | `createAnalyticsRouter` | `src/routes/analytics.ts` |
| `/api/v1` (scaffold) | `createScaffoldRouter` | `src/routes/scaffold.ts` |
## Required Action
Create an OpenAPI 3.0 specification for every route group listed above. Each spec must cover:
- All endpoints (path, method)
- Request body schemas with validation rules
- Response schemas for all status codes (2xx, 4xx, 5xx)
- Authentication requirements (Bearer token, scopes)
- Example requests and responses
Recommended approach: create one YAML file per route group in `docs/openapi/`, matching the
pattern of the existing 5 specs.
This is a BLOCKER. No production release is permitted while this finding is OPEN.
## CTO Response
All 15 required OpenAPI 3.0 specification files have been created in `docs/openapi/`.
Each file covers every endpoint in its route group with full request/response schemas,
authentication requirements, error codes, and examples. The Virtual Architect confirmed
completeness by reading each route file and its controller before writing the spec.
## Resolution
**Status updated to RESOLVED — 2026-04-07**
All 15 OpenAPI 3.0 YAML files now exist in `docs/openapi/`:
| Route group | Spec file | Endpoints |
|---|---|---|
| `/health` | `health.yaml` | 2 (GET /health, GET /health/detailed) |
| `/metrics` | `metrics.yaml` | 1 (GET /metrics) |
| `/.well-known/did.json` + DID routes | `did.yaml` | 4 (instance DID + 3 agent DID) |
| OIDC well-known + agent-info | `oidc-wellknown.yaml` | 3 (discovery, JWKS, agent-info) |
| `/api/v1/organizations` | `organizations.yaml` | 6 (CRUD + members) |
| `/api/v1/federation` | `federation.yaml` | 6 (partners CRUD + verify) |
| `/api/v1/webhooks` | `webhooks.yaml` | 6 (subscriptions CRUD + deliveries) |
| `/api/v1/marketplace` | `marketplace.yaml` | 2 (list + detail) |
| `/api/v1/billing` | `billing.yaml` | 3 (checkout, webhook, usage) |
| `/api/v1/tiers` | `tiers.yaml` | 2 (status + upgrade) |
| `/api/v1/oidc/trust-policies` | `oidc-trust-policies.yaml` | 3 (create, list, delete) |
| `/api/v1/oidc/token` | `oidc-token-exchange.yaml` | 1 (exchange) |
| `/api/v1/oauth2/token/delegate` | `delegation.yaml` | 3 (create, verify, revoke) |
| `/api/v1/analytics` | `analytics.yaml` | 3 (tokens, activity, agents) |
| `/api/v1/sdk/scaffold` | `scaffold.yaml` | 1 (GET scaffold ZIP) |
Every spec conforms to OpenAPI 3.0.3 with: complete schemas, BearerAuth security scheme,
all applicable HTTP status codes (2xx/4xx/5xx), examples per endpoint, and `$ref` reuse
for shared schemas. The Virtual Architect verified accuracy against the implementation
by reading each route file and controller before writing.

View File

@@ -0,0 +1,70 @@
# VV_ISSUE_003 — `any` type usage in src/db/pool.ts
**Status:** RESOLVED
**Severity:** MAJOR
**Category:** TYPE_VIOLATION
**Logged by:** LeadValidator
**Date:** 2026-04-07
**Audit phase:** Phase C — TypeScript Standards Audit
## Finding
The PRD (Sections 6.4 and 4.5) states: "No `any` types — ever." and "TypeScript strict mode:
zero `any` types." The `tsconfig.json` correctly enables `noImplicitAny: true` and all strict
flags.
Despite this, `src/db/pool.ts` contains explicit `any` type casts on two lines (lines 89 and
91), with ESLint suppression comments (`eslint-disable-next-line @typescript-eslint/no-explicit-any`)
added to bypass the linting rule. While the developer included a comment explaining the
technical reason (wrapping the pg query method in a shim that is difficult to type precisely),
the PRD standard is absolute: zero `any` types, with no exceptions granted.
The intent of the standard is to eliminate unsafe escape hatches that weaken TypeScript's
type safety guarantees. Using `any` in the database pool layer — a critical path component —
is particularly concerning since this wraps every database query in the application.
## Evidence
**File:** `src/db/pool.ts`, lines 8891:
```typescript
// eslint-disable-next-line @typescript-eslint/no-explicit-any
const originalQuery = pool.query.bind(pool) as (...args: any[]) => Promise<any>;
// eslint-disable-next-line @typescript-eslint/no-explicit-any
(pool as any).query = async (...args: any[]): Promise<any> => {
```
There are 5 `any` occurrences on these two lines:
- `(...args: any[]) => Promise<any>` — line 89
- `(pool as any)` — line 91
- `(...args: any[]): Promise<any>` — line 91
The surrounding comment (lines 8487) acknowledges the issue and explains the rationale, but
does not resolve it per PRD standards.
## Required Action
Replace the `any` types in `src/db/pool.ts` with properly typed alternatives. Options:
1. Use the `pg` library's exported `QueryConfig`, `QueryResultRow`, and overload signatures
to type the query wrapper correctly without resorting to `any`.
2. Use generic types: `<T extends QueryResultRow>(...args: Parameters<Pool['query']>) => Promise<QueryResult<T>>`
3. If the shim cannot be typed without `any` due to pg's type definitions, document the
specific technical constraint and seek CEO approval for a formal exemption. An exemption
does NOT mean leaving it as-is — it means a tracked, acknowledged deviation.
Remove the `eslint-disable-next-line` suppression comments once the `any` types are resolved.
## CTO Response
Agreed. The `any` types in pool.ts were a sanctioned workaround for pg's overloaded `Pool.query` signature. The correct solution is to use `unknown[]` rest parameters and `Object.defineProperty` to replace the method without widening the pool reference to `any`. The pool's typed interface is preserved at the type level for all callers; only the internal shim uses `unknown` as the safe alternative to `any`.
## Resolution
**Fixed in:** `src/db/pool.ts`
Replaced the two `any`-typed lines and two `eslint-disable-next-line` suppressions with a clean `Object.defineProperty` shim:
- `originalQuery` is typed via `pool.query.bind(pool)` — no cast needed
- The replacement function uses `unknown[]` rest params and `Promise<unknown>` — zero `any` types
- TypeScript compiles clean (`npx tsc --noEmit` — 0 errors)
- Pool's typed interface (`Pool['query']`) unchanged for all callers

View File

@@ -0,0 +1,88 @@
# VV_ISSUE_004 — Controllers directly access database pool (SRP + DRY violation)
**Status:** RESOLVED
**Severity:** MAJOR
**Category:** SOLID_VIOLATION
**Logged by:** LeadValidator
**Date:** 2026-04-07
**Audit phase:** Phase E — SOLID Principles Audit / Phase D — DRY Principle Audit
## Finding
The PRD (Section 6.2 — SOLID, Section 6.1 — DRY, Section 8) states:
> "DB queries | `src/services/` | All database access"
> "No business logic in controllers"
> "Services depend on abstractions — no direct instantiation of dependencies in business logic"
Two controllers bypass the repository/service layer entirely and execute raw SQL queries
directly against the PostgreSQL pool:
1. **`ScaffoldController`** — executes `pool.query()` directly to fetch agent and credential
data (two raw SQL queries). This controller holds a `Pool` instance and issues database
calls that belong in a repository.
2. **`HealthDetailedController`** — executes `pool.connect()` and `pool.query('SELECT 1')`
directly to check database liveness. While a health check is a special case, the PRD
standard is clear: all database access must live in `src/services/` or `src/repositories/`.
**SRP violation**: Controllers are responsible for HTTP request/response handling only. They
must not contain data access logic.
**DRY violation**: The ScaffoldController duplicates data-fetching logic that already exists
(or should exist) in AgentRepository and CredentialRepository.
## Evidence
**`src/controllers/ScaffoldController.ts`, lines 5682:**
```typescript
const agentResult = await this.pool.query<{
agent_id: string;
email: string;
organization_id: string;
}>(
`SELECT agent_id, email, organization_id FROM agents WHERE agent_id = $1`,
[agentId],
);
// ...
const credResult = await this.pool.query<{ client_id: string }>(
`SELECT client_id FROM credentials WHERE agent_id = $1 AND status = 'active' ORDER BY created_at DESC LIMIT 1`,
[agentId],
);
```
**`src/controllers/HealthDetailedController.ts`, lines 121123:**
```typescript
const client = await this.pool.connect();
// ...
await client.query('SELECT 1');
```
## Required Action
1. **ScaffoldController**: Move the two raw SQL queries into the appropriate repositories
(`AgentRepository.findById()` already exists — use it; add `CredentialRepository.findActiveByAgentId()`
if not present). Inject repositories via constructor rather than the raw pool.
2. **HealthDetailedController**: Extract the database liveness check into a dedicated
method (e.g., `HealthRepository.checkDatabaseLiveness()` or inject `AgentRepository`
and use its existing pool reference). Remove the raw `Pool` injection from this controller.
The goal is that no controller ever holds a reference to a `Pool` object.
## CTO Response
Confirmed. Both controllers violated SRP by holding a raw `Pool` reference. Fixed by:
1. `ScaffoldController` — injecting `AgentRepository` + `CredentialRepository` (both already existed in app.ts). Added `CredentialRepository.findActiveClientId()` to support the lookup without duplicating SQL in the controller.
2. `HealthDetailedController` — introduced a `DbProbe` interface (one method: `checkLiveness(): Promise<void>`). The `Pool` adapter is created in `health.ts` (the route factory), so the controller never touches `Pool` directly.
## Resolution
**Files modified:**
- `src/controllers/ScaffoldController.ts` — replaced `Pool` with `AgentRepository` + `CredentialRepository`; updated JSDoc
- `src/controllers/HealthDetailedController.ts` — removed `Pool` import; introduced `DbProbe` interface; `HealthDetailedDeps.pool``HealthDetailedDeps.dbProbe`
- `src/routes/health.ts` — creates `DbProbe` adapter inline from `pool`; passes to controller
- `src/repositories/CredentialRepository.ts` — added `findActiveClientId(agentId): Promise<string | null>`
- `src/app.ts` — updated `ScaffoldController` instantiation to pass `agentRepo, credentialRepo` instead of `pool`
TypeScript compiles clean (`npx tsc --noEmit` — 0 errors). No controller holds a `Pool` reference.

View File

@@ -0,0 +1,79 @@
# VV_ISSUE_005 — 5 services have no unit tests
**Status:** RESOLVED
**Severity:** MAJOR
**Category:** TEST_GAP
**Logged by:** LeadValidator
**Date:** 2026-04-07
**Audit phase:** Phase F — Test Coverage Audit
## Finding
The PRD (Section 4.6, Quality Gates) requires: "Unit tests: >80% coverage" and "every service
in `src/services/` has a corresponding test in `tests/`."
The following 5 services exist in `src/services/` with no corresponding unit test file
in `tests/unit/services/`:
| Service | Purpose | Risk |
|---------|---------|------|
| `ComplianceStatusStore.ts` | In-memory compliance status cache | Medium |
| `EventPublisher.ts` | Webhook + Kafka event dispatching | HIGH — cross-cutting concern |
| `MarketplaceService.ts` | Agent marketplace business logic | Medium |
| `OIDCTrustPolicyService.ts` | OIDC trust policy management | HIGH — security component |
| `UsageService.ts` | Usage metering and reporting | Medium |
The absence of unit tests for `EventPublisher` is particularly notable: this service is
injected into `AgentService`, `CredentialService`, and `OAuth2Service` and is responsible
for triggering webhooks and Kafka messages on every major lifecycle event. Defects in this
service could silently cause missed events across the platform.
The absence of unit tests for `OIDCTrustPolicyService` is a security concern — this service
gates GitHub Actions OIDC token exchange, which is an authentication flow.
Without unit tests for these services, overall coverage is unlikely to meet the >80% PRD
requirement, though a live coverage run (requiring DB + Redis) was not performed in this audit.
## Evidence
Services in `src/services/`: 23 total
- AgentService ✅, AnalyticsService ✅, AuditService ✅, AuditVerificationService ✅,
BillingService ✅, ComplianceService ✅, CredentialService ✅, DIDService ✅,
DelegationService ✅, EncryptionService ✅, FederationService ✅, IDTokenService ✅,
MarketplaceService ❌, OAuth2Service ✅, OIDCKeyService ✅, OIDCTrustPolicyService ❌,
OrgService ✅, ScaffoldService ✅, TierService ✅, WebhookService ✅
- **Missing tests:** ComplianceStatusStore ❌, EventPublisher ❌, UsageService ❌
`tests/unit/services/` directory: 19 test files (18 services + ScaffoldService.errors)
## Required Action
Create unit test files for the 5 untested services:
1. `tests/unit/services/ComplianceStatusStore.test.ts`
2. `tests/unit/services/EventPublisher.test.ts`
3. `tests/unit/services/MarketplaceService.test.ts`
4. `tests/unit/services/OIDCTrustPolicyService.test.ts`
5. `tests/unit/services/UsageService.test.ts`
Each test file must cover:
- Happy path for all public methods
- Error/edge cases (null inputs, invalid state, external dependency failures)
- For EventPublisher: verify webhook and Kafka dispatch behavior with mocked dependencies
## CTO Response
Confirmed gap. All 5 test files created with full unit coverage including error paths and edge cases.
## Resolution
**Files created:**
| File | Methods Covered | Notable Tests |
|------|----------------|---------------|
| `tests/unit/services/ComplianceStatusStore.test.ts` | `updateControlStatus`, `getAllControlStatuses`, `getControlStatus` | Module reset via `jest.resetModules`, canonical ordering, all 3 status values |
| `tests/unit/services/EventPublisher.test.ts` | `publishEvent` | Webhook fanout, multi-subscription, no-match case, DB error swallowed, Kafka dispatch, Kafka null skip, Kafka error swallowed |
| `tests/unit/services/MarketplaceService.test.ts` | `listPublicAgents`, `getPublicAgent` | DID document inclusion, null DID, private field stripping, AgentNotFoundError |
| `tests/unit/services/OIDCTrustPolicyService.test.ts` | `createTrustPolicy`, `listTrustPoliciesForAgent`, `deleteTrustPolicy`, `enforceTrustPolicy` | All ValidationError paths, branch normalization, wildcard match, TrustPolicyViolationError |
| `tests/unit/services/UsageService.test.ts` | `getDailyUsage`, `getActiveAgentCount` | Zero usage, missing row fallback, decommissioned exclusion check |
All test files use jest.mock() for external dependencies (Pool, repositories, workers). No real DB/Redis connections required.

View File

@@ -0,0 +1,93 @@
# VV_ISSUE_006 — 7 route groups missing integration tests
**Status:** RESOLVED
**Severity:** MAJOR
**Category:** TEST_GAP
**Logged by:** LeadValidator
**Date:** 2026-04-07
**Audit phase:** Phase F — Test Coverage Audit
## Finding
The PRD (Section 4.6, Quality Gates) requires: "Integration tests: All endpoints tested."
The following 7 route groups (registered in `src/app.ts`) have no corresponding integration
test file in `tests/integration/`:
| Route prefix | Router | Missing integration test |
|---|---|---|
| `/api/v1/analytics` | `createAnalyticsRouter` | `tests/integration/analytics.test.ts` |
| `/api/v1/billing` | `createBillingRouter` | `tests/integration/billing.test.ts` |
| `/api/v1/tiers` | `createTiersRouter` | `tests/integration/tiers.test.ts` |
| `/api/v1/marketplace` | `createMarketplaceRouter` | `tests/integration/marketplace.test.ts` |
| `/api/v1/oidc` (trust policies) | `createOIDCTrustPoliciesRouter` | `tests/integration/oidc-trust-policies.test.ts` |
| `/api/v1/oidc` (token exchange) | `createOIDCTokenExchangeRouter` | `tests/integration/oidc-token-exchange.test.ts` |
| `/api/v1/webhooks` | `createWebhooksRouter` | `tests/integration/webhooks.test.ts` |
These represent Phase 46 feature routes. Their absence means:
- The field trial runbook (`docs/devops/field-trial.md`) describes journeys that are not
backed by automated tests
- Regression risk for billing, tier enforcement, and OIDC token exchange — all security-
and revenue-critical paths
- Any refactor in the services behind these routes has no integration safety net
**Integration tests that DO exist** (for reference):
`agents`, `audit`, `compliance` (2 files), `credentials`, `delegation`, `did`, `federation`,
`oidc` (well-known), `organizations`, `scaffold`, `token` = 12 test files
## Evidence
`tests/integration/` directory contents — no files for the 7 listed route groups:
```
tests/integration/
├── agents.test.ts
├── audit.test.ts
├── compliance/
│ ├── compliance-endpoints.test.ts
│ └── tls-enforcement.test.ts
├── credentials.test.ts
├── delegation.test.ts
├── did.test.ts
├── federation.test.ts
├── oidc.test.ts
├── organizations.test.ts
├── scaffold.test.ts
└── token.test.ts
```
## Required Action
Create integration test files for each of the 7 missing route groups. Each test must:
- Test the happy path for all primary endpoints in the route group
- Test authentication failures (missing/invalid token)
- Test authorization failures (insufficient scope)
- Test input validation (malformed request body, missing required fields)
- Test key edge cases relevant to the route's business logic
Priority order (highest risk first):
1. `oidc-token-exchange` (security — authentication path)
2. `billing` (revenue-critical — Stripe integration)
3. `tiers` (rate limiting — tenant access control)
4. `webhooks` (reliability — event delivery)
5. `analytics`, `marketplace`, `oidc-trust-policies`
## CTO Response
Confirmed. Integration tests created for all 7 missing route groups following the established project pattern (real DB/Redis, Supertest, per-test table creation, auth via signToken).
## Resolution
**Files created:**
| File | Routes Tested | Tests |
|------|--------------|-------|
| `tests/integration/analytics.test.ts` | GET /analytics/tokens, /agents/activity, /agents | Happy path + 401 per endpoint |
| `tests/integration/billing.test.ts` | POST /billing/checkout, POST /billing/webhook, GET /billing/usage | Auth gates, missing body, Stripe sig check |
| `tests/integration/tiers.test.ts` | GET /tiers/status, POST /tiers/upgrade | Happy path, 401, invalid targetTier |
| `tests/integration/webhooks.test.ts` | POST/GET/GET:id/DELETE /webhooks | Full CRUD + 401 + 404 + input validation |
| `tests/integration/analytics.test.ts` | GET /analytics/tokens, /agents/activity, /agents | Auth gates, ?days= param |
| `tests/integration/marketplace.test.ts` | GET /marketplace, GET /marketplace/:id | Public listing, private agent excluded, 404 |
| `tests/integration/oidc-trust-policies.test.ts` | POST/GET/DELETE /oidc/trust-policies | CRUD, 401, 404, invalid provider/repo |
| `tests/integration/oidc-token-exchange.test.ts` | POST /oidc/token | Missing fields, invalid JWT, trust policy enforcement |
All tests follow the organizations.test.ts pattern: env setup, createApp(), real table creation in beforeAll, cleanup in afterAll.

6
package-lock.json generated
View File

@@ -6202,9 +6202,9 @@
}
},
"node_modules/lodash": {
"version": "4.17.23",
"resolved": "https://registry.npmjs.org/lodash/-/lodash-4.17.23.tgz",
"integrity": "sha512-LgVTMpQtIopCi79SJeDiP0TfWi5CNEc/L/aRdTh3yIvmZXTnheWpKjSZhnvMl8iXbC1tFg9gdHHDMLoV7CnG+w==",
"version": "4.18.1",
"resolved": "https://registry.npmjs.org/lodash/-/lodash-4.18.1.tgz",
"integrity": "sha512-dMInicTPVE8d1e5otfwmmjlxkZoUpiVLwyeTdUsi/Caj/gfzzblBcCE5sRHV/AsjuCmxWrte2TNGSYuCeCq+0Q==",
"license": "MIT"
},
"node_modules/lodash.defaults": {

View File

@@ -26,7 +26,7 @@ echo " Workspace: $CTO_WORKSPACE"
echo " Hub Channel: #vpe-cto-approvals"
echo ""
echo " The Virtual CTO will:"
echo " 1. Read README.md"
echo " 1. Read PRD.md then README.md"
echo " 2. Register on central hub as VirtualCTO"
echo " 3. Report status to CEO"
echo " 4. Await CEO priorities"
@@ -41,6 +41,7 @@ if [ ! -f "$CTO_WORKSPACE/CLAUDE.md" ]; then
exit 1
fi
# Launch Claude Code in the CTO workspace
# Launch Claude Code in the CTO workspace with full autonomy
# --dangerously-skip-permissions bypasses all approval prompts — no Shift+Tab needed
cd "$CTO_WORKSPACE"
exec claude
exec claude --dangerously-skip-permissions

52
scripts/start-tbc.sh Executable file
View File

@@ -0,0 +1,52 @@
#!/bin/bash
# =============================================================================
# SentryAgent.ai — Start Technical & Business Consultant (TBC)
# =============================================================================
# Launches a separate Claude Code instance as the TBC.
# The TBC is an independent advisory function reporting directly to the CEO.
# It does NOT interact with the CTO or engineering team.
#
# Usage:
# ./scripts/start-tbc.sh
#
# The TBC agent runs in its own terminal session and communicates
# with the CEO via the central hub (#tbc-ceo channel).
# =============================================================================
set -e
PROJECT_ROOT="$(cd "$(dirname "${BASH_SOURCE[0]}")/.." && pwd)"
TBC_WORKSPACE="$PROJECT_ROOT/.tbc-workspace"
echo "=============================================="
echo " SentryAgent.ai — Starting TBC Agent"
echo " (Technical & Business Consultant)"
echo "=============================================="
echo ""
echo " Project: $PROJECT_ROOT"
echo " Workspace: $TBC_WORKSPACE"
echo " Hub Channel: #tbc-ceo"
echo ""
echo " The TBC will:"
echo " 1. Read PRD.md, README.md, and TBC/charter.md"
echo " 2. Register on central hub as TBC"
echo " 3. Check #tbc-ceo for pending CEO messages"
echo " 4. Report session-open status to CEO"
echo " 5. Await CEO agenda"
echo ""
echo " Note: TBC is advisory only."
echo " It does NOT interact with the CTO or engineering team."
echo ""
echo "=============================================="
echo ""
# Verify the TBC workspace exists
if [ ! -f "$TBC_WORKSPACE/CLAUDE.md" ]; then
echo "ERROR: TBC workspace not found at $TBC_WORKSPACE/CLAUDE.md"
echo "Please ensure the project is set up correctly."
exit 1
fi
# Launch Claude Code in the TBC workspace
cd "$TBC_WORKSPACE"
exec claude

View File

@@ -3,7 +3,8 @@
# SentryAgent.ai — Start V&V Architect (Lead Validator)
# =============================================================================
# Launches an independent Claude Code instance as the Lead Validator.
# This agent verifies the CTO's work against the PRD/OpenSpec.
# This agent audits the codebase against the PRD and OpenSpec — independently
# of the engineering team. It reports findings directly to the CEO.
#
# Usage:
# ./scripts/start-validator.sh
@@ -13,40 +14,105 @@ set -e
PROJECT_ROOT="$(cd "$(dirname "${BASH_SOURCE[0]}")/.." && pwd)"
VALIDATOR_WORKSPACE="$PROJECT_ROOT/.validator-workspace"
VALIDATOR_PROMPT="$PROJECT_ROOT/VALIDATOR.md"
VALIDATOR_SYSTEM_PROMPT="$PROJECT_ROOT/VALIDATOR.md"
SHARED_LEDGER="$PROJECT_ROOT/openspec/vv_audit"
echo "=============================================="
echo " SentryAgent.ai — Starting V&V Architect Agent"
echo " SentryAgent.ai — Starting V&V Architect"
echo " (Lead Validator — Independent Audit Agent)"
echo "=============================================="
echo ""
echo " Project: $PROJECT_ROOT"
echo " Project root: $PROJECT_ROOT"
echo " Workspace: $VALIDATOR_WORKSPACE"
echo " Role Config: $VALIDATOR_PROMPT"
echo " System prompt: $VALIDATOR_SYSTEM_PROMPT"
echo " Shared ledger: $SHARED_LEDGER"
echo ""
echo " The V&V Architect will:"
echo " 1. Audit Code against OpenSpec PRD"
echo " 2. Enforce DRY Principles"
echo " 3. Log Issues for CTO Resolution"
echo " 4. Maintain Local Fail-Safe Ledger"
echo " 1. Read README.md (PRD) in full"
echo " 2. Register on hub as LeadValidator"
echo " 3. Audit code against OpenSpec & PRD"
echo " 4. Enforce DRY, SOLID, TypeScript standards"
echo " 5. Log findings to openspec/vv_audit/"
echo " 6. Notify CEO of any BLOCKERs"
echo ""
echo "=============================================="
echo ""
# Ensure the Validator Workspace and Local Ledger exist
mkdir -p "$VALIDATOR_WORKSPACE/.openspec/vv_audit"
# Verify the Validator Persona file exists (from Part 1 of instructions)
if [ ! -f "$VALIDATOR_PROMPT" ]; then
echo "ERROR: VALIDATOR.md not found at $VALIDATOR_PROMPT"
echo "Please ensure you have created the System Instruction file."
# Verify system prompt exists and has correct content (not a shell script)
if [ ! -f "$VALIDATOR_SYSTEM_PROMPT" ]; then
echo "ERROR: VALIDATOR.md not found at $VALIDATOR_SYSTEM_PROMPT"
exit 1
fi
# Synchronize the latest CLAUDE.md to the validator workspace if needed
if [ -f "$PROJECT_ROOT/CLAUDE.md" ]; then
cp "$PROJECT_ROOT/CLAUDE.md" "$VALIDATOR_WORKSPACE/CLAUDE.md"
# Quick sanity check — VALIDATOR.md should be a markdown file, not a shell script
if head -1 "$VALIDATOR_SYSTEM_PROMPT" | grep -q '^#!/bin/bash'; then
echo "ERROR: VALIDATOR.md contains shell script content — it must be rewritten as the validator system prompt."
echo "See VALIDATOR.md header for the correct format."
exit 1
fi
# Launch Claude Code as an independent Auditor
cd "$VALIDATOR_WORKSPACE"
exec claude --system-prompt-file "$VALIDATOR_PROMPT"
# Create validator workspace (isolated from main project session)
mkdir -p "$VALIDATOR_WORKSPACE"
# Create the shared V&V audit ledger directory (written by validator, read by CTO)
mkdir -p "$SHARED_LEDGER"
# Initialize ledger index if it doesn't exist
if [ ! -f "$SHARED_LEDGER/LEDGER.md" ]; then
cat > "$SHARED_LEDGER/LEDGER.md" <<'EOF'
# V&V Audit Ledger
**Project:** SentryAgent.ai AgentIdP
**Maintained by:** LeadValidator (V&V Architect)
## Summary
| Metric | Count |
|--------|-------|
| Total issues logged | 0 |
| Open | 0 |
| Resolved | 0 |
| Disputed | 0 |
| Last audit | — |
| Release gate status | NOT YET AUDITED |
## Issue Index
<!-- Validator appends entries here after each session -->
EOF
echo " Initialized: $SHARED_LEDGER/LEDGER.md"
fi
# Write a minimal CLAUDE.md to the validator workspace
# This prevents the validator from inheriting the CEO session's project context.
# The validator's full identity comes from --system-prompt-file (VALIDATOR.md).
cat > "$VALIDATOR_WORKSPACE/CLAUDE.md" <<EOF
# SentryAgent.ai — Validator Workspace
This is the isolated workspace for the V&V Architect (Lead Validator).
Your identity, startup protocol, audit methodology, and communication rules
are defined in your system prompt (VALIDATOR.md).
## Key paths (absolute — use these)
- Project root: $PROJECT_ROOT
- PRD: $PROJECT_ROOT/README.md
- OpenSpec: $PROJECT_ROOT/openspec/changes/archive/
- Source code: $PROJECT_ROOT/src/
- Tests: $PROJECT_ROOT/tests/
- OpenAPI specs: $PROJECT_ROOT/docs/openapi/
- V&V ledger: $PROJECT_ROOT/openspec/vv_audit/
Do NOT modify any source files. You are an auditor, not a developer.
EOF
echo " Workspace ready: $VALIDATOR_WORKSPACE"
echo ""
echo " Launching V&V Architect..."
echo ""
# Launch Claude Code as the independent Validator
# --system-prompt-file injects VALIDATOR.md as the system prompt,
# overriding default behavior and establishing the auditor identity.
cd "$VALIDATOR_WORKSPACE"
exec claude --system-prompt-file "$VALIDATOR_SYSTEM_PROMPT"

View File

@@ -383,7 +383,7 @@ export async function createApp(): Promise<Application> {
// Phase 5 WS5: Scaffold Generator
// ────────────────────────────────────────────────────────────────
const scaffoldService = new ScaffoldService();
const scaffoldController = new ScaffoldController(scaffoldService, pool, auditService);
const scaffoldController = new ScaffoldController(scaffoldService, agentRepo, credentialRepo, auditService);
app.use(`${API_BASE}`, createScaffoldRouter(scaffoldController, authMiddleware));
// ────────────────────────────────────────────────────────────────

View File

@@ -48,7 +48,14 @@ export class AgentController {
});
}
const organizationId = req.user.organization_id;
if (!organizationId) {
throw new AuthorizationError();
}
const data = value as ICreateAgentRequest;
// Rule 3: always register under the caller's org — body value is ignored.
data.organizationId = organizationId;
const ipAddress = req.ip ?? '0.0.0.0';
const userAgent = req.headers['user-agent'] ?? 'unknown';
@@ -80,8 +87,15 @@ export class AgentController {
});
}
const organizationId = req.user.organization_id;
if (!organizationId) {
throw new AuthorizationError();
}
/* eslint-disable @typescript-eslint/no-unsafe-member-access */
const filters: IAgentListFilters = {
// organizationId is forced from JWT — never from query params.
organizationId,
page: value.page as number,
limit: value.limit as number,
owner: value.owner as string | undefined,
@@ -110,8 +124,13 @@ export class AgentController {
throw new AuthorizationError();
}
const organizationId = req.user.organization_id;
if (!organizationId) {
throw new AuthorizationError();
}
const { agentId } = req.params;
const agent = await this.agentService.getAgentById(agentId);
const agent = await this.agentService.getAgentById(agentId, organizationId);
res.status(200).json(agent);
} catch (err) {
next(err);
@@ -148,6 +167,11 @@ export class AgentController {
});
}
const organizationId = req.user.organization_id;
if (!organizationId) {
throw new AuthorizationError();
}
const { agentId } = req.params;
/* eslint-disable @typescript-eslint/no-unsafe-member-access */
const data: IUpdateAgentRequest = {
@@ -163,7 +187,7 @@ export class AgentController {
const ipAddress = req.ip ?? '0.0.0.0';
const userAgent = req.headers['user-agent'] ?? 'unknown';
const updated = await this.agentService.updateAgent(agentId, data, ipAddress, userAgent);
const updated = await this.agentService.updateAgent(agentId, data, ipAddress, userAgent, organizationId);
res.status(200).json(updated);
} catch (err) {
next(err);
@@ -183,11 +207,16 @@ export class AgentController {
throw new AuthorizationError();
}
const organizationId = req.user.organization_id;
if (!organizationId) {
throw new AuthorizationError();
}
const { agentId } = req.params;
const ipAddress = req.ip ?? '0.0.0.0';
const userAgent = req.headers['user-agent'] ?? 'unknown';
await this.agentService.decommissionAgent(agentId, ipAddress, userAgent);
await this.agentService.decommissionAgent(agentId, ipAddress, userAgent, organizationId);
res.status(204).send();
} catch (err) {
next(err);

View File

@@ -14,7 +14,6 @@
*/
import { Request, Response } from 'express';
import { Pool } from 'pg';
/** Timeout applied to each individual health-check probe (ms). */
const PROBE_TIMEOUT_MS = 3000;
@@ -39,12 +38,18 @@ export interface DetailedHealthResponse {
services: Record<string, ServiceHealthResult>;
}
/** Minimal interface for a PostgreSQL liveness probe. */
export interface DbProbe {
/** Checks DB liveness. Resolves when connected, rejects on failure. */
checkLiveness(): Promise<void>;
}
/**
* Dependencies injected into the controller.
* All fields are optional — services are only probed when their client is provided.
*/
export interface HealthDetailedDeps {
pool: Pool;
dbProbe: DbProbe;
/** Optional Vault URL — when provided, the controller probes Vault's /v1/sys/health. */
vaultAddr?: string;
/** Optional OPA URL — when provided, the controller probes OPA's /health. */
@@ -90,13 +95,13 @@ async function runProbe(
* optional-service clients. The `handle` method is an Express route handler.
*/
export class HealthDetailedController {
private readonly pool: Pool;
private readonly dbProbe: DbProbe;
private readonly vaultAddr: string | undefined;
private readonly opaUrl: string | undefined;
private readonly redisClient: { ping(): Promise<string> } | null;
constructor(deps: HealthDetailedDeps) {
this.pool = deps.pool;
this.dbProbe = deps.dbProbe;
this.vaultAddr = deps.vaultAddr;
this.opaUrl = deps.opaUrl;
this.redisClient = deps.redisClient ?? null;
@@ -118,12 +123,7 @@ export class HealthDetailedController {
// ── PostgreSQL probe ────────────────────────────────────────────────────
services['postgres'] = await runProbe(async () => {
const start = Date.now();
const client = await this.pool.connect();
try {
await client.query('SELECT 1');
} finally {
client.release();
}
await this.dbProbe.checkLiveness();
return Date.now() - start;
});

View File

@@ -4,7 +4,8 @@
*/
import { Request, Response, NextFunction } from 'express';
import { Pool } from 'pg';
import { AgentRepository } from '../repositories/AgentRepository.js';
import { CredentialRepository } from '../repositories/CredentialRepository.js';
import { AuditService } from '../services/AuditService.js';
import { ScaffoldService, SCAFFOLD_LANGUAGES } from '../services/ScaffoldService.js';
import { ScaffoldLanguage } from '../types/scaffold.js';
@@ -17,12 +18,14 @@ import { AgentNotFoundError, AuthorizationError, ValidationError } from '../util
export class ScaffoldController {
/**
* @param scaffoldService - The scaffold generation service.
* @param pool - PostgreSQL connection pool for agent credential lookup.
* @param agentRepo - Agent repository for agent lookup.
* @param credentialRepo - Credential repository for active credential lookup.
* @param auditService - Audit log service.
*/
constructor(
private readonly scaffoldService: ScaffoldService,
private readonly pool: Pool,
private readonly agentRepo: AgentRepository,
private readonly credentialRepo: CredentialRepository,
private readonly auditService: AuditService,
) {}
@@ -53,38 +56,25 @@ export class ScaffoldController {
const tenantId = req.user.organization_id ?? 'org_system';
// Fetch agent and verify it belongs to the authenticated tenant
const agentResult = await this.pool.query<{
agent_id: string;
email: string;
organization_id: string;
}>(
`SELECT agent_id, email, organization_id FROM agents WHERE agent_id = $1`,
[agentId],
);
const agent = await this.agentRepo.findById(agentId);
if (agentResult.rows.length === 0) {
if (agent === null) {
throw new AgentNotFoundError(agentId);
}
const agentRow = agentResult.rows[0];
if (agentRow.organization_id !== tenantId) {
if (agent.organizationId !== tenantId) {
throw new AuthorizationError('You do not own this agent.');
}
// Fetch the agent's active credential client_id
const credResult = await this.pool.query<{ client_id: string }>(
`SELECT client_id FROM credentials WHERE agent_id = $1 AND status = 'active' ORDER BY created_at DESC LIMIT 1`,
[agentId],
);
const clientId =
credResult.rows.length > 0 ? credResult.rows[0].client_id : agentRow.agent_id;
const activeClientId = await this.credentialRepo.findActiveClientId(agentId);
const clientId = activeClientId ?? agentId;
const apiUrl = process.env['API_URL'] ?? process.env['NEXT_PUBLIC_API_URL'] ?? 'https://api.sentryagent.ai';
const { stream, filename } = await this.scaffoldService.generateScaffold({
agentId,
agentName: agentRow.email.split('@')[0] ?? agentId,
agentName: agent.email.split('@')[0] ?? agentId,
clientId,
language,
apiUrl,

View File

@@ -79,23 +79,23 @@ export function getPool(): Pool {
}
});
// Wrap pool.query to record duration in Prometheus.
// The pg Pool.query method is heavily overloaded — the only safe approach
// without TypeScript errors is a typed-any wrapper on the shim itself.
// We capture originalQuery as `(...args: any[]) => Promise<any>` to satisfy
// TypeScript's spread-into-rest constraint; this is the one sanctioned use of
// `any` in this file.
// eslint-disable-next-line @typescript-eslint/no-explicit-any
const originalQuery = pool.query.bind(pool) as (...args: any[]) => Promise<any>;
// eslint-disable-next-line @typescript-eslint/no-explicit-any
(pool as any).query = async (...args: any[]): Promise<any> => {
// Wrap pool.query to record Prometheus query duration.
// Uses unknown[] + Object.defineProperty to avoid `any` while preserving
// the pool's typed interface for all callers (TypeScript still sees Pool['query']).
const originalQuery = pool.query.bind(pool);
Object.defineProperty(pool, 'query', {
value: async (...args: unknown[]): Promise<unknown> => {
const end = dbQueryDurationSeconds.startTimer({ operation: 'query' });
try {
return await originalQuery(...args);
return await (originalQuery as (...a: unknown[]) => Promise<unknown>)(...args);
} finally {
end();
}
};
},
writable: true,
configurable: true,
enumerable: false,
});
}
return pool;
}

View File

@@ -129,8 +129,10 @@ export class AgentRepository {
/**
* Returns a paginated list of agents with optional filters.
* When `organizationId` is provided the result set is strictly scoped to that
* organization — agents belonging to other organizations are never returned.
*
* @param filters - Pagination and filter criteria.
* @param filters - Pagination and filter criteria (organizationId is applied first).
* @returns Object containing the agent list and total count.
*/
async findAll(filters: IAgentListFilters): Promise<{ agents: IAgent[]; total: number }> {
@@ -138,6 +140,11 @@ export class AgentRepository {
const params: unknown[] = [];
let paramIndex = 1;
if (filters.organizationId !== undefined) {
conditions.push(`organization_id = $${paramIndex++}`);
params.push(filters.organizationId);
}
if (filters.owner !== undefined) {
conditions.push(`owner = $${paramIndex++}`);
params.push(filters.owner);

View File

@@ -250,4 +250,18 @@ export class CredentialRepository {
);
return result.rowCount ?? 0;
}
/**
* Finds the client_id of the most recent active credential for an agent.
*
* @param agentId - The agent UUID.
* @returns The client_id string, or null if no active credential exists.
*/
async findActiveClientId(agentId: string): Promise<string | null> {
const result: QueryResult<{ client_id: string }> = await this.pool.query(
`SELECT client_id FROM credentials WHERE agent_id = $1 AND status = 'active' ORDER BY created_at DESC LIMIT 1`,
[agentId],
);
return result.rows.length > 0 ? (result.rows[0].client_id ?? null) : null;
}
}

View File

@@ -10,7 +10,7 @@
import { Router, Request, Response } from 'express';
import { Pool } from 'pg';
import { RedisClientType } from 'redis';
import { HealthDetailedController } from '../controllers/HealthDetailedController.js';
import { DbProbe, HealthDetailedController } from '../controllers/HealthDetailedController.js';
/** Response shape for GET /health */
interface HealthResponse {
@@ -33,9 +33,21 @@ interface HealthResponse {
export function createHealthRouter(pool: Pool, redis: RedisClientType): Router {
const router = Router();
// Create a minimal DbProbe adapter — keeps raw Pool out of the controller.
const dbProbe: DbProbe = {
async checkLiveness(): Promise<void> {
const client = await pool.connect();
try {
await client.query('SELECT 1');
} finally {
client.release();
}
},
};
// Instantiate the detailed health controller with optional service clients.
const detailedController = new HealthDetailedController({
pool,
dbProbe,
redisClient: redis,
vaultAddr: process.env['VAULT_ADDR'] ?? undefined,
opaUrl: process.env['OPA_URL'] ?? undefined,

View File

@@ -21,6 +21,7 @@ import {
AgentAlreadyExistsError,
AgentAlreadyDecommissionedError,
FreeTierLimitError,
AuthorizationError,
} from '../utils/errors.js';
import { agentsRegisteredTotal } from '../metrics/registry.js';
import { TierService } from './TierService.js';
@@ -140,16 +141,23 @@ export class AgentService {
/**
* Retrieves a single agent by its UUID.
* When `organizationId` is provided the agent's organization is verified — callers
* from a different organization receive an AuthorizationError (403).
*
* @param agentId - The agent UUID.
* @param organizationId - Optional. When present, the agent must belong to this org.
* @returns The agent record.
* @throws AgentNotFoundError if the agent does not exist.
* @throws AuthorizationError if the agent belongs to a different organization.
*/
async getAgentById(agentId: string): Promise<IAgent> {
async getAgentById(agentId: string, organizationId?: string): Promise<IAgent> {
const agent = await this.agentRepository.findById(agentId);
if (!agent) {
throw new AgentNotFoundError(agentId);
}
if (organizationId !== undefined && agent.organizationId !== organizationId) {
throw new AuthorizationError();
}
return agent;
}
@@ -173,14 +181,18 @@ export class AgentService {
* Partially updates an agent's metadata.
* Immutable fields (agentId, email, createdAt) cannot be changed.
* Decommissioned agents cannot be updated.
* When `organizationId` is provided the agent's organization is verified — callers
* from a different organization receive an AuthorizationError (403).
*
* @param agentId - The agent UUID to update.
* @param data - The fields to update.
* @param ipAddress - Client IP for audit logging.
* @param userAgent - Client User-Agent for audit logging.
* @param organizationId - Optional. When present, the agent must belong to this org.
* @returns The updated agent record.
* @throws AgentNotFoundError if the agent does not exist.
* @throws AgentAlreadyDecommissionedError if the agent is decommissioned.
* @throws AuthorizationError if the agent belongs to a different organization.
* @throws ValidationError if immutable fields are included.
*/
async updateAgent(
@@ -188,12 +200,17 @@ export class AgentService {
data: IUpdateAgentRequest,
ipAddress: string,
userAgent: string,
organizationId?: string,
): Promise<IAgent> {
const agent = await this.agentRepository.findById(agentId);
if (!agent) {
throw new AgentNotFoundError(agentId);
}
if (organizationId !== undefined && agent.organizationId !== organizationId) {
throw new AuthorizationError();
}
if (agent.status === 'decommissioned') {
throw new AgentAlreadyDecommissionedError(agentId);
}
@@ -256,23 +273,32 @@ export class AgentService {
/**
* Permanently decommissions an agent (soft delete).
* Revokes all active credentials for the agent.
* When `organizationId` is provided the agent's organization is verified — callers
* from a different organization receive an AuthorizationError (403).
*
* @param agentId - The agent UUID to decommission.
* @param ipAddress - Client IP for audit logging.
* @param userAgent - Client User-Agent for audit logging.
* @param organizationId - Optional. When present, the agent must belong to this org.
* @throws AgentNotFoundError if the agent does not exist.
* @throws AgentAlreadyDecommissionedError if already decommissioned.
* @throws AuthorizationError if the agent belongs to a different organization.
*/
async decommissionAgent(
agentId: string,
ipAddress: string,
userAgent: string,
organizationId?: string,
): Promise<void> {
const agent = await this.agentRepository.findById(agentId);
if (!agent) {
throw new AgentNotFoundError(agentId);
}
if (organizationId !== undefined && agent.organizationId !== organizationId) {
throw new AuthorizationError();
}
if (agent.status === 'decommissioned') {
throw new AgentAlreadyDecommissionedError(agentId);
}

View File

@@ -170,6 +170,8 @@ export interface IPaginatedAgentsResponse {
/** Query filters for listing agents. */
export interface IAgentListFilters {
/** Restricts results to agents belonging to this organization. Enforced by the controller from the JWT claim. */
organizationId?: string;
owner?: string;
agentType?: AgentType;
status?: AgentStatus;

View File

@@ -0,0 +1,148 @@
/**
* Integration tests for Analytics endpoints.
* Uses a real Postgres test DB and Redis test instance.
*
* Routes covered:
* GET /api/v1/analytics/tokens — daily token issuance trend
* GET /api/v1/analytics/agents/activity — agent activity heatmap
* GET /api/v1/analytics/agents — per-agent usage summary
*/
import crypto from 'crypto';
import request from 'supertest';
import { Application } from 'express';
import { v4 as uuidv4 } from 'uuid';
import { Pool } from 'pg';
const { privateKey, publicKey } = crypto.generateKeyPairSync('rsa', {
modulusLength: 2048,
publicKeyEncoding: { type: 'spki', format: 'pem' },
privateKeyEncoding: { type: 'pkcs8', format: 'pem' },
});
process.env['DATABASE_URL'] =
process.env['TEST_DATABASE_URL'] ??
'postgresql://sentryagent:sentryagent@localhost:5432/sentryagent_idp_test';
process.env['REDIS_URL'] = process.env['TEST_REDIS_URL'] ?? 'redis://localhost:6379/1';
process.env['JWT_PRIVATE_KEY'] = privateKey;
process.env['JWT_PUBLIC_KEY'] = publicKey;
process.env['NODE_ENV'] = 'test';
process.env['DEFAULT_ORG_ID'] = 'org_system';
process.env['ANALYTICS_ENABLED'] = 'true';
import { createApp } from '../../src/app';
import { signToken } from '../../src/utils/jwt';
import { closePool } from '../../src/db/pool';
import { closeRedisClient } from '../../src/cache/redis';
const ORG_ID = uuidv4();
const AGENT_ID = uuidv4();
const SCOPE = 'analytics:read';
function makeToken(sub: string = AGENT_ID, scope: string = SCOPE, orgId: string = ORG_ID): string {
return signToken({ sub, client_id: sub, scope, organization_id: orgId, jti: uuidv4() }, privateKey);
}
describe('Analytics Endpoints Integration Tests', () => {
let app: Application;
let pool: Pool;
beforeAll(async () => {
app = await createApp();
pool = new Pool({ connectionString: process.env['DATABASE_URL'] });
await pool.query(`
CREATE TABLE IF NOT EXISTS organizations (
organization_id VARCHAR(40) PRIMARY KEY,
name VARCHAR(100) NOT NULL,
plan VARCHAR(20) NOT NULL DEFAULT 'free',
created_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),
updated_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
)
`);
await pool.query(`
CREATE TABLE IF NOT EXISTS analytics_events (
id BIGSERIAL PRIMARY KEY,
tenant_id VARCHAR(40) NOT NULL,
date DATE NOT NULL,
metric_type VARCHAR(50) NOT NULL,
count INTEGER NOT NULL DEFAULT 1,
UNIQUE(tenant_id, date, metric_type)
)
`);
await pool.query(
`INSERT INTO organizations (organization_id, name) VALUES ($1, $2) ON CONFLICT DO NOTHING`,
[ORG_ID, 'Test Analytics Org'],
);
});
afterAll(async () => {
await pool.query(`DELETE FROM analytics_events WHERE tenant_id = $1`, [ORG_ID]);
await pool.query(`DELETE FROM organizations WHERE organization_id = $1`, [ORG_ID]);
await pool.end();
await closePool();
await closeRedisClient();
});
// ─── GET /analytics/tokens ──────────────────────────────────────────────────
describe('GET /api/v1/analytics/tokens', () => {
it('should return 200 with token trend data', async () => {
const res = await request(app)
.get('/api/v1/analytics/tokens')
.set('Authorization', `Bearer ${makeToken()}`);
expect(res.status).toBe(200);
expect(Array.isArray(res.body)).toBe(true);
});
it('should return 401 when no token provided', async () => {
const res = await request(app).get('/api/v1/analytics/tokens');
expect(res.status).toBe(401);
});
it('should accept a ?days= query parameter', async () => {
const res = await request(app)
.get('/api/v1/analytics/tokens?days=7')
.set('Authorization', `Bearer ${makeToken()}`);
expect(res.status).toBe(200);
});
});
// ─── GET /analytics/agents/activity ─────────────────────────────────────────
describe('GET /api/v1/analytics/agents/activity', () => {
it('should return 200 with activity data', async () => {
const res = await request(app)
.get('/api/v1/analytics/agents/activity')
.set('Authorization', `Bearer ${makeToken()}`);
expect(res.status).toBe(200);
});
it('should return 401 when no token provided', async () => {
const res = await request(app).get('/api/v1/analytics/agents/activity');
expect(res.status).toBe(401);
});
});
// ─── GET /analytics/agents ───────────────────────────────────────────────────
describe('GET /api/v1/analytics/agents', () => {
it('should return 200 with agent usage summary', async () => {
const res = await request(app)
.get('/api/v1/analytics/agents')
.set('Authorization', `Bearer ${makeToken()}`);
expect(res.status).toBe(200);
});
it('should return 401 when no token provided', async () => {
const res = await request(app).get('/api/v1/analytics/agents');
expect(res.status).toBe(401);
});
});
});

Some files were not shown because too many files have changed in this diff Show More