sagaz-ai 0.2.0 → 0.3.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/CHANGELOG.md +63 -1
- package/RELEASE_NOTES.md +25 -26
- package/ai-orchestration-ecosystem/INDEX.md +19 -0
- package/ai-orchestration-ecosystem/README.md +16 -5
- package/ai-orchestration-ecosystem/examples/README.md +38 -60
- package/ai-orchestration-ecosystem/examples/brownfield-refactor.md +90 -0
- package/ai-orchestration-ecosystem/examples/bugfix-production-release.md +90 -0
- package/ai-orchestration-ecosystem/examples/mobile-habit-tracker.md +111 -0
- package/ai-orchestration-ecosystem/examples/web-saas-vercel.md +114 -0
- package/ai-orchestration-ecosystem/governance/capabilities-matrix.md +169 -0
- package/ai-orchestration-ecosystem/governance/operations-runbook.md +236 -0
- package/ai-orchestration-ecosystem/manifest.json +18 -1
- package/ai-orchestration-ecosystem/protocols/agent-observability.md +111 -36
- package/ai-orchestration-ecosystem/protocols/github-operations.md +1 -0
- package/ai-orchestration-ecosystem/protocols/mcp-connector-policy.md +173 -0
- package/ai-orchestration-ecosystem/protocols/permission-contract.md +99 -0
- package/ai-orchestration-ecosystem/protocols/release-versioning-gate.md +2 -0
- package/ai-orchestration-ecosystem/stack-playbooks/README.md +61 -0
- package/ai-orchestration-ecosystem/stack-playbooks/expo-eas.md +63 -0
- package/ai-orchestration-ecosystem/stack-playbooks/firebase.md +61 -0
- package/ai-orchestration-ecosystem/stack-playbooks/nextjs-vercel-supabase.md +64 -0
- package/ai-orchestration-ecosystem/stack-playbooks/node-api.md +61 -0
- package/ai-orchestration-ecosystem/stack-playbooks/react-vite-static.md +60 -0
- package/ai-orchestration-ecosystem/templates/execution-trace.md +89 -0
- package/ai-orchestration-ecosystem/templates/run-state.md +7 -0
- package/ai-orchestration-ecosystem/tools/tool-registry.md +4 -0
- package/codex-skill/sagaz/SKILL.md +14 -2
- package/package.json +1 -1
- package/scripts/verify-package.js +184 -0
package/CHANGELOG.md
CHANGED
|
@@ -1,5 +1,68 @@
|
|
|
1
1
|
# Changelog
|
|
2
2
|
|
|
3
|
+
## [0.3.0] - 2026-06-11
|
|
4
|
+
|
|
5
|
+
### Release Type
|
|
6
|
+
|
|
7
|
+
Minor
|
|
8
|
+
|
|
9
|
+
### Added
|
|
10
|
+
|
|
11
|
+
- Operations runbook for daily starts, project starts, resumes, handoffs, verification, releases, GitHub operations, and stop conditions.
|
|
12
|
+
- Complete examples library covering web SaaS on Vercel, mobile habit tracking, production bugfix releases, and brownfield refactors.
|
|
13
|
+
- Capabilities matrix comparing Sagaz with common orchestration systems and identifying what Sagaz now covers or intentionally defers.
|
|
14
|
+
- Formal permission contract with approval levels for local edits, installs, network access, GitHub operations, releases, secrets, and destructive actions.
|
|
15
|
+
- Stack playbooks for Next.js/Vercel/Supabase, React/Vite/static hosting, Expo/EAS, Node APIs, and Firebase.
|
|
16
|
+
- Execution trace template and stronger observability contract for commands, decisions, failures, handoffs, and release evidence.
|
|
17
|
+
- MCP connector policy for Figma, GitHub, browser automation, deployment providers, databases, Canva, npm registries, observability, and AI providers.
|
|
18
|
+
|
|
19
|
+
### Changed
|
|
20
|
+
|
|
21
|
+
- `npm test` now validates stack playbooks, permission policy, execution trace requirements, observability rules, and MCP connector policy coverage.
|
|
22
|
+
- README, INDEX, manifest, tool registry, run-state template, and Sagaz skill instructions now expose the new governance and connector contracts.
|
|
23
|
+
- Release governance now requires stronger evidence around permissions, connector usage, workflow traceability, and stack-specific verification.
|
|
24
|
+
|
|
25
|
+
### Fixed
|
|
26
|
+
|
|
27
|
+
- Filled remaining non-CLI governance gaps identified after the 0.2.0 release.
|
|
28
|
+
- Reduced ambiguity around cross-platform execution on Windows and macOS inside Codex Desktop.
|
|
29
|
+
|
|
30
|
+
### Removed
|
|
31
|
+
|
|
32
|
+
- None.
|
|
33
|
+
|
|
34
|
+
### Security
|
|
35
|
+
|
|
36
|
+
- Added explicit permission levels for secrets, destructive actions, external publishing, GitHub operations, package registries, and MCP connectors.
|
|
37
|
+
|
|
38
|
+
### Compatibility
|
|
39
|
+
|
|
40
|
+
- Windows: supported through Codex Desktop and locally verified on Windows.
|
|
41
|
+
- macOS: supported through Codex Desktop and covered by GitHub Actions package checks.
|
|
42
|
+
- Node.js: package baseline remains `>=22.14`; Node.js 24 is preferred for new installs and CI.
|
|
43
|
+
- Codex Desktop: Sagaz remains a Codex Desktop orchestration skill, not a standalone terminal agent runtime.
|
|
44
|
+
|
|
45
|
+
### Migration Notes
|
|
46
|
+
|
|
47
|
+
- Existing users should run `npx sagaz-ai@0.3.0 sync` or `npx sagaz-ai sync` to refresh the installed Codex Desktop skill.
|
|
48
|
+
- Open a new Codex Desktop thread after syncing so the updated skill can be discovered.
|
|
49
|
+
|
|
50
|
+
### Verification
|
|
51
|
+
|
|
52
|
+
- npm test: passed locally on Windows.
|
|
53
|
+
- npm run doctor: passed locally on Windows with `Synchronized with source: yes`.
|
|
54
|
+
- npm pack --dry-run: passed locally on Windows after allowing npm cache access outside the sandbox.
|
|
55
|
+
- Windows: prepared and verified from a Windows Codex Desktop workspace.
|
|
56
|
+
- macOS: package checks remain covered by GitHub Actions.
|
|
57
|
+
- Codex Desktop: skill sync remains required after install or upgrade.
|
|
58
|
+
|
|
59
|
+
### Release Evidence
|
|
60
|
+
|
|
61
|
+
- Commit: pending.
|
|
62
|
+
- Tag: pending.
|
|
63
|
+
- GitHub release: pending.
|
|
64
|
+
- npm package: pending.
|
|
65
|
+
|
|
3
66
|
## [0.2.0] - 2026-06-08
|
|
4
67
|
|
|
5
68
|
### Release Type
|
|
@@ -64,4 +127,3 @@ Minor
|
|
|
64
127
|
- Tag: pending.
|
|
65
128
|
- GitHub release: pending.
|
|
66
129
|
- npm package: pending.
|
|
67
|
-
|
package/RELEASE_NOTES.md
CHANGED
|
@@ -2,8 +2,8 @@
|
|
|
2
2
|
|
|
3
3
|
## Release
|
|
4
4
|
|
|
5
|
-
Version: 0.
|
|
6
|
-
Date: 2026-06-
|
|
5
|
+
Version: 0.3.0
|
|
6
|
+
Date: 2026-06-11
|
|
7
7
|
Release type: Minor
|
|
8
8
|
GitHub commit: pending
|
|
9
9
|
Git tag: pending
|
|
@@ -12,34 +12,34 @@ npm package: pending
|
|
|
12
12
|
|
|
13
13
|
## Summary
|
|
14
14
|
|
|
15
|
-
Sagaz 0.
|
|
15
|
+
Sagaz 0.3.0 completes the main non-CLI governance layer for Codex Desktop orchestration. It adds operational runbooks, complete scenario examples, a capabilities matrix, formal permission policy, stack playbooks, execution trace evidence, and MCP connector governance.
|
|
16
16
|
|
|
17
17
|
## Audience Impact
|
|
18
18
|
|
|
19
|
-
- New users: clearer
|
|
19
|
+
- New users: clearer operating model, examples, stack guidance, and permission expectations before using Sagaz.
|
|
20
20
|
- Existing users: should refresh the installed skill with `npx sagaz-ai sync`.
|
|
21
|
-
- Maintainers: stronger
|
|
22
|
-
- Design team: Figma MCP
|
|
23
|
-
- Engineering team:
|
|
21
|
+
- Maintainers: stronger package checks now catch stack playbook, observability, permission, and connector-policy drift.
|
|
22
|
+
- Design team: Figma MCP usage is governed as a formal connector workflow for app-like mockups and design artifacts.
|
|
23
|
+
- Engineering team: workflow evidence now includes traceable commands, decisions, failures, permissions, and handoffs.
|
|
24
24
|
|
|
25
25
|
## What Changed
|
|
26
26
|
|
|
27
|
-
- Added
|
|
28
|
-
- Added
|
|
29
|
-
- Added
|
|
30
|
-
- Added
|
|
31
|
-
- Added
|
|
32
|
-
- Added
|
|
33
|
-
- Added
|
|
34
|
-
-
|
|
27
|
+
- Added an operations runbook for everyday Sagaz use.
|
|
28
|
+
- Added complete examples for common delivery scenarios.
|
|
29
|
+
- Added a capabilities matrix against other orchestration ecosystems.
|
|
30
|
+
- Added a formal permission contract for Windows and macOS Codex Desktop usage.
|
|
31
|
+
- Added stack-specific playbooks.
|
|
32
|
+
- Added an execution trace template and stronger observability protocol.
|
|
33
|
+
- Added MCP connector policy across design, deploy, package, data, browser, and AI providers.
|
|
34
|
+
- Expanded package verification to enforce the new governance files.
|
|
35
35
|
|
|
36
36
|
## Why It Matters
|
|
37
37
|
|
|
38
|
-
Sagaz
|
|
38
|
+
Sagaz now has clearer rules for how agents should choose tools, request permission, preserve workflow state, hand off work, verify stack-specific outcomes, and operate MCP connectors without drifting into ad hoc behavior.
|
|
39
39
|
|
|
40
40
|
## Compatibility
|
|
41
41
|
|
|
42
|
-
- Windows: supported and locally verified.
|
|
42
|
+
- Windows: supported and locally verified from a Codex Desktop workspace.
|
|
43
43
|
- macOS: supported through Codex Desktop and GitHub Actions runner validation.
|
|
44
44
|
- Node.js: `>=22.14` remains the package minimum; Node.js 24 is preferred for new installs and CI.
|
|
45
45
|
- Codex Desktop: required.
|
|
@@ -51,7 +51,7 @@ Sagaz is now harder to accidentally drift, release, or publish in an inconsisten
|
|
|
51
51
|
Run:
|
|
52
52
|
|
|
53
53
|
```bash
|
|
54
|
-
npx sagaz-ai sync
|
|
54
|
+
npx sagaz-ai@0.3.0 sync
|
|
55
55
|
npx sagaz-ai doctor
|
|
56
56
|
```
|
|
57
57
|
|
|
@@ -59,16 +59,16 @@ Then open a new Codex Desktop thread so Sagaz is rediscovered.
|
|
|
59
59
|
|
|
60
60
|
## Verification
|
|
61
61
|
|
|
62
|
-
- `npm test`: passed locally.
|
|
63
|
-
- `npm run doctor`: passed locally with installed skill synchronization confirmed.
|
|
64
|
-
- `npm pack --dry-run`: passed locally after npm cache access was allowed outside the sandbox.
|
|
65
|
-
- Evaluation scenarios: enforced by the strengthened Sagaz evaluation suite.
|
|
62
|
+
- `npm test`: passed locally on Windows.
|
|
63
|
+
- `npm run doctor`: passed locally on Windows with installed skill synchronization confirmed.
|
|
64
|
+
- `npm pack --dry-run`: passed locally on Windows after npm cache access was allowed outside the sandbox.
|
|
66
65
|
- Manual checks: Git status reviewed before release preparation.
|
|
67
66
|
|
|
68
67
|
## Known Limitations
|
|
69
68
|
|
|
70
|
-
-
|
|
71
|
-
-
|
|
69
|
+
- Sagaz still intentionally skips a standalone CLI runtime; Codex Desktop remains the execution surface.
|
|
70
|
+
- GitHub release and npm publishing remain explicit approval steps.
|
|
71
|
+
- Connector behavior depends on each external MCP/app authorization and platform availability.
|
|
72
72
|
|
|
73
73
|
## Rollback Plan
|
|
74
74
|
|
|
@@ -79,6 +79,5 @@ Then open a new Codex Desktop thread so Sagaz is rediscovered.
|
|
|
79
79
|
## Release Decision
|
|
80
80
|
|
|
81
81
|
Approved by: Thiago Cabral
|
|
82
|
-
Approval date: 2026-06-
|
|
82
|
+
Approval date: 2026-06-11
|
|
83
83
|
Residual risk: GitHub Actions and npm publishing still need remote execution after push.
|
|
84
|
-
|
|
@@ -71,6 +71,8 @@ See `protocols/` for quality gates, testing matrix, stack selection, design qual
|
|
|
71
71
|
- `protocols/installed-skill-sync.md`
|
|
72
72
|
- `protocols/memory.md`
|
|
73
73
|
- `protocols/model-routing.md`
|
|
74
|
+
- `protocols/mcp-connector-policy.md`
|
|
75
|
+
- `protocols/permission-contract.md`
|
|
74
76
|
- `protocols/post-delivery-monitoring.md`
|
|
75
77
|
|
|
76
78
|
## Tools
|
|
@@ -89,6 +91,15 @@ See `protocols/` for quality gates, testing matrix, stack selection, design qual
|
|
|
89
91
|
- `stack-presets/static-site.md`
|
|
90
92
|
- `stack-presets/admin-dashboard.md`
|
|
91
93
|
|
|
94
|
+
## Stack Playbooks
|
|
95
|
+
|
|
96
|
+
- `stack-playbooks/README.md`
|
|
97
|
+
- `stack-playbooks/nextjs-vercel-supabase.md`
|
|
98
|
+
- `stack-playbooks/react-vite-static.md`
|
|
99
|
+
- `stack-playbooks/expo-eas.md`
|
|
100
|
+
- `stack-playbooks/node-api.md`
|
|
101
|
+
- `stack-playbooks/firebase.md`
|
|
102
|
+
|
|
92
103
|
## Evaluations
|
|
93
104
|
|
|
94
105
|
- `evals/sagaz-evaluation-suite.md`
|
|
@@ -96,13 +107,21 @@ See `protocols/` for quality gates, testing matrix, stack selection, design qual
|
|
|
96
107
|
## Examples
|
|
97
108
|
|
|
98
109
|
- `examples/README.md`
|
|
110
|
+
- `examples/web-saas-vercel.md`
|
|
111
|
+
- `examples/mobile-habit-tracker.md`
|
|
112
|
+
- `examples/bugfix-production-release.md`
|
|
113
|
+
- `examples/brownfield-refactor.md`
|
|
99
114
|
|
|
100
115
|
## Templates
|
|
101
116
|
|
|
102
117
|
See `templates/` for task briefs, product specs, technical specs, design systems, future-change guides, refactor safety contracts, stack recommendations, run state, squad handoffs, QA reports, release checklists, changelogs, release notes, and final handoffs.
|
|
103
118
|
|
|
119
|
+
- `templates/execution-trace.md`
|
|
120
|
+
|
|
104
121
|
## Governance
|
|
105
122
|
|
|
123
|
+
- `governance/capabilities-matrix.md`
|
|
124
|
+
- `governance/operations-runbook.md`
|
|
106
125
|
- `governance/quality-policy.md`
|
|
107
126
|
- `governance/security-policy.md`
|
|
108
127
|
- `governance/versioning.md`
|
|
@@ -4,11 +4,12 @@ A local AI orchestration ecosystem for Codex, focused on autonomous teams, consi
|
|
|
4
4
|
|
|
5
5
|
## How To Use
|
|
6
6
|
|
|
7
|
-
1. Read `
|
|
8
|
-
2.
|
|
9
|
-
3.
|
|
10
|
-
4.
|
|
11
|
-
5.
|
|
7
|
+
1. Read `governance/operations-runbook.md` for the daily operating procedure.
|
|
8
|
+
2. Read `quickstart.md`.
|
|
9
|
+
3. Choose the smallest sufficient workflow or squad.
|
|
10
|
+
4. Use formal tasks, handoffs, and quality gates.
|
|
11
|
+
5. Create or update run state for medium/large work.
|
|
12
|
+
6. Verify before declaring done.
|
|
12
13
|
|
|
13
14
|
## Structure
|
|
14
15
|
|
|
@@ -18,7 +19,9 @@ A local AI orchestration ecosystem for Codex, focused on autonomous teams, consi
|
|
|
18
19
|
- `agents/`: role definitions.
|
|
19
20
|
- `tasks/`: formal task contracts.
|
|
20
21
|
- `protocols/`: operating rules and quality gates.
|
|
22
|
+
- `stack-playbooks/`: operational guides for common stack implementation, verification, and deployment.
|
|
21
23
|
- `templates/`: reusable Markdown artifacts.
|
|
24
|
+
- `examples/`: complete web, mobile, bugfix, and refactor flow examples.
|
|
22
25
|
- `engineering/`: software engineering standards.
|
|
23
26
|
- `governance/`: quality, security, and maintenance policies.
|
|
24
27
|
|
|
@@ -34,6 +37,14 @@ Use `protocols/release-versioning-gate.md` before version bumps, Git tags, GitHu
|
|
|
34
37
|
|
|
35
38
|
Use `protocols/installed-skill-sync.md` after changing the Sagaz skill or release rules so the installed Codex Desktop skill does not drift from the repository copy.
|
|
36
39
|
|
|
40
|
+
Use `governance/capabilities-matrix.md` when comparing Sagaz with CrewAI, AutoGen, LangChain, LangGraph, AIOX, Synkra, or similar orchestration systems.
|
|
41
|
+
|
|
42
|
+
Use `protocols/permission-contract.md` before actions that change local state, remote state, accounts, deployments, packages, credentials, or GitHub history.
|
|
43
|
+
|
|
44
|
+
Use `protocols/agent-observability.md` and `templates/execution-trace.md` for multi-phase, production, release, deployment, package, or high-risk work.
|
|
45
|
+
|
|
46
|
+
Use `protocols/mcp-connector-policy.md` before using MCPs or external connectors such as Figma, GitHub, Canva, Browser, Vercel, Supabase, Firebase, npm, or observability tools.
|
|
47
|
+
|
|
37
48
|
## Advanced Engineering Coverage
|
|
38
49
|
|
|
39
50
|
Sagaz includes protocols for SRE readiness, DORA metrics, secure SDLC, dependency governance, data privacy lifecycle, architecture fitness functions, API contracts, performance budgets, accessibility compliance, database migrations, release strategy, and AI application quality.
|
|
@@ -2,69 +2,47 @@
|
|
|
2
2
|
|
|
3
3
|
## Purpose
|
|
4
4
|
|
|
5
|
-
Provide reusable, low-token examples for common Sagaz projects.
|
|
5
|
+
Provide reusable, low-token examples for common Sagaz projects.
|
|
6
6
|
|
|
7
|
-
|
|
7
|
+
Examples are not templates to copy blindly. They show the expected prompt shape, workflow, squads, artifacts, handoffs, verification depth, GitHub actions, deployment path, and final delivery evidence.
|
|
8
8
|
|
|
9
|
-
|
|
10
|
-
- SaaS web app
|
|
11
|
-
- admin dashboard
|
|
12
|
-
- mobile app
|
|
13
|
-
- bugfix to release
|
|
14
|
-
- safe refactor
|
|
15
|
-
- production deploy
|
|
16
|
-
- GitHub release
|
|
9
|
+
## Complete Examples
|
|
17
10
|
|
|
18
|
-
|
|
19
|
-
|
|
20
|
-
|
|
21
|
-
|
|
22
|
-
- user prompt
|
|
23
|
-
- selected workflow
|
|
24
|
-
- required squads
|
|
25
|
-
- first questions, if any
|
|
26
|
-
- stack recommendation summary
|
|
27
|
-
- handoff sequence
|
|
28
|
-
- expected artifacts
|
|
29
|
-
- verification plan
|
|
30
|
-
- GitHub actions to suggest
|
|
31
|
-
- deployment path
|
|
32
|
-
- final handoff shape
|
|
33
|
-
|
|
34
|
-
## Minimal Web App Example
|
|
35
|
-
|
|
36
|
-
```md
|
|
37
|
-
User prompt:
|
|
38
|
-
Sagaz: create a premium appointment scheduling SaaS for small clinics.
|
|
39
|
-
|
|
40
|
-
Workflow:
|
|
41
|
-
workflows/greenfield-web-app.md
|
|
42
|
-
|
|
43
|
-
Squads:
|
|
44
|
-
Product Factory -> Design Studio -> Production Critical -> GitHub Ops
|
|
11
|
+
- `web-saas-vercel.md`: appointment scheduling SaaS using a web production path.
|
|
12
|
+
- `mobile-habit-tracker.md`: Android/iOS habit tracker with mobile release planning.
|
|
13
|
+
- `bugfix-production-release.md`: production bugfix through verification and GitHub release.
|
|
14
|
+
- `brownfield-refactor.md`: safe refactor of an existing project without behavior changes.
|
|
45
15
|
|
|
46
|
-
|
|
47
|
-
Next.js on Vercel, TypeScript, Supabase, Playwright, GitHub Actions.
|
|
48
|
-
|
|
49
|
-
Reason:
|
|
50
|
-
Fast delivery, clear deployment path, managed auth/database, strong web ecosystem, good future maintainability.
|
|
51
|
-
|
|
52
|
-
Required handoffs:
|
|
53
|
-
Intake -> stack -> spec -> design -> architecture -> implementation -> QA -> production readiness -> GitHub/deploy.
|
|
54
|
-
```
|
|
55
|
-
|
|
56
|
-
## Mobile App Example
|
|
57
|
-
|
|
58
|
-
```md
|
|
59
|
-
User prompt:
|
|
60
|
-
Sagaz: create an Android/iOS habit tracker with premium UX and store-ready release planning.
|
|
61
|
-
|
|
62
|
-
Workflow:
|
|
63
|
-
workflows/mobile-app-production.md
|
|
16
|
+
## Example Structure
|
|
64
17
|
|
|
65
|
-
|
|
66
|
-
|
|
18
|
+
Each complete example includes:
|
|
19
|
+
|
|
20
|
+
- User prompt.
|
|
21
|
+
- Selected workflow.
|
|
22
|
+
- Required squads.
|
|
23
|
+
- First actions.
|
|
24
|
+
- Stack recommendation.
|
|
25
|
+
- Handoff sequence.
|
|
26
|
+
- Expected artifacts.
|
|
27
|
+
- Verification plan.
|
|
28
|
+
- GitHub actions to suggest.
|
|
29
|
+
- Deployment or release path.
|
|
30
|
+
- Final handoff shape.
|
|
31
|
+
|
|
32
|
+
## How To Use
|
|
33
|
+
|
|
34
|
+
1. Pick the example closest to the user's request.
|
|
35
|
+
2. Load only that example and the named workflow/task/protocol files needed for the current phase.
|
|
36
|
+
3. Adapt constraints to the actual project.
|
|
37
|
+
4. Keep run state for medium, large, production, mobile, or multi-phase work.
|
|
38
|
+
5. Ask permission before moving across major phases or doing remote actions.
|
|
39
|
+
|
|
40
|
+
## Selection Map
|
|
41
|
+
|
|
42
|
+
| User Request | Example | Workflow |
|
|
43
|
+
| --- | --- | --- |
|
|
44
|
+
| New SaaS, dashboard, or premium web app | `web-saas-vercel.md` | `workflows/greenfield-web-app.md` |
|
|
45
|
+
| Android/iOS app | `mobile-habit-tracker.md` | `workflows/mobile-app-production.md` |
|
|
46
|
+
| Production bug | `bugfix-production-release.md` | `workflows/bugfix-to-release.md` |
|
|
47
|
+
| Safe refactor | `brownfield-refactor.md` | `workflows/brownfield-refactor-safe.md` |
|
|
67
48
|
|
|
68
|
-
Required evidence:
|
|
69
|
-
Device-size review, offline behavior decision, accessibility checks, app icon/splash plan, release checklist.
|
|
70
|
-
```
|
|
@@ -0,0 +1,90 @@
|
|
|
1
|
+
# Example: Brownfield Refactor
|
|
2
|
+
|
|
3
|
+
## User Prompt
|
|
4
|
+
|
|
5
|
+
```text
|
|
6
|
+
Sagaz: refactor this existing project safely without changing behavior.
|
|
7
|
+
|
|
8
|
+
Goal:
|
|
9
|
+
Make the billing module easier to maintain before adding new plan types.
|
|
10
|
+
```
|
|
11
|
+
|
|
12
|
+
## Selected Workflow
|
|
13
|
+
|
|
14
|
+
`workflows/brownfield-refactor-safe.md`
|
|
15
|
+
|
|
16
|
+
## Required Squads
|
|
17
|
+
|
|
18
|
+
- `squads/code-audit.md`
|
|
19
|
+
- `squads/refactor-lab.md`
|
|
20
|
+
- `squads/production-critical.md`
|
|
21
|
+
- `squads/github-ops.md`
|
|
22
|
+
|
|
23
|
+
## First Actions
|
|
24
|
+
|
|
25
|
+
1. Inspect git status.
|
|
26
|
+
2. Identify the current behavior and files involved.
|
|
27
|
+
3. Establish baseline tests or manual checks.
|
|
28
|
+
4. Define invariants that must not change.
|
|
29
|
+
5. Create or update run state.
|
|
30
|
+
6. Ask permission before editing code.
|
|
31
|
+
|
|
32
|
+
## Stack Recommendation
|
|
33
|
+
|
|
34
|
+
Use the existing project stack. Prefer local patterns and existing helpers over new abstractions.
|
|
35
|
+
|
|
36
|
+
## Handoff Sequence
|
|
37
|
+
|
|
38
|
+
| Phase | From | To | Evidence |
|
|
39
|
+
| --- | --- | --- | --- |
|
|
40
|
+
| Baseline | code-audit | refactor-lab | behavior map, tests, invariants |
|
|
41
|
+
| Refactor plan | refactor-lab | production-critical | scoped plan, rollback path |
|
|
42
|
+
| Implementation | production-critical | production-critical | small commits or small logical steps |
|
|
43
|
+
| Verification | production-critical | github-ops | before/after checks, residual risk |
|
|
44
|
+
|
|
45
|
+
## Expected Artifacts
|
|
46
|
+
|
|
47
|
+
- `templates/refactor-safety-contract.md`.
|
|
48
|
+
- `templates/future-change-guide.md`.
|
|
49
|
+
- Baseline behavior notes.
|
|
50
|
+
- Changed file summary.
|
|
51
|
+
- `templates/qa-report.md`.
|
|
52
|
+
- Final handoff.
|
|
53
|
+
|
|
54
|
+
## Verification Plan
|
|
55
|
+
|
|
56
|
+
- Run existing tests before changes.
|
|
57
|
+
- Add characterization tests if risk is high and coverage is weak.
|
|
58
|
+
- Refactor in small steps.
|
|
59
|
+
- Run tests after each meaningful step.
|
|
60
|
+
- Compare user-facing behavior before and after.
|
|
61
|
+
- Avoid unrelated formatting or churn.
|
|
62
|
+
|
|
63
|
+
## GitHub Actions To Suggest
|
|
64
|
+
|
|
65
|
+
- Commit after tests pass.
|
|
66
|
+
- Use PR review when refactor touches shared behavior.
|
|
67
|
+
- Mention that behavior should remain unchanged in PR or release notes.
|
|
68
|
+
|
|
69
|
+
## Release Path
|
|
70
|
+
|
|
71
|
+
1. Confirm baseline.
|
|
72
|
+
2. Refactor safely.
|
|
73
|
+
3. Verify no behavior change.
|
|
74
|
+
4. Prepare future-change guide.
|
|
75
|
+
5. Ask approval for GitHub operations.
|
|
76
|
+
|
|
77
|
+
## Final Handoff Shape
|
|
78
|
+
|
|
79
|
+
```md
|
|
80
|
+
Current team:
|
|
81
|
+
Refactor scope:
|
|
82
|
+
Behavior preserved:
|
|
83
|
+
Evidence/artifacts:
|
|
84
|
+
Checks run:
|
|
85
|
+
Files changed:
|
|
86
|
+
Residual risk:
|
|
87
|
+
Next recommended action:
|
|
88
|
+
Permission needed:
|
|
89
|
+
```
|
|
90
|
+
|
|
@@ -0,0 +1,90 @@
|
|
|
1
|
+
# Example: Production Bugfix To Release
|
|
2
|
+
|
|
3
|
+
## User Prompt
|
|
4
|
+
|
|
5
|
+
```text
|
|
6
|
+
Sagaz: fix this production bug, test it, and prepare a GitHub release.
|
|
7
|
+
|
|
8
|
+
Bug:
|
|
9
|
+
Users cannot complete checkout when discount code is empty.
|
|
10
|
+
```
|
|
11
|
+
|
|
12
|
+
## Selected Workflow
|
|
13
|
+
|
|
14
|
+
`workflows/bugfix-to-release.md`
|
|
15
|
+
|
|
16
|
+
## Required Squads
|
|
17
|
+
|
|
18
|
+
- `squads/code-audit.md`
|
|
19
|
+
- `squads/production-critical.md`
|
|
20
|
+
- `squads/github-ops.md`
|
|
21
|
+
|
|
22
|
+
## First Actions
|
|
23
|
+
|
|
24
|
+
1. Inspect current git status.
|
|
25
|
+
2. Reproduce or characterize the bug.
|
|
26
|
+
3. Identify scope and likely affected files.
|
|
27
|
+
4. Create or update run state if the fix is multi-step or production critical.
|
|
28
|
+
5. Ask before changing code if the reproduction path is unclear.
|
|
29
|
+
|
|
30
|
+
## Stack Recommendation
|
|
31
|
+
|
|
32
|
+
Use the existing project stack. Do not introduce new dependencies unless the bug cannot be fixed safely without them.
|
|
33
|
+
|
|
34
|
+
## Handoff Sequence
|
|
35
|
+
|
|
36
|
+
| Phase | From | To | Evidence |
|
|
37
|
+
| --- | --- | --- | --- |
|
|
38
|
+
| Triage | code-audit | production-critical | reproduction, root cause, affected files |
|
|
39
|
+
| Fix | production-critical | production-critical | minimal patch, regression test |
|
|
40
|
+
| Verification | production-critical | github-ops | test output, risk notes, release recommendation |
|
|
41
|
+
| Release | github-ops | complete | commit, push, tag or release only after approval |
|
|
42
|
+
|
|
43
|
+
## Expected Artifacts
|
|
44
|
+
|
|
45
|
+
- Reproduction notes.
|
|
46
|
+
- Root cause summary.
|
|
47
|
+
- Minimal code diff.
|
|
48
|
+
- Regression test or manual verification evidence.
|
|
49
|
+
- `templates/qa-report.md`.
|
|
50
|
+
- `templates/release-notes.md` when a release is prepared.
|
|
51
|
+
|
|
52
|
+
## Verification Plan
|
|
53
|
+
|
|
54
|
+
- Test the failing path before and after the fix.
|
|
55
|
+
- Add regression coverage when feasible.
|
|
56
|
+
- Run the smallest relevant test suite first.
|
|
57
|
+
- Run broader checks when checkout, auth, payment, or data integrity may be affected.
|
|
58
|
+
- Smoke test release candidate.
|
|
59
|
+
|
|
60
|
+
## GitHub Actions To Suggest
|
|
61
|
+
|
|
62
|
+
- Commit after verification.
|
|
63
|
+
- Push after approval.
|
|
64
|
+
- Create a GitHub release only when the fix is ready for users.
|
|
65
|
+
- Include risk and rollback notes in release notes.
|
|
66
|
+
|
|
67
|
+
## Release Path
|
|
68
|
+
|
|
69
|
+
1. Confirm fix scope.
|
|
70
|
+
2. Run checks.
|
|
71
|
+
3. Prepare release notes.
|
|
72
|
+
4. Ask approval for commit and push.
|
|
73
|
+
5. Ask approval for tag or GitHub release.
|
|
74
|
+
6. Monitor post-release if production risk is meaningful.
|
|
75
|
+
|
|
76
|
+
## Final Handoff Shape
|
|
77
|
+
|
|
78
|
+
```md
|
|
79
|
+
Current team:
|
|
80
|
+
Bug:
|
|
81
|
+
Root cause:
|
|
82
|
+
Fix:
|
|
83
|
+
Evidence/artifacts:
|
|
84
|
+
Checks run:
|
|
85
|
+
Release status:
|
|
86
|
+
Rollback:
|
|
87
|
+
Residual risk:
|
|
88
|
+
Permission needed:
|
|
89
|
+
```
|
|
90
|
+
|
|
@@ -0,0 +1,111 @@
|
|
|
1
|
+
# Example: Mobile Habit Tracker
|
|
2
|
+
|
|
3
|
+
## User Prompt
|
|
4
|
+
|
|
5
|
+
```text
|
|
6
|
+
Sagaz: create an Android/iOS habit tracker with premium UX and store-ready release planning.
|
|
7
|
+
|
|
8
|
+
Requirements:
|
|
9
|
+
- daily habits
|
|
10
|
+
- streaks
|
|
11
|
+
- reminders
|
|
12
|
+
- offline support
|
|
13
|
+
- clean design
|
|
14
|
+
- future account sync
|
|
15
|
+
```
|
|
16
|
+
|
|
17
|
+
## Selected Workflow
|
|
18
|
+
|
|
19
|
+
`workflows/mobile-app-production.md`
|
|
20
|
+
|
|
21
|
+
## Required Squads
|
|
22
|
+
|
|
23
|
+
- `squads/mobile-app-studio.md`
|
|
24
|
+
- `squads/design-studio.md`
|
|
25
|
+
- `squads/production-critical.md`
|
|
26
|
+
- `squads/github-ops.md`
|
|
27
|
+
|
|
28
|
+
## First Actions
|
|
29
|
+
|
|
30
|
+
1. Clarify offline-first expectations, reminder behavior, sync timing, and target stores.
|
|
31
|
+
2. Create or update run state from `templates/run-state.md`.
|
|
32
|
+
3. Use `tasks/intake-brief.md`.
|
|
33
|
+
4. Use `tasks/product-requirements.md`.
|
|
34
|
+
5. Use `tasks/stack-recommendation.md`.
|
|
35
|
+
6. Ask before installing mobile dependencies or configuring account-linked services.
|
|
36
|
+
|
|
37
|
+
## Stack Recommendation
|
|
38
|
+
|
|
39
|
+
Default recommendation:
|
|
40
|
+
|
|
41
|
+
- Expo.
|
|
42
|
+
- React Native.
|
|
43
|
+
- TypeScript.
|
|
44
|
+
- Local SQLite or AsyncStorage for offline habits.
|
|
45
|
+
- Supabase later if account sync becomes required.
|
|
46
|
+
- EAS Build when store distribution is needed.
|
|
47
|
+
|
|
48
|
+
Decision points:
|
|
49
|
+
|
|
50
|
+
- Use local-first storage for simple private habits.
|
|
51
|
+
- Use Supabase when cross-device sync or user accounts become required.
|
|
52
|
+
- Use native modules only when Expo support is not enough.
|
|
53
|
+
|
|
54
|
+
## Handoff Sequence
|
|
55
|
+
|
|
56
|
+
| Phase | From | To | Evidence |
|
|
57
|
+
| --- | --- | --- | --- |
|
|
58
|
+
| Intake | mobile-app-studio | design-studio | platform targets, offline rules, notification rules |
|
|
59
|
+
| UX | design-studio | mobile-app-studio | screen map, states, design system, accessibility notes |
|
|
60
|
+
| Build | mobile-app-studio | production-critical | implementation evidence, device checks |
|
|
61
|
+
| Release | production-critical | github-ops | store checklist, QA report, release notes |
|
|
62
|
+
|
|
63
|
+
## Expected Artifacts
|
|
64
|
+
|
|
65
|
+
- `templates/product-spec.md`.
|
|
66
|
+
- `templates/stack-recommendation.md`.
|
|
67
|
+
- `templates/design-system-spec.md`.
|
|
68
|
+
- `templates/mobile-release-checklist.md`.
|
|
69
|
+
- `templates/qa-report.md`.
|
|
70
|
+
- `templates/future-change-guide.md`.
|
|
71
|
+
- `templates/final-handoff.md`.
|
|
72
|
+
|
|
73
|
+
## Verification Plan
|
|
74
|
+
|
|
75
|
+
- Typecheck and lint.
|
|
76
|
+
- Unit tests for habit streak logic.
|
|
77
|
+
- Manual simulator checks on small and large screens.
|
|
78
|
+
- Offline behavior check.
|
|
79
|
+
- Notification permission and fallback check.
|
|
80
|
+
- Accessibility checks for tap targets, contrast, labels, and dynamic text.
|
|
81
|
+
- EAS readiness review before store release.
|
|
82
|
+
|
|
83
|
+
## GitHub Actions To Suggest
|
|
84
|
+
|
|
85
|
+
- Commit once local checks pass.
|
|
86
|
+
- Push after mobile release checklist is current.
|
|
87
|
+
- Use GitHub release only when the build is ready for testers or stores.
|
|
88
|
+
|
|
89
|
+
## Release Path
|
|
90
|
+
|
|
91
|
+
1. Confirm bundle identifiers and app metadata.
|
|
92
|
+
2. Prepare icon and splash assets.
|
|
93
|
+
3. Configure EAS.
|
|
94
|
+
4. Produce internal build.
|
|
95
|
+
5. Run smoke tests.
|
|
96
|
+
6. Prepare store checklist.
|
|
97
|
+
7. Ask approval before external submission.
|
|
98
|
+
|
|
99
|
+
## Final Handoff Shape
|
|
100
|
+
|
|
101
|
+
```md
|
|
102
|
+
Current team:
|
|
103
|
+
What was completed:
|
|
104
|
+
Evidence/artifacts:
|
|
105
|
+
Device checks:
|
|
106
|
+
Release readiness:
|
|
107
|
+
Risks or pending items:
|
|
108
|
+
Next recommended action:
|
|
109
|
+
Permission needed:
|
|
110
|
+
```
|
|
111
|
+
|