fix template, remove okr, use casan.*
This commit is contained in:
thanhnv
@@ -26,10 +26,10 @@ REJECTED verdict received
|
||||
|
||||
| Gate Step | Review Agent | Fix Agent | Fix Instruction |
|
||||
|-----------|-------------|-----------|-----------------|
|
||||
| Step 5 | `okr.reviewspec` | `speckit.specify` | "Fix CRITICAL spec issues: <list>. Re-generate affected sections of spec.md." |
|
||||
| Step 7 | `okr.reviewplan` | `speckit.plan` | "Fix CRITICAL plan conformance issues: <list>. Update plan.md." |
|
||||
| Step 11 | `okr.reviewcode` | `speckit.implement` | "Fix CRITICAL code review issues: <list>. Apply minimal targeted fixes." |
|
||||
| Step 12 | `okr.testkit` | `speckit.implement` | "Fix CRITICAL test failures tracing to SRS/BD/DD: <failed test list>." |
|
||||
| Step 5 | `casan.reviewspec` | `speckit.specify` | "Fix CRITICAL spec issues: <list>. Re-generate affected sections of spec.md." |
|
||||
| Step 7 | `casan.reviewplan` | `speckit.plan` | "Fix CRITICAL plan conformance issues: <list>. Update plan.md." |
|
||||
| Step 11 | `casan.reviewcode` | `speckit.implement` | "Fix CRITICAL code review issues: <list>. Apply minimal targeted fixes." |
|
||||
| Step 12 | `casan.testkit` | `speckit.implement` | "Fix CRITICAL test failures tracing to SRS/BD/DD: <failed test list>." |
|
||||
|
||||
## BACK-TO-PLAN Fix Cycle (Step 12 only)
|
||||
|
||||
|
||||
@@ -1,21 +1,9 @@
|
||||
# Giao thức Kiểm soát Ảo giác (Hallucination Prevention Checklist)
|
||||
# Hallucination Prevention Checklist
|
||||
|
||||
Giao thức này cung cấp bộ checklist bắt buộc để các Review Agents và bản thân Sub-agents đối chiếu chéo kết quả nhằm triệt tiêu hoàn toàn hiện tượng ảo giác (hallucination).
|
||||
|
||||
## 1. Nguyên lý đối chiếu chéo (Grounding)
|
||||
- Không có bất kỳ chi tiết thiết kế hoặc logic code nào được phép tự ý phát minh nếu không có cơ sở chứng cứ rõ ràng từ:
|
||||
- Tài liệu Yêu cầu nghiệp vụ (`apps/okr/domain/input/okr-requirement.md`).
|
||||
- Bản vẽ thiết kế Basic Design (`bd-*.md`) hoặc Detail Design (`dd-*.md`).
|
||||
- Tệp thông tin Context hiện tại (`pipeline-context.yaml`).
|
||||
|
||||
## 2. Checklist rà soát chất lượng (Hallucination Checks)
|
||||
Trước khi đánh dấu một bước là hoàn thành, Agent phải tự xác nhận qua checklist sau:
|
||||
|
||||
- [ ] **Sự nhất quán dữ liệu (Data Conformance):** Các kiểu dữ liệu, các bảng và trường thông tin trong code có khớp 100% với file `data-model.md` và `plan.md` không?
|
||||
- [ ] **Xác thực đường dẫn (Path Verification):** Mọi đường dẫn file được tham chiếu trong spec/plan/tasks có tồn tại vật lý trên đĩa hoặc được định nghĩa trong context không? (Tuyệt đối không đoán đường dẫn).
|
||||
- [ ] **Độ phủ yêu cầu (Requirement Coverage):** Tất cả các câu trả lời và dòng code có giải quyết đúng mục tiêu nghiệp vụ được giao không? Có thêm thắt tính năng dư thừa ngoài đặc tả (Feature Creep) không?
|
||||
- [ ] **Độ chính xác của API/Contract:** Các endpoint, headers, và payload API trong frontend và backend có khớp nhau hoàn toàn theo mô tả trong `contracts/` không?
|
||||
|
||||
## 3. Quy trình phản biện (Judge Gate)
|
||||
- Khi Review Agent thực hiện đánh giá (Step 5, 7, 11), nếu phát hiện bất kỳ điểm nào không nhất quán hoặc tự ý sáng tạo không có căn cứ, Review Agent phải từ chối phê duyệt với verdict `REJECTED`.
|
||||
- Phải liệt kê cụ thể các điểm nghi ngờ ảo giác vào mục `critical-issues` trong Step-Result block để fix agent thực hiện điều chỉnh.
|
||||
- [ ] Exactly one project manifest is selected and valid.
|
||||
- [ ] Requirement, architecture, quality profile, and relevant generated artifacts were read.
|
||||
- [ ] Every product behavior, entity, role, endpoint, screen, and validation rule cites a source ID.
|
||||
- [ ] No shared CASAN file contains project-specific assumptions.
|
||||
- [ ] No dependency, path, command, source root, or deployment target was invented.
|
||||
- [ ] Build/test commands equal manifest argv arrays and matched verification rules ran.
|
||||
- [ ] Missing or contradictory evidence produces REJECTED/blocked, never an inferred answer.
|
||||
|
||||
@@ -1,95 +1,7 @@
|
||||
# Common Delegation Block for speckit.implement
|
||||
|
||||
This delegation block is used by the Boss when invoking `speckit.implement` in Step 10.
|
||||
Sub-agent already knows its own workflow — Boss only passes **step-specific context**.
|
||||
|
||||
## Standard Context (always included)
|
||||
|
||||
```yaml
|
||||
feature-id: <feature-id>
|
||||
module-id: <mod-id>
|
||||
report-nn: <NN>
|
||||
report-phase: <phase-name>
|
||||
pipeline-context: docs/output/output_logs/<feature-id>/pipeline-context.yaml
|
||||
mode: autonomous
|
||||
language: Vietnamese
|
||||
```
|
||||
|
||||
## Real Execution Mandate
|
||||
|
||||
ALL terminal commands MUST be executed via the `run` tool with real output captured.
|
||||
|
||||
- **PROHIBITED:** Documenting commands without executing, mock output, skipping npm commands.
|
||||
- **REQUIRED:** Use `get_errors` after every code edit to verify compile/lint errors are resolved.
|
||||
- **REQUIRED:** For frontend under `frontend/`, run `npm install` if `node_modules/` does not exist.
|
||||
|
||||
## ⛔ Portable Database Schema Rules (Post-Mortem P-02, P-05)
|
||||
|
||||
When generating Prisma schema:
|
||||
|
||||
1. **Do NOT use `enum` in schema.prisma** — SQLite does not support enums. Use `String` type with `@default("VALUE")` instead.
|
||||
2. **Do NOT use `@db.VarChar()`, `@db.Text`, or any provider-specific annotations** — these break when switching providers.
|
||||
3. **Create `backend/src/common/types/domain-enums.ts`** with TypeScript `const` arrays + derived types for all domain enumerations:
|
||||
```ts
|
||||
export const ROLES = ['ADMIN', 'MANAGER', 'EMPLOYEE'] as const;
|
||||
export type Role = (typeof ROLES)[number];
|
||||
```
|
||||
4. **Import enums from `domain-enums.ts`**, NEVER from `@prisma/client` enum types.
|
||||
5. **Use `provider = "sqlite"` as default** for local dev. Only switch to MySQL/PostgreSQL when Docker is confirmed available.
|
||||
|
||||
## ⛔ Mandatory .env File Creation (Post-Mortem P-03)
|
||||
|
||||
During Step 10 implementation, the agent MUST:
|
||||
|
||||
1. **Create `backend/.env`** with at minimum:
|
||||
```
|
||||
DATABASE_URL="file:./dev.db"
|
||||
JWT_SECRET=<random-generated-secret>
|
||||
JWT_REFRESH_SECRET=<random-generated-secret>
|
||||
PORT=3000
|
||||
```
|
||||
2. **Create `backend/.env.example`** (same keys, placeholder values) for documentation.
|
||||
3. **NEVER hardcode JWT secrets, database URLs, or API keys in source code.** All secrets MUST be read from `process.env`.
|
||||
4. Add `.env` to `.gitignore` (but NOT `.env.example`).
|
||||
|
||||
## ⛔ Security: Secrets Management (Post-Mortem P-09)
|
||||
|
||||
- JWT_SECRET, JWT_REFRESH_SECRET, DATABASE_URL → **env-only, NEVER in source files**
|
||||
- Use `@nestjs/config` `ConfigService` or `process.env` to read secrets at runtime
|
||||
- If `technical_architecture.md` says "hardcoded (workshop)" → OVERRIDE: still use env vars. Security trumps convenience.
|
||||
|
||||
## ⛔ React Frontend Quality Rules (Post-Mortem P-06, P-07)
|
||||
|
||||
1. **React Router future flags:** When using React Router DOM v6, ALWAYS add future flags to `<BrowserRouter>`:
|
||||
```tsx
|
||||
<BrowserRouter future={{ v7_startTransition: true, v7_relativeSplatPath: true }}>
|
||||
```
|
||||
2. **NEVER call `navigate()` during render.** Use `<Navigate to="..." replace />` component for conditional redirects in render body.
|
||||
3. **ADMIN role queries:** When implementing list/dashboard endpoints, ADMIN role MUST see ALL records (not filtered by `ownerId`). Add role-based query logic:
|
||||
```ts
|
||||
const where = user.role === 'ADMIN' ? {} : { ownerId: user.id };
|
||||
```
|
||||
|
||||
## Step-Specific Additional Instructions
|
||||
|
||||
### STEP 10 — Implementation + Build & Fix
|
||||
```
|
||||
Phase 1 — Implement:
|
||||
Execute all tasks in specs/<feature-id>/tasks.md phase by phase.
|
||||
Track every file created/modified in the report's Artifacts section.
|
||||
|
||||
Phase 2 — Build & Fix:
|
||||
Build the application and fix all compile/runtime errors. Do NOT launch the screen.
|
||||
Execute in order:
|
||||
1. Fix all compile/lint errors (get_errors → fix → repeat until zero)
|
||||
2. Build frontend: cd frontend && npm install && npm run build
|
||||
3. Start Docker (if docker-compose.dev.yml exists): docker compose -f docker/docker-compose.dev.yml up -d
|
||||
4. Build backend: cd backend && npm install && npm run build
|
||||
5. Verify startup (if Docker available): cd backend && npm run start:dev
|
||||
```
|
||||
|
||||
## UI Layout Convention (for frontend work)
|
||||
|
||||
> Read `docs/technical_architecture.md §IV` for all UI layout rules.
|
||||
> Shared components: `AppLayout.jsx`, `SystemHeader.jsx`, `ModuleNav.jsx` under `frontend/src/components/shared/`
|
||||
> Create if not exist, reuse if they do. Wrap ALL page components in `<AppLayout>`.
|
||||
# Implementation Scope Protocol
|
||||
|
||||
The selected manifest is the write boundary. Parallel implementation is allowed only for disjoint
|
||||
declared source roots with explicit ownership and no shared-file overlap. Each worker receives the
|
||||
same manifest hash, requirement IDs, architecture, plan/tasks, and quality profile. Workers may not
|
||||
install unapproved dependencies, create secrets, weaken gates, or write outside scope. Merge only
|
||||
after manifest build/test and every matching verification rule pass together.
|
||||
|
||||
@@ -1,149 +1,7 @@
|
||||
# Pipeline Context File
|
||||
|
||||
The Boss maintains a running context file updated after each step.
|
||||
Sub-agents read this file instead of re-reading large source files.
|
||||
|
||||
## Path
|
||||
|
||||
```
|
||||
docs/output/output_logs/<feature-id>/pipeline-context.yaml
|
||||
```
|
||||
|
||||
## Schema
|
||||
|
||||
```yaml
|
||||
# --- Immutable (set at STEP 0) ---
|
||||
feature-id: <feature-id>
|
||||
module-id: <mod-id> # e.g. mod01
|
||||
module-keyword: <keyword> # e.g. OKR
|
||||
module-short-name: <short-name> # e.g. xxx
|
||||
mode: autonomous
|
||||
language: Vietnamese
|
||||
|
||||
# --- Tech stack summary (extracted once from docs/technical_architecture.md) ---
|
||||
tech-stack:
|
||||
backend: "NestJS 10, Node.js 22, TypeScript 5"
|
||||
frontend: "React 18.3, Vite 6.0"
|
||||
db: "PostgreSQL 17"
|
||||
cache: "Redis 7.4"
|
||||
css: "Bootstrap 5 (utility classes only)"
|
||||
|
||||
# --- Updated after each step ---
|
||||
casan-harness:
|
||||
level-target: 5
|
||||
h4-security:
|
||||
policy: packages/casan-harness/security/prompt-filter.yaml
|
||||
output-policy: packages/casan-harness/security/output-policy.yaml
|
||||
audit-log: .specify/logs/audit/security.jsonl
|
||||
h5-governance:
|
||||
approval-flow: packages/casan-harness/governance/approval-flow.yaml
|
||||
risk-registry: packages/casan-harness/governance/risk-registry.yaml
|
||||
audit-log: .specify/logs/audit/audit.jsonl
|
||||
h6-agentops:
|
||||
metrics-policy: .specify/agentops/metrics.yaml
|
||||
metrics-log: .specify/logs/cost/metrics.jsonl
|
||||
alert-log: .specify/agentops/alerts.log
|
||||
h2-tool-registry:
|
||||
registry: packages/casan-harness/level5/tool-registry.yaml
|
||||
audit-log: .specify/logs/level5/tool-registry.jsonl
|
||||
h7-drift:
|
||||
golden-dir: apps/okr/domain/golden-runs/
|
||||
drift-log: .specify/logs/level5/drift.jsonl
|
||||
rollback:
|
||||
transactions-log: .specify/logs/level5/rollback-transactions.jsonl
|
||||
steps:
|
||||
step-0:
|
||||
status: COMPLETE
|
||||
pipeline-mode: UPDATE | CREATE
|
||||
casan:
|
||||
h4-trace: .specify/logs/trace/security-<trace-id>.json
|
||||
h4-verdict: PASS | BLOCKED # PASS = clean, BLOCKED = security violation detected
|
||||
h5-trace: .specify/logs/trace/governance-<trace-id>.json
|
||||
h5-verdict: APPROVED | DENIED # APPROVED = governance ok, DENIED = policy/approval rejected
|
||||
h6-trace: .specify/logs/trace/agentops-<trace-id>.json
|
||||
h6-verdict: OK | ALERT # OK = metrics normal, ALERT = threshold breached
|
||||
step-1-srs:
|
||||
status: COMPLETE | SKIPPED | FAILED
|
||||
path: docs/output/ipa-docs/srs/srs-<mod-id>-<short-name>.md
|
||||
report: docs/output/output_logs/<feature-id>/reports/01-srs-report.md
|
||||
fea-count: <N>
|
||||
tbc-count: <N>
|
||||
step-2-bd:
|
||||
status: COMPLETE
|
||||
path: docs/output/ipa-docs/bd/bd-<mod-id>-<short-name>.md
|
||||
report: docs/output/output_logs/<feature-id>/reports/02-bd-report.md
|
||||
screen-count: <N>
|
||||
step-3-spec:
|
||||
status: COMPLETE
|
||||
path: docs/output/specs/<feature-id>/spec.md
|
||||
report: docs/output/output_logs/<feature-id>/reports/03-specify-report.md
|
||||
branch: <branch-name>
|
||||
step-4-clarify:
|
||||
status: COMPLETE
|
||||
qa-path: docs/output/output_logs/<feature-id>/reports/04-clarify-qa.md
|
||||
report: docs/output/output_logs/<feature-id>/reports/04-clarify-report.md
|
||||
tbc-resolved: <N>
|
||||
step-5-review-spec:
|
||||
status: COMPLETE
|
||||
verdict: APPROVED | APPROVED_WITH_CONDITIONS | REJECTED
|
||||
report: docs/output/output_logs/<feature-id>/reports/05-review-spec-report.md
|
||||
retries: <N>
|
||||
step-6-plan:
|
||||
status: COMPLETE
|
||||
path: docs/output/specs/<feature-id>/plan.md
|
||||
data-model: docs/output/specs/<feature-id>/data-model.md
|
||||
contracts: docs/output/specs/<feature-id>/contracts/
|
||||
report: docs/output/output_logs/<feature-id>/reports/06-plan-report.md
|
||||
step-7-review-plan:
|
||||
status: COMPLETE
|
||||
verdict: APPROVED
|
||||
report: docs/output/output_logs/<feature-id>/reports/07-review-plan-report.md
|
||||
retries: <N>
|
||||
step-8-dd:
|
||||
status: COMPLETE
|
||||
path: docs/output/ipa-docs/dd/dd-<mod-id>-<short-name>.md
|
||||
report: docs/output/output_logs/<feature-id>/reports/08-dd-report.md
|
||||
step-8b-testcases:
|
||||
status: COMPLETE
|
||||
path: docs/output/ipa-docs/testcase/testcase-<mod-id>-<short-name>.md
|
||||
report: docs/output/output_logs/<feature-id>/reports/08b-testcases-report.md
|
||||
step-9-tasks:
|
||||
status: COMPLETE
|
||||
path: docs/output/specs/<feature-id>/tasks.md
|
||||
report: docs/output/output_logs/<feature-id>/reports/09-tasks-report.md
|
||||
step-10-implement:
|
||||
status: COMPLETE
|
||||
report: docs/output/output_logs/<feature-id>/reports/10-implement-report.md
|
||||
retries: <N>
|
||||
step-11-review-code:
|
||||
status: COMPLETE
|
||||
verdict: APPROVED
|
||||
report: docs/output/output_logs/<feature-id>/reports/11-review-code-report.md
|
||||
retries: <N>
|
||||
step-12-testkit:
|
||||
status: COMPLETE
|
||||
verdict: PASS | FAIL
|
||||
report: docs/output/output_logs/<feature-id>/reports/12-testkit-report.md
|
||||
ipa-report: docs/output/ipa-docs/testreport/testreport-<mod-id>-<short-name>.md
|
||||
back-to-plan-cycles: <N>
|
||||
step-13-launch:
|
||||
status: COMPLETE
|
||||
fe-url: "http://localhost:5173"
|
||||
be-url: "http://localhost:8081"
|
||||
report: docs/output/output_logs/<feature-id>/reports/13-launch-report.md
|
||||
```
|
||||
|
||||
## Boss Update Rules
|
||||
|
||||
1. **After STEP 0**: Create file with immutable section + tech-stack (read from `docs/technical_architecture.md` once)
|
||||
2. **After each step**: Parse the sub-agent's `<!-- STEP-RESULT -->` block and update the corresponding `steps.step-N` section
|
||||
3. **After each CASAN gate**: Append H4/H5/H6 trace paths and status under the corresponding step's `casan` key
|
||||
4. **Before delegating**: Sub-agents receive the pipeline-context path in `$ARGUMENTS` and can read it for all prior step outputs
|
||||
|
||||
## Sub-Agent Read Rules
|
||||
|
||||
Sub-agents SHOULD read `pipeline-context.yaml` at startup to discover:
|
||||
- `feature-id`, `module-id`, `module-keyword` (no need to re-detect)
|
||||
- Artifact paths from prior steps (no need to guess)
|
||||
- Tech stack (no need to re-read `docs/technical_architecture.md` for basics)
|
||||
- CASAN harness evidence paths and policies for H4/H5/H6
|
||||
# Pipeline Context Contract
|
||||
|
||||
Each run records project ID, manifest path/hash, feature/module IDs, requirement and architecture
|
||||
paths/hashes, quality profile ID/hash, artifact namespace, source roots, current step, attempt,
|
||||
verdict, trace ID, model/provider metadata, argv command evidence, and rollback transaction where
|
||||
applicable. Context paths must be repository-relative and confined to the selected project or shared
|
||||
CASAN roots. A step may consume only artifacts from the same project/feature run.
|
||||
|
||||
@@ -1,96 +1,27 @@
|
||||
# Step Result Block — Handoff Contract
|
||||
|
||||
Every sub-agent MUST include a structured result block at the end of their response.
|
||||
The Boss parses this block to extract status, artifacts, and metrics without reading the full report.
|
||||
|
||||
## Format
|
||||
|
||||
```yaml
|
||||
<!-- STEP-RESULT
|
||||
step: <step-number>
|
||||
agent: <agent-name>
|
||||
status: SUCCESS | FAILED
|
||||
feature-id: <feature-id>
|
||||
module-id: <mod-id>
|
||||
artifacts:
|
||||
<key>: <file-path>
|
||||
metrics:
|
||||
<key>: <value>
|
||||
verdict: APPROVED | APPROVED_WITH_CONDITIONS | REJECTED | N/A
|
||||
critical-issues: []
|
||||
next-inputs:
|
||||
<key>: <file-path>
|
||||
/STEP-RESULT -->
|
||||
```
|
||||
|
||||
## Examples
|
||||
|
||||
### STEP 1 — okr.srs
|
||||
```yaml
|
||||
<!-- STEP-RESULT
|
||||
step: 1
|
||||
agent: okr.srs
|
||||
status: SUCCESS
|
||||
feature-id: 001-xxx
|
||||
module-id: mod01
|
||||
artifacts:
|
||||
srs: docs/output/ipa-docs/srs/srs-mod01-xxx.md
|
||||
report: docs/output/output_logs/001-xxx/reports/01-srs-report.md
|
||||
metrics:
|
||||
fea-count: 12
|
||||
tbc-count: 3
|
||||
verdict: N/A
|
||||
critical-issues: []
|
||||
next-inputs:
|
||||
srs-path: docs/output/ipa-docs/srs/srs-mod01-xxx.md
|
||||
/STEP-RESULT -->
|
||||
```
|
||||
|
||||
### STEP 5 — okr.reviewspec (with rejection)
|
||||
```yaml
|
||||
<!-- STEP-RESULT
|
||||
step: 5
|
||||
agent: okr.reviewspec
|
||||
status: SUCCESS
|
||||
feature-id: 001-xxx
|
||||
module-id: mod01
|
||||
artifacts:
|
||||
report: docs/output/output_logs/001-xxx/reports/05-review-spec-report.md
|
||||
metrics:
|
||||
critical-count: 2
|
||||
minor-count: 3
|
||||
verdict: REJECTED
|
||||
critical-issues:
|
||||
- "Missing BR-KR-002 boundary validation in spec §5"
|
||||
- "SCR-mod01-02 wireframe missing target field"
|
||||
next-inputs: {}
|
||||
/STEP-RESULT -->
|
||||
```
|
||||
|
||||
## Boss Parsing Rule
|
||||
|
||||
After each sub-agent returns, the Boss:
|
||||
1. Extracts `<!-- STEP-RESULT ... /STEP-RESULT -->` block
|
||||
2. Parses YAML content
|
||||
3. **ARTIFACT VERIFICATION (mandatory before step-3):** For every path listed under `artifacts:`, use the `Glob` tool to confirm the file exists on disk.
|
||||
- If ANY artifact file is missing → treat the step as **FAILED**, do NOT update pipeline-context.yaml with status: COMPLETE, and re-invoke the sub-agent with an explicit instruction to write the missing file(s).
|
||||
- Log: `[ARTIFACT GATE] STEP N — missing: <path>. Re-invoking agent.`
|
||||
4. Updates `pipeline-context.yaml` with artifacts and metrics — **only after step-3 passes**
|
||||
5. Checks `verdict` for gate decisions — no need to read the full report file
|
||||
6. If `critical-issues` is non-empty and verdict is REJECTED → invoke gate retry protocol
|
||||
|
||||
## Artifact Verification Table
|
||||
|
||||
Steps with primary artifacts that MUST be verified on disk:
|
||||
|
||||
| Step | Agent | Artifact key | Expected path pattern |
|
||||
|------|-------|--------------|-----------------------|
|
||||
| 1 | okr.srs | `srs` | `docs/output/ipa-docs/srs/srs-*.md` |
|
||||
| 2 | okr.bd | `bd` | `docs/output/ipa-docs/bd/bd-*.md` |
|
||||
| 3 | speckit.specify | `spec` | `specs/*/spec.md` |
|
||||
| 6 | speckit.plan | `plan` | `specs/*/plan.md` |
|
||||
| 8 | okr.dd | `dd` | `docs/output/ipa-docs/dd/dd-*.md` |
|
||||
| 8b | okr.testkit | `testcases` | `docs/output/ipa-docs/testcase/testcase-*.md` |
|
||||
| 9 | speckit.tasks | `tasks` | `specs/*/tasks.md` |
|
||||
|
||||
Review steps (5, 7, 11) and the launch step (13) produce reports only — no primary artifact to verify beyond the report file itself.
|
||||
# Step Result Contract
|
||||
|
||||
Every pipeline step writes a machine-readable terminal block:
|
||||
|
||||
```text
|
||||
<!-- STEP-RESULT
|
||||
project-id: <manifest project_id>
|
||||
feature-id: <manifest feature.id>
|
||||
manifest-sha256: <hash>
|
||||
status: COMPLETE|BLOCKED|ERROR
|
||||
verdict: APPROVED|REJECTED|PASS|FAIL
|
||||
artifacts:
|
||||
- <repository-relative path>
|
||||
critical-issues:
|
||||
- none|<issue>
|
||||
commands:
|
||||
- <JSON argv + exit code>
|
||||
/STEP-RESULT -->
|
||||
```
|
||||
|
||||
Paths must be inside the manifest artifact namespace or source roots. A consumer rejects blocks
|
||||
whose project, feature, manifest hash, artifact path, or trace/run identity does not match current
|
||||
context. Missing verdict/evidence is an error, never implicit approval.
|
||||
|
||||
Agent mapping: SRS `casan.srs`; BD `casan.bd`; spec/plan/tasks/implementation `speckit.*`;
|
||||
reviews `casan.reviewspec`, `casan.reviewplan`, `casan.reviewcode`; DD `casan.dd`; tests
|
||||
`casan.testkit`; orchestration `casan.pipeline`.
|
||||
|
||||
@@ -4,7 +4,7 @@ Giao thức này quy định danh sách trắng các công cụ và câu lệnh
|
||||
|
||||
## 1. Danh sách trắng công cụ (Tool Whitelist per Agent)
|
||||
|
||||
### A. Boss Orchestrator (okr.bossbuiltin)
|
||||
### A. Boss Orchestrator (casan.pipeline)
|
||||
Được phép điều phối và chạy toàn bộ các chuỗi công cụ chuẩn bị và kiểm thử:
|
||||
- `Read`, `Write`, `Edit`, `Glob`, `Grep` (IDE Tools)
|
||||
- Các script hỗ trợ: `packages/casan-harness/scripts/bash/casan-harness.sh`, `security-check.sh`, `governance-check.sh`, `agent-metrics.sh`
|
||||
@@ -18,10 +18,10 @@ Chỉ được phép làm việc trên các tệp tin tài liệu (Read-only on
|
||||
|
||||
### C. Implementation Agent (speckit.implement)
|
||||
Được quyền viết code và tự động xác minh lỗi:
|
||||
- `Read`, `Write`, `Edit` (trên toàn bộ workspace bao gồm `backend/`, `frontend/`)
|
||||
- `Read` within selected manifest context roots; `Write`/`Edit` only within its declared source roots and artifact namespace
|
||||
- `Bash` (chỉ giới hạn cho các lệnh: `npm install`, `npm run build`, `npm test`, `npx prisma`, `git diff`)
|
||||
|
||||
### D. Testing & Quality Agent (okr.testkit, okr.reviewcode)
|
||||
### D. Testing & Quality Agent (casan.testkit, casan.reviewcode)
|
||||
Được quyền chạy kiểm thử và review:
|
||||
- `Read` (toàn bộ workspace)
|
||||
- `Bash` (chỉ chạy lệnh kiểm thử: `npm test`, `npm run test:cov`, `jest`, `mocha`)
|
||||
|
||||
Reference in New Issue
Block a user