sagaz-ai 0.1.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/INSTALL.md +78 -0
- package/LICENSE +21 -0
- package/README.md +185 -0
- package/ai-orchestration-ecosystem/ACTIVATE.md +45 -0
- package/ai-orchestration-ecosystem/INDEX.md +73 -0
- package/ai-orchestration-ecosystem/README.md +31 -0
- package/ai-orchestration-ecosystem/agents/design-director.md +20 -0
- package/ai-orchestration-ecosystem/agents/implementation-engineer.md +21 -0
- package/ai-orchestration-ecosystem/agents/orchestrator.md +22 -0
- package/ai-orchestration-ecosystem/agents/product-strategist.md +22 -0
- package/ai-orchestration-ecosystem/agents/qa-verifier.md +23 -0
- package/ai-orchestration-ecosystem/agents/refactor-steward.md +20 -0
- package/ai-orchestration-ecosystem/agents/security-governance.md +21 -0
- package/ai-orchestration-ecosystem/agents/software-architect.md +21 -0
- package/ai-orchestration-ecosystem/agents/specification-writer.md +21 -0
- package/ai-orchestration-ecosystem/agents/technology-strategist.md +21 -0
- package/ai-orchestration-ecosystem/agents/ui-systems-designer.md +20 -0
- package/ai-orchestration-ecosystem/agents/ux-architect.md +21 -0
- package/ai-orchestration-ecosystem/agents/visual-qa.md +20 -0
- package/ai-orchestration-ecosystem/core/decision-records.md +25 -0
- package/ai-orchestration-ecosystem/core/operating-system.md +29 -0
- package/ai-orchestration-ecosystem/core/token-economy.md +15 -0
- package/ai-orchestration-ecosystem/engineering/software-engineering-deep-guide.md +23 -0
- package/ai-orchestration-ecosystem/governance/ecosystem-maintenance.md +13 -0
- package/ai-orchestration-ecosystem/governance/package-release-policy.md +51 -0
- package/ai-orchestration-ecosystem/governance/quality-policy.md +13 -0
- package/ai-orchestration-ecosystem/governance/security-policy.md +13 -0
- package/ai-orchestration-ecosystem/governance/versioning.md +13 -0
- package/ai-orchestration-ecosystem/protocols/accessibility-compliance.md +39 -0
- package/ai-orchestration-ecosystem/protocols/ai-application-quality.md +40 -0
- package/ai-orchestration-ecosystem/protocols/api-contracts.md +37 -0
- package/ai-orchestration-ecosystem/protocols/architecture-fitness-functions.md +36 -0
- package/ai-orchestration-ecosystem/protocols/ci-cd-readiness.md +32 -0
- package/ai-orchestration-ecosystem/protocols/communication.md +32 -0
- package/ai-orchestration-ecosystem/protocols/data-privacy-lifecycle.md +38 -0
- package/ai-orchestration-ecosystem/protocols/database-migrations.md +36 -0
- package/ai-orchestration-ecosystem/protocols/delegation.md +32 -0
- package/ai-orchestration-ecosystem/protocols/dependency-governance.md +36 -0
- package/ai-orchestration-ecosystem/protocols/design-quality.md +32 -0
- package/ai-orchestration-ecosystem/protocols/dora-metrics.md +36 -0
- package/ai-orchestration-ecosystem/protocols/github-operations.md +32 -0
- package/ai-orchestration-ecosystem/protocols/guided-proactivity.md +32 -0
- package/ai-orchestration-ecosystem/protocols/memory.md +32 -0
- package/ai-orchestration-ecosystem/protocols/model-routing.md +32 -0
- package/ai-orchestration-ecosystem/protocols/performance-budgets.md +41 -0
- package/ai-orchestration-ecosystem/protocols/post-delivery-monitoring.md +32 -0
- package/ai-orchestration-ecosystem/protocols/production-readiness.md +32 -0
- package/ai-orchestration-ecosystem/protocols/quality-gates.md +32 -0
- package/ai-orchestration-ecosystem/protocols/release-strategy.md +38 -0
- package/ai-orchestration-ecosystem/protocols/secure-sdlc.md +38 -0
- package/ai-orchestration-ecosystem/protocols/squad-pipeline-handoffs.md +32 -0
- package/ai-orchestration-ecosystem/protocols/sre-readiness.md +41 -0
- package/ai-orchestration-ecosystem/protocols/stack-selection.md +32 -0
- package/ai-orchestration-ecosystem/protocols/testing-matrix.md +32 -0
- package/ai-orchestration-ecosystem/quickstart.md +25 -0
- package/ai-orchestration-ecosystem/skills/exhaustive-verification.md +14 -0
- package/ai-orchestration-ecosystem/skills/refactor-proofing.md +14 -0
- package/ai-orchestration-ecosystem/skills/spec-first-development.md +14 -0
- package/ai-orchestration-ecosystem/squads/code-audit.md +45 -0
- package/ai-orchestration-ecosystem/squads/design-studio.md +45 -0
- package/ai-orchestration-ecosystem/squads/github-ops.md +45 -0
- package/ai-orchestration-ecosystem/squads/maintenance-ops.md +45 -0
- package/ai-orchestration-ecosystem/squads/mobile-app-studio.md +45 -0
- package/ai-orchestration-ecosystem/squads/product-factory.md +45 -0
- package/ai-orchestration-ecosystem/squads/production-critical.md +45 -0
- package/ai-orchestration-ecosystem/squads/refactor-lab.md +45 -0
- package/ai-orchestration-ecosystem/squads/research-to-spec.md +45 -0
- package/ai-orchestration-ecosystem/tasks/design-system.md +34 -0
- package/ai-orchestration-ecosystem/tasks/github-release-ops.md +34 -0
- package/ai-orchestration-ecosystem/tasks/implementation-build.md +34 -0
- package/ai-orchestration-ecosystem/tasks/intake-brief.md +34 -0
- package/ai-orchestration-ecosystem/tasks/product-requirements.md +34 -0
- package/ai-orchestration-ecosystem/tasks/production-readiness.md +34 -0
- package/ai-orchestration-ecosystem/tasks/stack-recommendation.md +34 -0
- package/ai-orchestration-ecosystem/tasks/verification-qa.md +34 -0
- package/ai-orchestration-ecosystem/templates/design-system-spec.md +20 -0
- package/ai-orchestration-ecosystem/templates/final-handoff.md +20 -0
- package/ai-orchestration-ecosystem/templates/github-actions-checklist.md +20 -0
- package/ai-orchestration-ecosystem/templates/implementation-plan.md +20 -0
- package/ai-orchestration-ecosystem/templates/mobile-release-checklist.md +20 -0
- package/ai-orchestration-ecosystem/templates/product-spec.md +20 -0
- package/ai-orchestration-ecosystem/templates/qa-report.md +20 -0
- package/ai-orchestration-ecosystem/templates/run-state.md +20 -0
- package/ai-orchestration-ecosystem/templates/squad-handoff.md +20 -0
- package/ai-orchestration-ecosystem/templates/squad-runbook.md +20 -0
- package/ai-orchestration-ecosystem/templates/stack-recommendation.md +20 -0
- package/ai-orchestration-ecosystem/templates/task-brief.md +20 -0
- package/ai-orchestration-ecosystem/templates/technical-spec.md +20 -0
- package/ai-orchestration-ecosystem/workflows/brownfield-refactor-safe.md +25 -0
- package/ai-orchestration-ecosystem/workflows/bugfix-to-release.md +25 -0
- package/ai-orchestration-ecosystem/workflows/greenfield-web-app.md +25 -0
- package/ai-orchestration-ecosystem/workflows/mobile-app-production.md +36 -0
- package/ai-orchestration-ecosystem/workflows/web-production-release.md +39 -0
- package/bin/sagaz.js +107 -0
- package/codex-skill/sagaz/SKILL.md +69 -0
- package/package.json +42 -0
- package/scripts/verify-package.js +29 -0
|
@@ -0,0 +1,45 @@
|
|
|
1
|
+
# Squad: Github Ops
|
|
2
|
+
|
|
3
|
+
## Use
|
|
4
|
+
|
|
5
|
+
Use this squad when the task matches Github Ops.
|
|
6
|
+
|
|
7
|
+
## Agents
|
|
8
|
+
|
|
9
|
+
- Orchestrator
|
|
10
|
+
- Product Strategist when product decisions are needed
|
|
11
|
+
- Technology Strategist when stack or deployment decisions are needed
|
|
12
|
+
- Software Architect when architecture matters
|
|
13
|
+
- Design Studio roles when UI exists
|
|
14
|
+
- Implementation Engineer when code changes are needed
|
|
15
|
+
- QA Verifier for verification
|
|
16
|
+
- Security Governance when data, auth, secrets, payments, or production are involved
|
|
17
|
+
- GitHub Ops when versioning, PRs, releases, or checks are useful
|
|
18
|
+
|
|
19
|
+
## Flow
|
|
20
|
+
|
|
21
|
+
1. Confirm objective, constraints, definition of done, and risks.
|
|
22
|
+
2. Select relevant tasks and protocols.
|
|
23
|
+
3. Execute the phase in small verifiable steps.
|
|
24
|
+
4. Produce evidence and residual risks.
|
|
25
|
+
5. Ask permission before handing off to the next team.
|
|
26
|
+
|
|
27
|
+
## Required Gates
|
|
28
|
+
|
|
29
|
+
- Clear objective and definition of done.
|
|
30
|
+
- Relevant specification or task contract.
|
|
31
|
+
- Handoff approval between major phases.
|
|
32
|
+
- Verification evidence proportional to risk.
|
|
33
|
+
- Residual risks documented.
|
|
34
|
+
|
|
35
|
+
## Standard Output
|
|
36
|
+
|
|
37
|
+
```md
|
|
38
|
+
Scope:
|
|
39
|
+
Current phase:
|
|
40
|
+
Evidence:
|
|
41
|
+
Risks:
|
|
42
|
+
Next team:
|
|
43
|
+
Permission request:
|
|
44
|
+
```
|
|
45
|
+
|
|
@@ -0,0 +1,45 @@
|
|
|
1
|
+
# Squad: Maintenance Ops
|
|
2
|
+
|
|
3
|
+
## Use
|
|
4
|
+
|
|
5
|
+
Use this squad when the task matches Maintenance Ops.
|
|
6
|
+
|
|
7
|
+
## Agents
|
|
8
|
+
|
|
9
|
+
- Orchestrator
|
|
10
|
+
- Product Strategist when product decisions are needed
|
|
11
|
+
- Technology Strategist when stack or deployment decisions are needed
|
|
12
|
+
- Software Architect when architecture matters
|
|
13
|
+
- Design Studio roles when UI exists
|
|
14
|
+
- Implementation Engineer when code changes are needed
|
|
15
|
+
- QA Verifier for verification
|
|
16
|
+
- Security Governance when data, auth, secrets, payments, or production are involved
|
|
17
|
+
- GitHub Ops when versioning, PRs, releases, or checks are useful
|
|
18
|
+
|
|
19
|
+
## Flow
|
|
20
|
+
|
|
21
|
+
1. Confirm objective, constraints, definition of done, and risks.
|
|
22
|
+
2. Select relevant tasks and protocols.
|
|
23
|
+
3. Execute the phase in small verifiable steps.
|
|
24
|
+
4. Produce evidence and residual risks.
|
|
25
|
+
5. Ask permission before handing off to the next team.
|
|
26
|
+
|
|
27
|
+
## Required Gates
|
|
28
|
+
|
|
29
|
+
- Clear objective and definition of done.
|
|
30
|
+
- Relevant specification or task contract.
|
|
31
|
+
- Handoff approval between major phases.
|
|
32
|
+
- Verification evidence proportional to risk.
|
|
33
|
+
- Residual risks documented.
|
|
34
|
+
|
|
35
|
+
## Standard Output
|
|
36
|
+
|
|
37
|
+
```md
|
|
38
|
+
Scope:
|
|
39
|
+
Current phase:
|
|
40
|
+
Evidence:
|
|
41
|
+
Risks:
|
|
42
|
+
Next team:
|
|
43
|
+
Permission request:
|
|
44
|
+
```
|
|
45
|
+
|
|
@@ -0,0 +1,45 @@
|
|
|
1
|
+
# Squad: Mobile App Studio
|
|
2
|
+
|
|
3
|
+
## Use
|
|
4
|
+
|
|
5
|
+
Use this squad when the task matches Mobile App Studio.
|
|
6
|
+
|
|
7
|
+
## Agents
|
|
8
|
+
|
|
9
|
+
- Orchestrator
|
|
10
|
+
- Product Strategist when product decisions are needed
|
|
11
|
+
- Technology Strategist when stack or deployment decisions are needed
|
|
12
|
+
- Software Architect when architecture matters
|
|
13
|
+
- Design Studio roles when UI exists
|
|
14
|
+
- Implementation Engineer when code changes are needed
|
|
15
|
+
- QA Verifier for verification
|
|
16
|
+
- Security Governance when data, auth, secrets, payments, or production are involved
|
|
17
|
+
- GitHub Ops when versioning, PRs, releases, or checks are useful
|
|
18
|
+
|
|
19
|
+
## Flow
|
|
20
|
+
|
|
21
|
+
1. Confirm objective, constraints, definition of done, and risks.
|
|
22
|
+
2. Select relevant tasks and protocols.
|
|
23
|
+
3. Execute the phase in small verifiable steps.
|
|
24
|
+
4. Produce evidence and residual risks.
|
|
25
|
+
5. Ask permission before handing off to the next team.
|
|
26
|
+
|
|
27
|
+
## Required Gates
|
|
28
|
+
|
|
29
|
+
- Clear objective and definition of done.
|
|
30
|
+
- Relevant specification or task contract.
|
|
31
|
+
- Handoff approval between major phases.
|
|
32
|
+
- Verification evidence proportional to risk.
|
|
33
|
+
- Residual risks documented.
|
|
34
|
+
|
|
35
|
+
## Standard Output
|
|
36
|
+
|
|
37
|
+
```md
|
|
38
|
+
Scope:
|
|
39
|
+
Current phase:
|
|
40
|
+
Evidence:
|
|
41
|
+
Risks:
|
|
42
|
+
Next team:
|
|
43
|
+
Permission request:
|
|
44
|
+
```
|
|
45
|
+
|
|
@@ -0,0 +1,45 @@
|
|
|
1
|
+
# Squad: Product Factory
|
|
2
|
+
|
|
3
|
+
## Use
|
|
4
|
+
|
|
5
|
+
Use this squad when the task matches Product Factory.
|
|
6
|
+
|
|
7
|
+
## Agents
|
|
8
|
+
|
|
9
|
+
- Orchestrator
|
|
10
|
+
- Product Strategist when product decisions are needed
|
|
11
|
+
- Technology Strategist when stack or deployment decisions are needed
|
|
12
|
+
- Software Architect when architecture matters
|
|
13
|
+
- Design Studio roles when UI exists
|
|
14
|
+
- Implementation Engineer when code changes are needed
|
|
15
|
+
- QA Verifier for verification
|
|
16
|
+
- Security Governance when data, auth, secrets, payments, or production are involved
|
|
17
|
+
- GitHub Ops when versioning, PRs, releases, or checks are useful
|
|
18
|
+
|
|
19
|
+
## Flow
|
|
20
|
+
|
|
21
|
+
1. Confirm objective, constraints, definition of done, and risks.
|
|
22
|
+
2. Select relevant tasks and protocols.
|
|
23
|
+
3. Execute the phase in small verifiable steps.
|
|
24
|
+
4. Produce evidence and residual risks.
|
|
25
|
+
5. Ask permission before handing off to the next team.
|
|
26
|
+
|
|
27
|
+
## Required Gates
|
|
28
|
+
|
|
29
|
+
- Clear objective and definition of done.
|
|
30
|
+
- Relevant specification or task contract.
|
|
31
|
+
- Handoff approval between major phases.
|
|
32
|
+
- Verification evidence proportional to risk.
|
|
33
|
+
- Residual risks documented.
|
|
34
|
+
|
|
35
|
+
## Standard Output
|
|
36
|
+
|
|
37
|
+
```md
|
|
38
|
+
Scope:
|
|
39
|
+
Current phase:
|
|
40
|
+
Evidence:
|
|
41
|
+
Risks:
|
|
42
|
+
Next team:
|
|
43
|
+
Permission request:
|
|
44
|
+
```
|
|
45
|
+
|
|
@@ -0,0 +1,45 @@
|
|
|
1
|
+
# Squad: Production Critical
|
|
2
|
+
|
|
3
|
+
## Use
|
|
4
|
+
|
|
5
|
+
Use this squad when the task matches Production Critical.
|
|
6
|
+
|
|
7
|
+
## Agents
|
|
8
|
+
|
|
9
|
+
- Orchestrator
|
|
10
|
+
- Product Strategist when product decisions are needed
|
|
11
|
+
- Technology Strategist when stack or deployment decisions are needed
|
|
12
|
+
- Software Architect when architecture matters
|
|
13
|
+
- Design Studio roles when UI exists
|
|
14
|
+
- Implementation Engineer when code changes are needed
|
|
15
|
+
- QA Verifier for verification
|
|
16
|
+
- Security Governance when data, auth, secrets, payments, or production are involved
|
|
17
|
+
- GitHub Ops when versioning, PRs, releases, or checks are useful
|
|
18
|
+
|
|
19
|
+
## Flow
|
|
20
|
+
|
|
21
|
+
1. Confirm objective, constraints, definition of done, and risks.
|
|
22
|
+
2. Select relevant tasks and protocols.
|
|
23
|
+
3. Execute the phase in small verifiable steps.
|
|
24
|
+
4. Produce evidence and residual risks.
|
|
25
|
+
5. Ask permission before handing off to the next team.
|
|
26
|
+
|
|
27
|
+
## Required Gates
|
|
28
|
+
|
|
29
|
+
- Clear objective and definition of done.
|
|
30
|
+
- Relevant specification or task contract.
|
|
31
|
+
- Handoff approval between major phases.
|
|
32
|
+
- Verification evidence proportional to risk.
|
|
33
|
+
- Residual risks documented.
|
|
34
|
+
|
|
35
|
+
## Standard Output
|
|
36
|
+
|
|
37
|
+
```md
|
|
38
|
+
Scope:
|
|
39
|
+
Current phase:
|
|
40
|
+
Evidence:
|
|
41
|
+
Risks:
|
|
42
|
+
Next team:
|
|
43
|
+
Permission request:
|
|
44
|
+
```
|
|
45
|
+
|
|
@@ -0,0 +1,45 @@
|
|
|
1
|
+
# Squad: Refactor Lab
|
|
2
|
+
|
|
3
|
+
## Use
|
|
4
|
+
|
|
5
|
+
Use this squad when the task matches Refactor Lab.
|
|
6
|
+
|
|
7
|
+
## Agents
|
|
8
|
+
|
|
9
|
+
- Orchestrator
|
|
10
|
+
- Product Strategist when product decisions are needed
|
|
11
|
+
- Technology Strategist when stack or deployment decisions are needed
|
|
12
|
+
- Software Architect when architecture matters
|
|
13
|
+
- Design Studio roles when UI exists
|
|
14
|
+
- Implementation Engineer when code changes are needed
|
|
15
|
+
- QA Verifier for verification
|
|
16
|
+
- Security Governance when data, auth, secrets, payments, or production are involved
|
|
17
|
+
- GitHub Ops when versioning, PRs, releases, or checks are useful
|
|
18
|
+
|
|
19
|
+
## Flow
|
|
20
|
+
|
|
21
|
+
1. Confirm objective, constraints, definition of done, and risks.
|
|
22
|
+
2. Select relevant tasks and protocols.
|
|
23
|
+
3. Execute the phase in small verifiable steps.
|
|
24
|
+
4. Produce evidence and residual risks.
|
|
25
|
+
5. Ask permission before handing off to the next team.
|
|
26
|
+
|
|
27
|
+
## Required Gates
|
|
28
|
+
|
|
29
|
+
- Clear objective and definition of done.
|
|
30
|
+
- Relevant specification or task contract.
|
|
31
|
+
- Handoff approval between major phases.
|
|
32
|
+
- Verification evidence proportional to risk.
|
|
33
|
+
- Residual risks documented.
|
|
34
|
+
|
|
35
|
+
## Standard Output
|
|
36
|
+
|
|
37
|
+
```md
|
|
38
|
+
Scope:
|
|
39
|
+
Current phase:
|
|
40
|
+
Evidence:
|
|
41
|
+
Risks:
|
|
42
|
+
Next team:
|
|
43
|
+
Permission request:
|
|
44
|
+
```
|
|
45
|
+
|
|
@@ -0,0 +1,45 @@
|
|
|
1
|
+
# Squad: Research To Spec
|
|
2
|
+
|
|
3
|
+
## Use
|
|
4
|
+
|
|
5
|
+
Use this squad when the task matches Research To Spec.
|
|
6
|
+
|
|
7
|
+
## Agents
|
|
8
|
+
|
|
9
|
+
- Orchestrator
|
|
10
|
+
- Product Strategist when product decisions are needed
|
|
11
|
+
- Technology Strategist when stack or deployment decisions are needed
|
|
12
|
+
- Software Architect when architecture matters
|
|
13
|
+
- Design Studio roles when UI exists
|
|
14
|
+
- Implementation Engineer when code changes are needed
|
|
15
|
+
- QA Verifier for verification
|
|
16
|
+
- Security Governance when data, auth, secrets, payments, or production are involved
|
|
17
|
+
- GitHub Ops when versioning, PRs, releases, or checks are useful
|
|
18
|
+
|
|
19
|
+
## Flow
|
|
20
|
+
|
|
21
|
+
1. Confirm objective, constraints, definition of done, and risks.
|
|
22
|
+
2. Select relevant tasks and protocols.
|
|
23
|
+
3. Execute the phase in small verifiable steps.
|
|
24
|
+
4. Produce evidence and residual risks.
|
|
25
|
+
5. Ask permission before handing off to the next team.
|
|
26
|
+
|
|
27
|
+
## Required Gates
|
|
28
|
+
|
|
29
|
+
- Clear objective and definition of done.
|
|
30
|
+
- Relevant specification or task contract.
|
|
31
|
+
- Handoff approval between major phases.
|
|
32
|
+
- Verification evidence proportional to risk.
|
|
33
|
+
- Residual risks documented.
|
|
34
|
+
|
|
35
|
+
## Standard Output
|
|
36
|
+
|
|
37
|
+
```md
|
|
38
|
+
Scope:
|
|
39
|
+
Current phase:
|
|
40
|
+
Evidence:
|
|
41
|
+
Risks:
|
|
42
|
+
Next team:
|
|
43
|
+
Permission request:
|
|
44
|
+
```
|
|
45
|
+
|
|
@@ -0,0 +1,34 @@
|
|
|
1
|
+
# Task: Design System
|
|
2
|
+
|
|
3
|
+
## Owner
|
|
4
|
+
|
|
5
|
+
Assigned by the active workflow or squad.
|
|
6
|
+
|
|
7
|
+
## Inputs
|
|
8
|
+
|
|
9
|
+
- User goal.
|
|
10
|
+
- Current run state.
|
|
11
|
+
- Relevant specifications, files, and constraints.
|
|
12
|
+
|
|
13
|
+
## Outputs
|
|
14
|
+
|
|
15
|
+
- Completed task artifact.
|
|
16
|
+
- Evidence.
|
|
17
|
+
- Risks and pending items.
|
|
18
|
+
- Handoff recommendation.
|
|
19
|
+
|
|
20
|
+
## Acceptance Criteria
|
|
21
|
+
|
|
22
|
+
- Output is specific and testable.
|
|
23
|
+
- Assumptions are recorded.
|
|
24
|
+
- Verification method is stated.
|
|
25
|
+
- Next step is clear.
|
|
26
|
+
|
|
27
|
+
## Verification
|
|
28
|
+
|
|
29
|
+
Check against the active protocol and quality gates.
|
|
30
|
+
|
|
31
|
+
## Stop Condition
|
|
32
|
+
|
|
33
|
+
Stop and ask the user when scope, cost, architecture, production risk, or external state would change.
|
|
34
|
+
|
|
@@ -0,0 +1,34 @@
|
|
|
1
|
+
# Task: Github Release Ops
|
|
2
|
+
|
|
3
|
+
## Owner
|
|
4
|
+
|
|
5
|
+
Assigned by the active workflow or squad.
|
|
6
|
+
|
|
7
|
+
## Inputs
|
|
8
|
+
|
|
9
|
+
- User goal.
|
|
10
|
+
- Current run state.
|
|
11
|
+
- Relevant specifications, files, and constraints.
|
|
12
|
+
|
|
13
|
+
## Outputs
|
|
14
|
+
|
|
15
|
+
- Completed task artifact.
|
|
16
|
+
- Evidence.
|
|
17
|
+
- Risks and pending items.
|
|
18
|
+
- Handoff recommendation.
|
|
19
|
+
|
|
20
|
+
## Acceptance Criteria
|
|
21
|
+
|
|
22
|
+
- Output is specific and testable.
|
|
23
|
+
- Assumptions are recorded.
|
|
24
|
+
- Verification method is stated.
|
|
25
|
+
- Next step is clear.
|
|
26
|
+
|
|
27
|
+
## Verification
|
|
28
|
+
|
|
29
|
+
Check against the active protocol and quality gates.
|
|
30
|
+
|
|
31
|
+
## Stop Condition
|
|
32
|
+
|
|
33
|
+
Stop and ask the user when scope, cost, architecture, production risk, or external state would change.
|
|
34
|
+
|
|
@@ -0,0 +1,34 @@
|
|
|
1
|
+
# Task: Implementation Build
|
|
2
|
+
|
|
3
|
+
## Owner
|
|
4
|
+
|
|
5
|
+
Assigned by the active workflow or squad.
|
|
6
|
+
|
|
7
|
+
## Inputs
|
|
8
|
+
|
|
9
|
+
- User goal.
|
|
10
|
+
- Current run state.
|
|
11
|
+
- Relevant specifications, files, and constraints.
|
|
12
|
+
|
|
13
|
+
## Outputs
|
|
14
|
+
|
|
15
|
+
- Completed task artifact.
|
|
16
|
+
- Evidence.
|
|
17
|
+
- Risks and pending items.
|
|
18
|
+
- Handoff recommendation.
|
|
19
|
+
|
|
20
|
+
## Acceptance Criteria
|
|
21
|
+
|
|
22
|
+
- Output is specific and testable.
|
|
23
|
+
- Assumptions are recorded.
|
|
24
|
+
- Verification method is stated.
|
|
25
|
+
- Next step is clear.
|
|
26
|
+
|
|
27
|
+
## Verification
|
|
28
|
+
|
|
29
|
+
Check against the active protocol and quality gates.
|
|
30
|
+
|
|
31
|
+
## Stop Condition
|
|
32
|
+
|
|
33
|
+
Stop and ask the user when scope, cost, architecture, production risk, or external state would change.
|
|
34
|
+
|
|
@@ -0,0 +1,34 @@
|
|
|
1
|
+
# Task: Intake Brief
|
|
2
|
+
|
|
3
|
+
## Owner
|
|
4
|
+
|
|
5
|
+
Assigned by the active workflow or squad.
|
|
6
|
+
|
|
7
|
+
## Inputs
|
|
8
|
+
|
|
9
|
+
- User goal.
|
|
10
|
+
- Current run state.
|
|
11
|
+
- Relevant specifications, files, and constraints.
|
|
12
|
+
|
|
13
|
+
## Outputs
|
|
14
|
+
|
|
15
|
+
- Completed task artifact.
|
|
16
|
+
- Evidence.
|
|
17
|
+
- Risks and pending items.
|
|
18
|
+
- Handoff recommendation.
|
|
19
|
+
|
|
20
|
+
## Acceptance Criteria
|
|
21
|
+
|
|
22
|
+
- Output is specific and testable.
|
|
23
|
+
- Assumptions are recorded.
|
|
24
|
+
- Verification method is stated.
|
|
25
|
+
- Next step is clear.
|
|
26
|
+
|
|
27
|
+
## Verification
|
|
28
|
+
|
|
29
|
+
Check against the active protocol and quality gates.
|
|
30
|
+
|
|
31
|
+
## Stop Condition
|
|
32
|
+
|
|
33
|
+
Stop and ask the user when scope, cost, architecture, production risk, or external state would change.
|
|
34
|
+
|
|
@@ -0,0 +1,34 @@
|
|
|
1
|
+
# Task: Product Requirements
|
|
2
|
+
|
|
3
|
+
## Owner
|
|
4
|
+
|
|
5
|
+
Assigned by the active workflow or squad.
|
|
6
|
+
|
|
7
|
+
## Inputs
|
|
8
|
+
|
|
9
|
+
- User goal.
|
|
10
|
+
- Current run state.
|
|
11
|
+
- Relevant specifications, files, and constraints.
|
|
12
|
+
|
|
13
|
+
## Outputs
|
|
14
|
+
|
|
15
|
+
- Completed task artifact.
|
|
16
|
+
- Evidence.
|
|
17
|
+
- Risks and pending items.
|
|
18
|
+
- Handoff recommendation.
|
|
19
|
+
|
|
20
|
+
## Acceptance Criteria
|
|
21
|
+
|
|
22
|
+
- Output is specific and testable.
|
|
23
|
+
- Assumptions are recorded.
|
|
24
|
+
- Verification method is stated.
|
|
25
|
+
- Next step is clear.
|
|
26
|
+
|
|
27
|
+
## Verification
|
|
28
|
+
|
|
29
|
+
Check against the active protocol and quality gates.
|
|
30
|
+
|
|
31
|
+
## Stop Condition
|
|
32
|
+
|
|
33
|
+
Stop and ask the user when scope, cost, architecture, production risk, or external state would change.
|
|
34
|
+
|
|
@@ -0,0 +1,34 @@
|
|
|
1
|
+
# Task: Production Readiness
|
|
2
|
+
|
|
3
|
+
## Owner
|
|
4
|
+
|
|
5
|
+
Assigned by the active workflow or squad.
|
|
6
|
+
|
|
7
|
+
## Inputs
|
|
8
|
+
|
|
9
|
+
- User goal.
|
|
10
|
+
- Current run state.
|
|
11
|
+
- Relevant specifications, files, and constraints.
|
|
12
|
+
|
|
13
|
+
## Outputs
|
|
14
|
+
|
|
15
|
+
- Completed task artifact.
|
|
16
|
+
- Evidence.
|
|
17
|
+
- Risks and pending items.
|
|
18
|
+
- Handoff recommendation.
|
|
19
|
+
|
|
20
|
+
## Acceptance Criteria
|
|
21
|
+
|
|
22
|
+
- Output is specific and testable.
|
|
23
|
+
- Assumptions are recorded.
|
|
24
|
+
- Verification method is stated.
|
|
25
|
+
- Next step is clear.
|
|
26
|
+
|
|
27
|
+
## Verification
|
|
28
|
+
|
|
29
|
+
Check against the active protocol and quality gates.
|
|
30
|
+
|
|
31
|
+
## Stop Condition
|
|
32
|
+
|
|
33
|
+
Stop and ask the user when scope, cost, architecture, production risk, or external state would change.
|
|
34
|
+
|
|
@@ -0,0 +1,34 @@
|
|
|
1
|
+
# Task: Stack Recommendation
|
|
2
|
+
|
|
3
|
+
## Owner
|
|
4
|
+
|
|
5
|
+
Assigned by the active workflow or squad.
|
|
6
|
+
|
|
7
|
+
## Inputs
|
|
8
|
+
|
|
9
|
+
- User goal.
|
|
10
|
+
- Current run state.
|
|
11
|
+
- Relevant specifications, files, and constraints.
|
|
12
|
+
|
|
13
|
+
## Outputs
|
|
14
|
+
|
|
15
|
+
- Completed task artifact.
|
|
16
|
+
- Evidence.
|
|
17
|
+
- Risks and pending items.
|
|
18
|
+
- Handoff recommendation.
|
|
19
|
+
|
|
20
|
+
## Acceptance Criteria
|
|
21
|
+
|
|
22
|
+
- Output is specific and testable.
|
|
23
|
+
- Assumptions are recorded.
|
|
24
|
+
- Verification method is stated.
|
|
25
|
+
- Next step is clear.
|
|
26
|
+
|
|
27
|
+
## Verification
|
|
28
|
+
|
|
29
|
+
Check against the active protocol and quality gates.
|
|
30
|
+
|
|
31
|
+
## Stop Condition
|
|
32
|
+
|
|
33
|
+
Stop and ask the user when scope, cost, architecture, production risk, or external state would change.
|
|
34
|
+
|
|
@@ -0,0 +1,34 @@
|
|
|
1
|
+
# Task: Verification Qa
|
|
2
|
+
|
|
3
|
+
## Owner
|
|
4
|
+
|
|
5
|
+
Assigned by the active workflow or squad.
|
|
6
|
+
|
|
7
|
+
## Inputs
|
|
8
|
+
|
|
9
|
+
- User goal.
|
|
10
|
+
- Current run state.
|
|
11
|
+
- Relevant specifications, files, and constraints.
|
|
12
|
+
|
|
13
|
+
## Outputs
|
|
14
|
+
|
|
15
|
+
- Completed task artifact.
|
|
16
|
+
- Evidence.
|
|
17
|
+
- Risks and pending items.
|
|
18
|
+
- Handoff recommendation.
|
|
19
|
+
|
|
20
|
+
## Acceptance Criteria
|
|
21
|
+
|
|
22
|
+
- Output is specific and testable.
|
|
23
|
+
- Assumptions are recorded.
|
|
24
|
+
- Verification method is stated.
|
|
25
|
+
- Next step is clear.
|
|
26
|
+
|
|
27
|
+
## Verification
|
|
28
|
+
|
|
29
|
+
Check against the active protocol and quality gates.
|
|
30
|
+
|
|
31
|
+
## Stop Condition
|
|
32
|
+
|
|
33
|
+
Stop and ask the user when scope, cost, architecture, production risk, or external state would change.
|
|
34
|
+
|