sagaz-ai 0.2.0 → 0.3.1
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 +117 -1
- package/README.md +8 -0
- package/RELEASE_NOTES.md +23 -31
- package/ai-orchestration-ecosystem/ADOPTION.md +178 -0
- package/ai-orchestration-ecosystem/INDEX.md +24 -0
- package/ai-orchestration-ecosystem/README.md +18 -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 +19 -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 +185 -1
package/CHANGELOG.md
CHANGED
|
@@ -1,5 +1,122 @@
|
|
|
1
1
|
# Changelog
|
|
2
2
|
|
|
3
|
+
## [0.3.1] - 2026-06-11
|
|
4
|
+
|
|
5
|
+
### Release Type
|
|
6
|
+
|
|
7
|
+
Patch
|
|
8
|
+
|
|
9
|
+
### Added
|
|
10
|
+
|
|
11
|
+
- Sagaz adoption guide for first use in another project, team onboarding, invocation prompts, cross-platform notes, permission model, and evidence expectations.
|
|
12
|
+
|
|
13
|
+
### Changed
|
|
14
|
+
|
|
15
|
+
- README, ecosystem README, INDEX, manifest, and package verifier now register the adoption guide as an official ecosystem document.
|
|
16
|
+
|
|
17
|
+
### Fixed
|
|
18
|
+
|
|
19
|
+
- None.
|
|
20
|
+
|
|
21
|
+
### Removed
|
|
22
|
+
|
|
23
|
+
- None.
|
|
24
|
+
|
|
25
|
+
### Security
|
|
26
|
+
|
|
27
|
+
- No security changes.
|
|
28
|
+
|
|
29
|
+
### Compatibility
|
|
30
|
+
|
|
31
|
+
- Windows: supported through Codex Desktop.
|
|
32
|
+
- macOS: supported through Codex Desktop.
|
|
33
|
+
- Node.js: package baseline remains `>=22.14`; Node.js 24 is preferred for new installs and CI.
|
|
34
|
+
- Codex Desktop: Sagaz remains a Codex Desktop orchestration skill, not a standalone terminal agent runtime.
|
|
35
|
+
|
|
36
|
+
### Migration Notes
|
|
37
|
+
|
|
38
|
+
- Existing users should run `npx sagaz-ai@0.3.1 sync` or `npx sagaz-ai sync` to refresh the installed Codex Desktop skill.
|
|
39
|
+
- Open a new Codex Desktop thread after syncing so the updated skill can be discovered.
|
|
40
|
+
|
|
41
|
+
### Verification
|
|
42
|
+
|
|
43
|
+
- npm test: passed locally on Windows.
|
|
44
|
+
- npm run doctor: passed locally on Windows with `Synchronized with source: yes`.
|
|
45
|
+
- npm pack --dry-run: passed locally on Windows after allowing npm cache access outside the sandbox.
|
|
46
|
+
- Windows: prepared from a Windows Codex Desktop workspace.
|
|
47
|
+
- macOS: package checks remain covered by GitHub Actions.
|
|
48
|
+
- Codex Desktop: skill sync remains required after install or upgrade.
|
|
49
|
+
|
|
50
|
+
### Release Evidence
|
|
51
|
+
|
|
52
|
+
- Commit: pending.
|
|
53
|
+
- Tag: pending.
|
|
54
|
+
- GitHub release: pending.
|
|
55
|
+
- npm package: pending.
|
|
56
|
+
|
|
57
|
+
## [0.3.0] - 2026-06-11
|
|
58
|
+
|
|
59
|
+
### Release Type
|
|
60
|
+
|
|
61
|
+
Minor
|
|
62
|
+
|
|
63
|
+
### Added
|
|
64
|
+
|
|
65
|
+
- Operations runbook for daily starts, project starts, resumes, handoffs, verification, releases, GitHub operations, and stop conditions.
|
|
66
|
+
- Complete examples library covering web SaaS on Vercel, mobile habit tracking, production bugfix releases, and brownfield refactors.
|
|
67
|
+
- Capabilities matrix comparing Sagaz with common orchestration systems and identifying what Sagaz now covers or intentionally defers.
|
|
68
|
+
- Formal permission contract with approval levels for local edits, installs, network access, GitHub operations, releases, secrets, and destructive actions.
|
|
69
|
+
- Stack playbooks for Next.js/Vercel/Supabase, React/Vite/static hosting, Expo/EAS, Node APIs, and Firebase.
|
|
70
|
+
- Execution trace template and stronger observability contract for commands, decisions, failures, handoffs, and release evidence.
|
|
71
|
+
- MCP connector policy for Figma, GitHub, browser automation, deployment providers, databases, Canva, npm registries, observability, and AI providers.
|
|
72
|
+
|
|
73
|
+
### Changed
|
|
74
|
+
|
|
75
|
+
- `npm test` now validates stack playbooks, permission policy, execution trace requirements, observability rules, and MCP connector policy coverage.
|
|
76
|
+
- README, INDEX, manifest, tool registry, run-state template, and Sagaz skill instructions now expose the new governance and connector contracts.
|
|
77
|
+
- Release governance now requires stronger evidence around permissions, connector usage, workflow traceability, and stack-specific verification.
|
|
78
|
+
|
|
79
|
+
### Fixed
|
|
80
|
+
|
|
81
|
+
- Filled remaining non-CLI governance gaps identified after the 0.2.0 release.
|
|
82
|
+
- Reduced ambiguity around cross-platform execution on Windows and macOS inside Codex Desktop.
|
|
83
|
+
|
|
84
|
+
### Removed
|
|
85
|
+
|
|
86
|
+
- None.
|
|
87
|
+
|
|
88
|
+
### Security
|
|
89
|
+
|
|
90
|
+
- Added explicit permission levels for secrets, destructive actions, external publishing, GitHub operations, package registries, and MCP connectors.
|
|
91
|
+
|
|
92
|
+
### Compatibility
|
|
93
|
+
|
|
94
|
+
- Windows: supported through Codex Desktop and locally verified on Windows.
|
|
95
|
+
- macOS: supported through Codex Desktop and covered by GitHub Actions package checks.
|
|
96
|
+
- Node.js: package baseline remains `>=22.14`; Node.js 24 is preferred for new installs and CI.
|
|
97
|
+
- Codex Desktop: Sagaz remains a Codex Desktop orchestration skill, not a standalone terminal agent runtime.
|
|
98
|
+
|
|
99
|
+
### Migration Notes
|
|
100
|
+
|
|
101
|
+
- Existing users should run `npx sagaz-ai@0.3.0 sync` or `npx sagaz-ai sync` to refresh the installed Codex Desktop skill.
|
|
102
|
+
- Open a new Codex Desktop thread after syncing so the updated skill can be discovered.
|
|
103
|
+
|
|
104
|
+
### Verification
|
|
105
|
+
|
|
106
|
+
- npm test: passed locally on Windows.
|
|
107
|
+
- npm run doctor: passed locally on Windows with `Synchronized with source: yes`.
|
|
108
|
+
- npm pack --dry-run: passed locally on Windows after allowing npm cache access outside the sandbox.
|
|
109
|
+
- Windows: prepared and verified from a Windows Codex Desktop workspace.
|
|
110
|
+
- macOS: package checks remain covered by GitHub Actions.
|
|
111
|
+
- Codex Desktop: skill sync remains required after install or upgrade.
|
|
112
|
+
|
|
113
|
+
### Release Evidence
|
|
114
|
+
|
|
115
|
+
- Commit: pending.
|
|
116
|
+
- Tag: pending.
|
|
117
|
+
- GitHub release: pending.
|
|
118
|
+
- npm package: pending.
|
|
119
|
+
|
|
3
120
|
## [0.2.0] - 2026-06-08
|
|
4
121
|
|
|
5
122
|
### Release Type
|
|
@@ -64,4 +181,3 @@ Minor
|
|
|
64
181
|
- Tag: pending.
|
|
65
182
|
- GitHub release: pending.
|
|
66
183
|
- npm package: pending.
|
|
67
|
-
|
package/README.md
CHANGED
|
@@ -168,6 +168,14 @@ Then open a new Codex Desktop thread and run:
|
|
|
168
168
|
Sagaz: explain the available workflows.
|
|
169
169
|
```
|
|
170
170
|
|
|
171
|
+
For the first real use in another project, start with:
|
|
172
|
+
|
|
173
|
+
```text
|
|
174
|
+
Sagaz: audit this project and tell me what workflow, stack playbook, risks, tests, and next implementation step you recommend. Do not change files yet.
|
|
175
|
+
```
|
|
176
|
+
|
|
177
|
+
The detailed adoption guide lives at `ai-orchestration-ecosystem/ADOPTION.md`.
|
|
178
|
+
|
|
171
179
|
### Manual Installation
|
|
172
180
|
|
|
173
181
|
#### 1. Clone Or Download The Repository
|
package/RELEASE_NOTES.md
CHANGED
|
@@ -2,9 +2,9 @@
|
|
|
2
2
|
|
|
3
3
|
## Release
|
|
4
4
|
|
|
5
|
-
Version: 0.
|
|
6
|
-
Date: 2026-06-
|
|
7
|
-
Release type:
|
|
5
|
+
Version: 0.3.1
|
|
6
|
+
Date: 2026-06-11
|
|
7
|
+
Release type: Patch
|
|
8
8
|
GitHub commit: pending
|
|
9
9
|
Git tag: pending
|
|
10
10
|
GitHub release: pending
|
|
@@ -12,38 +12,32 @@ npm package: pending
|
|
|
12
12
|
|
|
13
13
|
## Summary
|
|
14
14
|
|
|
15
|
-
Sagaz 0.
|
|
15
|
+
Sagaz 0.3.1 adds the official adoption guide for using Sagaz in another project after installation. It documents the first-use flow, team operating model, invocation prompts, Windows/macOS notes, permission expectations, and evidence artifacts.
|
|
16
16
|
|
|
17
17
|
## Audience Impact
|
|
18
18
|
|
|
19
|
-
- New users: clearer
|
|
20
|
-
- Existing users:
|
|
21
|
-
-
|
|
22
|
-
-
|
|
23
|
-
- Engineering team: workflows now behave more like formal contracts with gates, state, handoffs, and evidence.
|
|
19
|
+
- New users: clearer first real step after installing Sagaz.
|
|
20
|
+
- Existing users: can sync the installed skill and follow the adoption guide from a fresh Codex Desktop thread.
|
|
21
|
+
- Teams: get a practical onboarding path before applying Sagaz to production work.
|
|
22
|
+
- Maintainers: package validation now tracks the adoption guide in the ecosystem manifest.
|
|
24
23
|
|
|
25
24
|
## What Changed
|
|
26
25
|
|
|
27
|
-
- Added `
|
|
28
|
-
-
|
|
29
|
-
-
|
|
30
|
-
-
|
|
31
|
-
- Added GitHub Actions package checks across Linux, Windows, and macOS.
|
|
32
|
-
- Added formal changelog and release notes templates.
|
|
33
|
-
- Added installed skill sync protocol and CLI command.
|
|
34
|
-
- Strengthened workflow, task, run-state, and evaluation contracts.
|
|
26
|
+
- Added `ai-orchestration-ecosystem/ADOPTION.md`.
|
|
27
|
+
- Linked the adoption guide from the root README, ecosystem README, and ecosystem INDEX.
|
|
28
|
+
- Registered the adoption guide in `manifest.json`.
|
|
29
|
+
- Updated package verification so the docs group validates the new guide.
|
|
35
30
|
|
|
36
31
|
## Why It Matters
|
|
37
32
|
|
|
38
|
-
Sagaz
|
|
33
|
+
After `0.3.0`, Sagaz had strong governance but needed a direct bridge between installation and first use in a real project. This patch gives teams a safe starting prompt, explains what Sagaz should inspect first, and reinforces permission gates before risky actions.
|
|
39
34
|
|
|
40
35
|
## Compatibility
|
|
41
36
|
|
|
42
|
-
- Windows: supported
|
|
43
|
-
- macOS: supported through Codex Desktop
|
|
37
|
+
- Windows: supported through Codex Desktop.
|
|
38
|
+
- macOS: supported through Codex Desktop.
|
|
44
39
|
- Node.js: `>=22.14` remains the package minimum; Node.js 24 is preferred for new installs and CI.
|
|
45
40
|
- Codex Desktop: required.
|
|
46
|
-
- GitHub Actions: package checks run on Ubuntu, Windows, and macOS.
|
|
47
41
|
- npm package: still an installer/distribution package, not a standalone Sagaz runtime.
|
|
48
42
|
|
|
49
43
|
## Migration Notes
|
|
@@ -51,7 +45,7 @@ Sagaz is now harder to accidentally drift, release, or publish in an inconsisten
|
|
|
51
45
|
Run:
|
|
52
46
|
|
|
53
47
|
```bash
|
|
54
|
-
npx sagaz-ai sync
|
|
48
|
+
npx sagaz-ai@0.3.1 sync
|
|
55
49
|
npx sagaz-ai doctor
|
|
56
50
|
```
|
|
57
51
|
|
|
@@ -59,16 +53,15 @@ Then open a new Codex Desktop thread so Sagaz is rediscovered.
|
|
|
59
53
|
|
|
60
54
|
## Verification
|
|
61
55
|
|
|
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
|
-
-
|
|
66
|
-
- Manual checks: Git status reviewed before release preparation.
|
|
56
|
+
- `npm test`: passed locally on Windows.
|
|
57
|
+
- `npm run doctor`: passed locally on Windows with installed skill synchronization confirmed.
|
|
58
|
+
- `npm pack --dry-run`: passed locally on Windows after npm cache access was allowed outside the sandbox.
|
|
59
|
+
- Manual checks: adoption guide linked from README, INDEX, and manifest.
|
|
67
60
|
|
|
68
61
|
## Known Limitations
|
|
69
62
|
|
|
70
|
-
-
|
|
71
|
-
-
|
|
63
|
+
- Sagaz still intentionally skips a standalone CLI runtime; Codex Desktop remains the execution surface.
|
|
64
|
+
- Connector behavior depends on each external MCP/app authorization and platform availability.
|
|
72
65
|
|
|
73
66
|
## Rollback Plan
|
|
74
67
|
|
|
@@ -79,6 +72,5 @@ Then open a new Codex Desktop thread so Sagaz is rediscovered.
|
|
|
79
72
|
## Release Decision
|
|
80
73
|
|
|
81
74
|
Approved by: Thiago Cabral
|
|
82
|
-
Approval date: 2026-06-
|
|
75
|
+
Approval date: 2026-06-11
|
|
83
76
|
Residual risk: GitHub Actions and npm publishing still need remote execution after push.
|
|
84
|
-
|
|
@@ -0,0 +1,178 @@
|
|
|
1
|
+
# Sagaz Adoption Guide
|
|
2
|
+
|
|
3
|
+
Use this guide when starting Sagaz in another project or onboarding a team to Sagaz inside Codex Desktop.
|
|
4
|
+
|
|
5
|
+
## Purpose
|
|
6
|
+
|
|
7
|
+
This guide gives a practical first-use path for teams that want Sagaz to orchestrate product, design, implementation, verification, GitHub operations, and release readiness in an existing or new project.
|
|
8
|
+
|
|
9
|
+
It assumes Sagaz is already installed with `npx sagaz-ai install` or `npx sagaz-ai sync`.
|
|
10
|
+
|
|
11
|
+
## Requirements
|
|
12
|
+
|
|
13
|
+
- Codex Desktop on Windows or macOS.
|
|
14
|
+
- Node.js `22.14+`; Node.js 24 LTS is preferred.
|
|
15
|
+
- npm available in the terminal.
|
|
16
|
+
- Git installed when the project is version controlled.
|
|
17
|
+
- GitHub CLI (`gh`) when Sagaz should create branches, pull requests, issues, releases, or inspect checks.
|
|
18
|
+
- Project-specific tools already installed or approved for installation, such as `pnpm`, `yarn`, `bun`, Expo/EAS, Android Studio, Xcode, Supabase CLI, Firebase CLI, Vercel CLI, or test browsers.
|
|
19
|
+
|
|
20
|
+
Before starting a real project, run:
|
|
21
|
+
|
|
22
|
+
```bash
|
|
23
|
+
npx sagaz-ai doctor
|
|
24
|
+
```
|
|
25
|
+
|
|
26
|
+
If the installed skill is out of sync, run:
|
|
27
|
+
|
|
28
|
+
```bash
|
|
29
|
+
npx sagaz-ai sync
|
|
30
|
+
```
|
|
31
|
+
|
|
32
|
+
Then open a new Codex Desktop thread so the refreshed skill is discovered.
|
|
33
|
+
|
|
34
|
+
## First Use In Another Project
|
|
35
|
+
|
|
36
|
+
1. Open the target project folder in Codex Desktop.
|
|
37
|
+
2. Start a new thread after installing or syncing Sagaz.
|
|
38
|
+
3. Invoke Sagaz with a direct goal and any known constraints.
|
|
39
|
+
4. Let Sagaz inspect the project before making changes.
|
|
40
|
+
5. Approve each major handoff, external operation, dependency install, GitHub operation, deployment, package publish, or destructive action.
|
|
41
|
+
6. Keep the final handoff and run-state artifacts inside the project when the work is meaningful or long-lived.
|
|
42
|
+
|
|
43
|
+
## Invocation Pattern
|
|
44
|
+
|
|
45
|
+
Use `Sagaz:` at the beginning of the message.
|
|
46
|
+
|
|
47
|
+
For a new product:
|
|
48
|
+
|
|
49
|
+
```text
|
|
50
|
+
Sagaz: create a production-ready web SaaS for appointment scheduling.
|
|
51
|
+
|
|
52
|
+
Requirements:
|
|
53
|
+
- user login
|
|
54
|
+
- calendar scheduling
|
|
55
|
+
- admin dashboard
|
|
56
|
+
- premium but practical UI
|
|
57
|
+
- deployment on Vercel
|
|
58
|
+
- GitHub release flow
|
|
59
|
+
```
|
|
60
|
+
|
|
61
|
+
For an existing project:
|
|
62
|
+
|
|
63
|
+
```text
|
|
64
|
+
Sagaz: inspect this project and prepare a safe implementation plan before changing code.
|
|
65
|
+
|
|
66
|
+
Goal:
|
|
67
|
+
- add subscription billing
|
|
68
|
+
- preserve the current UX
|
|
69
|
+
- use the existing stack when reasonable
|
|
70
|
+
- include tests and deployment notes
|
|
71
|
+
```
|
|
72
|
+
|
|
73
|
+
For a bug:
|
|
74
|
+
|
|
75
|
+
```text
|
|
76
|
+
Sagaz: diagnose and fix the production checkout failure.
|
|
77
|
+
|
|
78
|
+
Rules:
|
|
79
|
+
- identify likely root cause first
|
|
80
|
+
- make the smallest safe fix
|
|
81
|
+
- run focused tests
|
|
82
|
+
- prepare a release handoff
|
|
83
|
+
```
|
|
84
|
+
|
|
85
|
+
For design work with Figma MCP:
|
|
86
|
+
|
|
87
|
+
```text
|
|
88
|
+
Sagaz: coordinate the design team using Figma MCP to create app-like mockups that can be inspected as real application flows.
|
|
89
|
+
|
|
90
|
+
Include:
|
|
91
|
+
- target users
|
|
92
|
+
- main screens
|
|
93
|
+
- component states
|
|
94
|
+
- interaction notes
|
|
95
|
+
- visual QA checklist
|
|
96
|
+
```
|
|
97
|
+
|
|
98
|
+
## Recommended First Response From Sagaz
|
|
99
|
+
|
|
100
|
+
Sagaz should respond with:
|
|
101
|
+
|
|
102
|
+
- The selected workflow.
|
|
103
|
+
- The selected squad or agents.
|
|
104
|
+
- The assumptions it is making.
|
|
105
|
+
- The files, commands, or connectors it needs to inspect.
|
|
106
|
+
- The permission level required for the next step.
|
|
107
|
+
- The expected first handoff artifact.
|
|
108
|
+
|
|
109
|
+
Sagaz should avoid starting large implementation work before it understands the project structure, stack, risks, and definition of done.
|
|
110
|
+
|
|
111
|
+
## Team Operating Model
|
|
112
|
+
|
|
113
|
+
Use this rhythm for team adoption:
|
|
114
|
+
|
|
115
|
+
1. Product confirms objective, users, constraints, and definition of done.
|
|
116
|
+
2. Technology confirms stack, architecture, dependencies, and operating costs.
|
|
117
|
+
3. Design confirms UX, UI system, accessibility, responsiveness, and visual QA expectations.
|
|
118
|
+
4. Engineering implements in small verifiable steps.
|
|
119
|
+
5. QA verifies behavior, regressions, accessibility, build, and deployment readiness.
|
|
120
|
+
6. GitHub Ops prepares commit, branch, pull request, checks, release notes, tag, and release when approved.
|
|
121
|
+
7. The final handoff records evidence, residual risk, rollback plan, and next recommended work.
|
|
122
|
+
|
|
123
|
+
## Cross-Platform Notes
|
|
124
|
+
|
|
125
|
+
Sagaz should treat Windows and macOS as first-class Codex Desktop environments.
|
|
126
|
+
|
|
127
|
+
- Prefer commands that work in the user's current shell.
|
|
128
|
+
- Use PowerShell syntax on Windows and POSIX shell syntax on macOS.
|
|
129
|
+
- Record when a command or dependency is platform-specific.
|
|
130
|
+
- Verify path examples before presenting them.
|
|
131
|
+
- Do not assume Linux-only tooling unless the project or CI requires it.
|
|
132
|
+
|
|
133
|
+
## Permission Model
|
|
134
|
+
|
|
135
|
+
Sagaz follows `protocols/permission-contract.md`.
|
|
136
|
+
|
|
137
|
+
Low-risk inspection can usually proceed directly. These actions require explicit approval:
|
|
138
|
+
|
|
139
|
+
- Installing dependencies.
|
|
140
|
+
- Writing or deleting files when implementation has not been clearly authorized.
|
|
141
|
+
- Running commands that access networked registries or external services.
|
|
142
|
+
- Creating, pushing, tagging, or releasing in GitHub.
|
|
143
|
+
- Deploying to hosting providers.
|
|
144
|
+
- Publishing packages.
|
|
145
|
+
- Handling secrets, credentials, production data, billing, or destructive operations.
|
|
146
|
+
|
|
147
|
+
## Evidence To Keep
|
|
148
|
+
|
|
149
|
+
For serious work, Sagaz should maintain or produce:
|
|
150
|
+
|
|
151
|
+
- `templates/run-state.md`
|
|
152
|
+
- `templates/execution-trace.md`
|
|
153
|
+
- `templates/implementation-plan.md`
|
|
154
|
+
- `templates/qa-report.md`
|
|
155
|
+
- `templates/final-handoff.md`
|
|
156
|
+
- `templates/future-change-guide.md`
|
|
157
|
+
- `templates/release-notes.md` when release work is involved.
|
|
158
|
+
|
|
159
|
+
## Good First Team Exercise
|
|
160
|
+
|
|
161
|
+
Use a low-risk existing repository and ask:
|
|
162
|
+
|
|
163
|
+
```text
|
|
164
|
+
Sagaz: audit this project and tell me what workflow, stack playbook, risks, tests, and next implementation step you recommend. Do not change files yet.
|
|
165
|
+
```
|
|
166
|
+
|
|
167
|
+
This verifies that the team understands Sagaz handoffs, permission gates, stack reasoning, and evidence before using it on production work.
|
|
168
|
+
|
|
169
|
+
## Success Criteria
|
|
170
|
+
|
|
171
|
+
Sagaz adoption is working when:
|
|
172
|
+
|
|
173
|
+
- The team can invoke Sagaz consistently in new and existing projects.
|
|
174
|
+
- Sagaz chooses workflows and stack playbooks without bloating context.
|
|
175
|
+
- The team sees clear permission prompts before risky actions.
|
|
176
|
+
- Handoffs explain what changed, what was verified, and what remains risky.
|
|
177
|
+
- GitHub, design, deployment, and package operations happen only after approval.
|
|
178
|
+
- Windows and macOS users can follow the same operating model with platform-appropriate commands.
|
|
@@ -3,6 +3,7 @@
|
|
|
3
3
|
## Quick Entry
|
|
4
4
|
|
|
5
5
|
- `ACTIVATE.md`: ready-to-use activation prompts.
|
|
6
|
+
- `ADOPTION.md`: first-use guide for adopting Sagaz in another project or team.
|
|
6
7
|
- `quickstart.md`: minimum operating rules.
|
|
7
8
|
- `README.md`: ecosystem overview.
|
|
8
9
|
- `manifest.json`: internal component registry for validation and navigation.
|
|
@@ -71,6 +72,8 @@ See `protocols/` for quality gates, testing matrix, stack selection, design qual
|
|
|
71
72
|
- `protocols/installed-skill-sync.md`
|
|
72
73
|
- `protocols/memory.md`
|
|
73
74
|
- `protocols/model-routing.md`
|
|
75
|
+
- `protocols/mcp-connector-policy.md`
|
|
76
|
+
- `protocols/permission-contract.md`
|
|
74
77
|
- `protocols/post-delivery-monitoring.md`
|
|
75
78
|
|
|
76
79
|
## Tools
|
|
@@ -89,6 +92,15 @@ See `protocols/` for quality gates, testing matrix, stack selection, design qual
|
|
|
89
92
|
- `stack-presets/static-site.md`
|
|
90
93
|
- `stack-presets/admin-dashboard.md`
|
|
91
94
|
|
|
95
|
+
## Stack Playbooks
|
|
96
|
+
|
|
97
|
+
- `stack-playbooks/README.md`
|
|
98
|
+
- `stack-playbooks/nextjs-vercel-supabase.md`
|
|
99
|
+
- `stack-playbooks/react-vite-static.md`
|
|
100
|
+
- `stack-playbooks/expo-eas.md`
|
|
101
|
+
- `stack-playbooks/node-api.md`
|
|
102
|
+
- `stack-playbooks/firebase.md`
|
|
103
|
+
|
|
92
104
|
## Evaluations
|
|
93
105
|
|
|
94
106
|
- `evals/sagaz-evaluation-suite.md`
|
|
@@ -96,16 +108,28 @@ See `protocols/` for quality gates, testing matrix, stack selection, design qual
|
|
|
96
108
|
## Examples
|
|
97
109
|
|
|
98
110
|
- `examples/README.md`
|
|
111
|
+
- `examples/web-saas-vercel.md`
|
|
112
|
+
- `examples/mobile-habit-tracker.md`
|
|
113
|
+
- `examples/bugfix-production-release.md`
|
|
114
|
+
- `examples/brownfield-refactor.md`
|
|
99
115
|
|
|
100
116
|
## Templates
|
|
101
117
|
|
|
102
118
|
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
119
|
|
|
120
|
+
- `templates/execution-trace.md`
|
|
121
|
+
|
|
104
122
|
## Governance
|
|
105
123
|
|
|
124
|
+
- `governance/capabilities-matrix.md`
|
|
125
|
+
- `governance/operations-runbook.md`
|
|
106
126
|
- `governance/quality-policy.md`
|
|
107
127
|
- `governance/security-policy.md`
|
|
108
128
|
- `governance/versioning.md`
|
|
109
129
|
- `governance/ecosystem-maintenance.md`
|
|
110
130
|
- `governance/package-release-policy.md`
|
|
131
|
+
|
|
132
|
+
## Adoption
|
|
133
|
+
|
|
134
|
+
- `ADOPTION.md`
|
|
111
135
|
|
|
@@ -4,21 +4,26 @@ 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 `ADOPTION.md` when starting Sagaz in another project or onboarding a team.
|
|
9
|
+
3. Read `quickstart.md`.
|
|
10
|
+
4. Choose the smallest sufficient workflow or squad.
|
|
11
|
+
5. Use formal tasks, handoffs, and quality gates.
|
|
12
|
+
6. Create or update run state for medium/large work.
|
|
13
|
+
7. Verify before declaring done.
|
|
12
14
|
|
|
13
15
|
## Structure
|
|
14
16
|
|
|
15
17
|
- `manifest.json`: internal component registry used to validate and navigate the ecosystem.
|
|
18
|
+
- `ADOPTION.md`: first-use guide for adopting Sagaz in another project or team.
|
|
16
19
|
- `workflows/`: named end-to-end flows.
|
|
17
20
|
- `squads/`: specialized teams.
|
|
18
21
|
- `agents/`: role definitions.
|
|
19
22
|
- `tasks/`: formal task contracts.
|
|
20
23
|
- `protocols/`: operating rules and quality gates.
|
|
24
|
+
- `stack-playbooks/`: operational guides for common stack implementation, verification, and deployment.
|
|
21
25
|
- `templates/`: reusable Markdown artifacts.
|
|
26
|
+
- `examples/`: complete web, mobile, bugfix, and refactor flow examples.
|
|
22
27
|
- `engineering/`: software engineering standards.
|
|
23
28
|
- `governance/`: quality, security, and maintenance policies.
|
|
24
29
|
|
|
@@ -34,6 +39,14 @@ Use `protocols/release-versioning-gate.md` before version bumps, Git tags, GitHu
|
|
|
34
39
|
|
|
35
40
|
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
41
|
|
|
42
|
+
Use `governance/capabilities-matrix.md` when comparing Sagaz with CrewAI, AutoGen, LangChain, LangGraph, AIOX, Synkra, or similar orchestration systems.
|
|
43
|
+
|
|
44
|
+
Use `protocols/permission-contract.md` before actions that change local state, remote state, accounts, deployments, packages, credentials, or GitHub history.
|
|
45
|
+
|
|
46
|
+
Use `protocols/agent-observability.md` and `templates/execution-trace.md` for multi-phase, production, release, deployment, package, or high-risk work.
|
|
47
|
+
|
|
48
|
+
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.
|
|
49
|
+
|
|
37
50
|
## Advanced Engineering Coverage
|
|
38
51
|
|
|
39
52
|
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
|
-
```
|