sagaz-ai 0.1.0 → 0.1.1

package/README.md

@@ -36,6 +36,11 @@ Sagaz also guides the user through the process. At the end of each phase, it exp
 - **GitHub without guesswork:** Sagaz recommends commits, pushes, pull requests, issues, and releases at the right time.
 - **Web and mobile:** workflows for browser apps, websites, dashboards, Android, and iOS.
 - **Persistent state:** Markdown run state records decisions, approvals, handoffs, risks, and test evidence.
+- **Agent observability:** compact traces record decisions, tools, evidence, failures, and recoveries.
+- **Durable checkpoints:** long projects can resume across threads and refactors without losing context.
+- **Tool registry:** Sagaz verifies and recommends tools such as GitHub CLI, Playwright, Vercel, Expo/EAS, Supabase, Firebase, Stripe, CI/CD, and observability services.
+- **Stack presets:** common web, mobile, backend, database, and dashboard stacks are documented as starting points.
+- **Sagaz evaluations:** scenario-based checks help prevent regressions in the orchestration system itself.
 
 ## How It Works
 
@@ -52,6 +57,10 @@ Key areas:
 - `agents/`: individual roles.
 - `tasks/`: formal tasks with inputs, outputs, acceptance criteria, verification, and stop conditions.
 - `protocols/`: rules for quality, handoffs, GitHub, production, design, CI/CD, and monitoring.
+- `tools/`: tool and connector selection rules.
+- `stack-presets/`: default stack recommendations and tradeoffs.
+- `evals/`: checks for Sagaz's own reliability.
+- `examples/`: reusable examples of common project flows.
 - `templates/`: reusable artifacts for specs, QA, handoffs, run state, and releases.
 - `engineering/`: deep software engineering standards.
 - `governance/`: security, quality, versioning, and ecosystem maintenance.
@@ -147,6 +156,10 @@ Sagaz should choose the appropriate workflow, create or update persistent run st
 
 For production-grade work, Sagaz can also apply 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 protocols.
 
+For tool-heavy work, Sagaz uses a tool registry to verify local availability and recommend the right connector or platform before asking permission to install, authenticate, deploy, publish, or modify external resources.
+
+For common project types, Sagaz can start from documented stack presets such as Next.js on Vercel, React with Vite, Expo mobile, React Native, Supabase, Firebase, Node APIs, static sites, and admin dashboards.
+
 ## Web Example
 
 ```text
@@ -175,6 +188,8 @@ Sagaz must ask permission before moving between major teams/phases, installing d
 
 Sagaz may directly run low-risk diagnostics such as reading files, inspecting structure, searching text, checking status, and proposing plans.
 
+Sagaz should proactively suggest useful actions across the whole ecosystem, including tests, visual QA, accessibility checks, security checks, commits, releases, deployment previews, monitoring, and documentation updates.
+
 ## Who It Is For
 
 Sagaz is for users who want to build serious software with Codex without needing to personally manage every detail of engineering, design, GitHub, deployment, and production operations.

package/ai-orchestration-ecosystem/INDEX.md

@@ -42,7 +42,7 @@ See `agents/` for Orchestrator, Product Strategist, Technology Strategist, Softw
 
 ## Protocols
 
-See `protocols/` for quality gates, testing matrix, stack selection, design quality, guided proactivity, squad handoffs, production readiness, GitHub operations, CI/CD readiness, post-delivery monitoring, delegation, communication, memory, and model routing.
+See `protocols/` for quality gates, testing matrix, stack selection, design quality, guided proactivity, squad handoffs, production readiness, GitHub operations, CI/CD readiness, post-delivery monitoring, durable run state, agent observability, delegation, communication, memory, and model routing.
 
 ## Advanced Engineering Protocols
 
@@ -58,10 +58,36 @@ See `protocols/` for quality gates, testing matrix, stack selection, design qual
 - `protocols/database-migrations.md`
 - `protocols/release-strategy.md`
 - `protocols/ai-application-quality.md`
+- `protocols/agent-observability.md`
+- `protocols/durable-run-state.md`
+
+## Tools
+
+- `tools/tool-registry.md`
+
+## Stack Presets
+
+- `stack-presets/nextjs-vercel.md`
+- `stack-presets/react-vite.md`
+- `stack-presets/expo-mobile.md`
+- `stack-presets/react-native.md`
+- `stack-presets/supabase.md`
+- `stack-presets/firebase.md`
+- `stack-presets/node-api.md`
+- `stack-presets/static-site.md`
+- `stack-presets/admin-dashboard.md`
+
+## Evaluations
+
+- `evals/sagaz-evaluation-suite.md`
+
+## Examples
+
+- `examples/README.md`
 
 ## Templates
 
-See `templates/` for task briefs, product specs, technical specs, design systems, stack recommendations, run state, squad handoffs, QA reports, release checklists, and final handoffs.
+See `templates/` for task briefs, product specs, technical specs, design systems, stack recommendations, run state, squad handoffs, QA reports, release checklists, changelogs, release notes, and final handoffs.
 
 ## Governance
 

package/ai-orchestration-ecosystem/core/operating-system.md

@@ -26,4 +26,8 @@ Create autonomous, auditable, outcome-oriented AI teams inside Codex with low to
 18. Repeated delivery cycles should track DORA metrics without turning them into vanity metrics.
 19. Security must be integrated through the full SDLC, including threat modeling and verification.
 20. Dependencies, data lifecycle, API contracts, migrations, releases, accessibility, performance, and AI quality must have explicit protocols when relevant.
+21. Durable run state and compact observability must be used for multi-phase or production work.
+22. External tools must be selected through the tool registry: verify availability, explain value, and ask permission before setup or state-changing use.
+23. Stack presets should be used as starting points, then adapted to project constraints.
+24. Sagaz itself must be evaluated with scenario-based checks before major workflow or package releases.
 

package/ai-orchestration-ecosystem/evals/sagaz-evaluation-suite.md

@@ -0,0 +1,71 @@
+# Sagaz Evaluation Suite
+
+## Purpose
+
+Evaluate whether Sagaz itself produces consistent, reliable, low-token, production-oriented results.
+
+## Evaluation Cadence
+
+Run these evaluations before major Sagaz releases and after changing core workflows, squads, protocols, or installation behavior.
+
+## Core Evaluations
+
+| Evaluation | Goal | Pass Criteria |
+| --- | --- | --- |
+| Invocation | Sagaz is easy to start by name | User can invoke Sagaz with one prompt |
+| Language intake | User can write in any language | Sagaz understands the request and answers in American English |
+| Workflow selection | Correct workflow is selected | Selected workflow matches project type and risk |
+| Token discipline | Only needed files are loaded | No broad file loading without reason |
+| Handoff quality | Teams transition clearly | Current work, evidence, next work, and permission are stated |
+| Stack advisory | Stack is justified | Cost, speed, scale, maintainability, deployment, and future changes are covered |
+| Design quality | UI work reaches high standards | Design system, responsiveness, accessibility, and visual QA are included |
+| Verification depth | Tests match risk | Build, lint, unit, integration, e2e, accessibility, and manual checks are considered |
+| GitHub guidance | User is guided proactively | Commits, pushes, PRs, releases, and issues are suggested at the right time |
+| Production readiness | Launch risk is explicit | Security, env vars, rollback, monitoring, and residual risks are documented |
+
+## Scenario Tests
+
+Use these prompts as smoke tests:
+
+```text
+Sagaz: create a complete appointment scheduling SaaS with premium design and Vercel deployment.
+```
+
+```text
+Sagaz: create an Android/iOS habit tracker and recommend the best stack.
+```
+
+```text
+Sagaz: refactor this existing project safely without changing behavior.
+```
+
+```text
+Sagaz: fix this production bug, test it, and prepare a GitHub release.
+```
+
+```text
+Sagaz: I am a beginner. Guide me through everything and ask permission before major actions.
+```
+
+## Scoring
+
+Score each scenario from 0 to 3:
+
+- 0: failed or unsafe
+- 1: partially usable
+- 2: usable with gaps
+- 3: production-grade for the scenario
+
+Sagaz should not release a major workflow change with any core evaluation below 2.
+
+## Regression Log
+
+```md
+Date:
+Version:
+Scenario:
+Score:
+Failure:
+Fix:
+Retest evidence:
+```

package/ai-orchestration-ecosystem/examples/README.md

@@ -0,0 +1,70 @@
+# Examples
+
+## Purpose
+
+Provide reusable, low-token examples for common Sagaz projects. Examples are not templates to copy blindly. They show the expected flow, artifacts, handoffs, and verification depth.
+
+## Example Categories
+
+- complete marketing website
+- SaaS web app
+- admin dashboard
+- mobile app
+- bugfix to release
+- safe refactor
+- production deploy
+- GitHub release
+
+## Example Structure
+
+Each example should include:
+
+- user prompt
+- selected workflow
+- required squads
+- first questions, if any
+- stack recommendation summary
+- handoff sequence
+- expected artifacts
+- verification plan
+- GitHub actions to suggest
+- deployment path
+- final handoff shape
+
+## Minimal Web App Example
+
+```md
+User prompt:
+Sagaz: create a premium appointment scheduling SaaS for small clinics.
+
+Workflow:
+workflows/greenfield-web-app.md
+
+Squads:
+Product Factory -> Design Studio -> Production Critical -> GitHub Ops
+
+Stack recommendation:
+Next.js on Vercel, TypeScript, Supabase, Playwright, GitHub Actions.
+
+Reason:
+Fast delivery, clear deployment path, managed auth/database, strong web ecosystem, good future maintainability.
+
+Required handoffs:
+Intake -> stack -> spec -> design -> architecture -> implementation -> QA -> production readiness -> GitHub/deploy.
+```
+
+## Mobile App Example
+
+```md
+User prompt:
+Sagaz: create an Android/iOS habit tracker with premium UX and store-ready release planning.
+
+Workflow:
+workflows/mobile-app-production.md
+
+Likely stack:
+Expo, React Native, TypeScript, SQLite or Supabase depending on sync needs, EAS for builds.
+
+Required evidence:
+Device-size review, offline behavior decision, accessibility checks, app icon/splash plan, release checklist.
+```

package/ai-orchestration-ecosystem/governance/package-release-policy.md

@@ -16,6 +16,7 @@ When Sagaz changes, update every relevant location:
 - `package.json` version when publishing a package update
 - GitHub repository
 - npm package when the installer or distributed files change
+- GitHub Actions workflows when package checks or publishing rules change
 
 ## Release Checklist
 
@@ -33,6 +34,15 @@ npm publish:
 Post-publish install test:
 ```
 
+## GitHub Actions
+
+The repository should include:
+
+- package checks on push and pull request
+- manual npm publishing workflow
+
+The npm publishing workflow requires an `NPM_TOKEN` repository secret. Do not assume it exists. If it is missing, guide the user through creating it and explain why it is needed.
+
 ## npm Publishing
 
 Use npm only for installation packaging. Sagaz itself is intended for Codex Desktop, not as a standalone CLI agent runtime.

package/ai-orchestration-ecosystem/protocols/agent-observability.md

@@ -0,0 +1,75 @@
+# Agent Observability
+
+## Purpose
+
+Make Sagaz work auditable without turning every interaction into a long transcript. Observability must show what was decided, which team acted, which tools were used, what evidence exists, and what risks remain.
+
+## When To Use
+
+Use this protocol for medium or large projects, production work, multi-team handoffs, debugging the Sagaz process, or any task where repeatability matters.
+
+## Minimum Trace
+
+Record only high-signal events:
+
+- user goal
+- active workflow
+- current squad and agent role
+- decision points
+- handoffs
+- approvals or denied approvals
+- tool categories used
+- files changed
+- tests and checks run
+- failures and recoveries
+- final evidence
+- residual risks
+
+## Token-Efficient Trace Format
+
+```md
+## Trace
+
+| Time | Team | Event | Evidence | Next |
+| --- | --- | --- | --- | --- |
+| YYYY-MM-DD HH:MM | Product Factory | Requirements clarified | product-spec.md | Stack selection |
+```
+
+## Tool Event Format
+
+```md
+Tool:
+Purpose:
+Inputs:
+Output summary:
+Cost/risk:
+Follow-up:
+```
+
+Do not paste long logs unless the log itself is the artifact being reviewed. Summarize and keep the exact command available.
+
+## Metrics
+
+Track these only when useful:
+
+- estimated token load by phase: low, medium, high
+- elapsed phase time
+- number of verification passes
+- reopened defects
+- blocked handoffs
+- tests run versus tests planned
+- deployment result
+
+## Failure Handling
+
+When a failure occurs:
+
+1. Record the failed action.
+2. Record the observed error.
+3. State the likely cause as an assumption when not proven.
+4. Define the smallest recovery step.
+5. Add or update a prevention rule if the failure can recur.
+
+## Completion Rule
+
+Sagaz must not claim reliable completion unless the trace includes enough evidence for another Codex thread to understand what happened and continue from the same state.

package/ai-orchestration-ecosystem/protocols/durable-run-state.md

@@ -0,0 +1,70 @@
+# Durable Run State
+
+## Purpose
+
+Keep Sagaz coherent across long projects, new Codex threads, context compaction, refactors, and releases.
+
+## Rule
+
+For medium or large work, create or update a run state file based on `templates/run-state.md`. The run state is the compact memory of the project. It must be short enough to reload cheaply and specific enough to prevent rework.
+
+## Required Sections
+
+- project goal
+- user constraints
+- active workflow
+- current phase
+- completed handoffs
+- approved decisions
+- denied or deferred suggestions
+- stack decision
+- design system status
+- implementation status
+- verification evidence
+- GitHub status
+- deployment status
+- risks and open questions
+- next recommended action
+
+## Checkpoint Rules
+
+Create a checkpoint after:
+
+- intake completion
+- stack selection
+- product specification approval
+- design system approval
+- architecture approval
+- implementation milestones
+- failed verification
+- successful verification
+- commit or release
+- deployment
+
+## Checkpoint Format
+
+```md
+## Checkpoint: YYYY-MM-DD HH:MM
+
+Phase:
+Completed:
+Evidence:
+Decision:
+Risks:
+Next recommended action:
+Needs user permission:
+```
+
+## Recovery Flow
+
+When resuming:
+
+1. Read the run state first.
+2. Read only the files referenced by the current phase.
+3. Verify the repository state before changing files.
+4. State the current phase and next proposed action.
+5. Ask permission only when the action is meaningful or state-changing.
+
+## Token Discipline
+
+Prefer links and short summaries over pasted content. Move large specs to templates or project files and keep the run state as an index plus decision ledger.

package/ai-orchestration-ecosystem/stack-presets/admin-dashboard.md

@@ -0,0 +1,31 @@
+# Stack Preset: Admin Dashboard
+
+## Best For
+
+Operational dashboards, internal tools, CRM-like interfaces, analytics panels, and back-office applications.
+
+## Default Stack
+
+- React or Next.js
+- TypeScript
+- Component library or a strict internal design system
+- Tables, filters, forms, role permissions, and audit logs
+- Playwright for critical workflows
+
+## Design Rules
+
+- Prioritize dense, scannable layouts.
+- Avoid marketing-style hero sections.
+- Make navigation predictable.
+- Use tables, filters, segmented controls, drawers, and modals intentionally.
+- Preserve keyboard and accessibility quality.
+
+## Required Sagaz Checks
+
+- role-based access
+- empty states
+- loading states
+- error states
+- destructive-action confirmations
+- audit trail needs
+- responsive behavior

package/ai-orchestration-ecosystem/stack-presets/expo-mobile.md

@@ -0,0 +1,33 @@
+# Stack Preset: Expo Mobile
+
+## Best For
+
+Cross-platform Android/iOS apps where one codebase, fast iteration, and managed builds matter.
+
+## Default Stack
+
+- Expo
+- React Native
+- TypeScript
+- Expo Router when suitable
+- EAS Build
+- EAS Update only when rollback strategy is clear
+
+## Strengths
+
+- Fastest practical path to Android and iOS for many teams.
+- Managed build and update tooling.
+- Large ecosystem.
+- Good fit for Codex-assisted development.
+
+## Tradeoffs
+
+- Some native integrations may require config plugins or prebuild.
+- App store release still needs careful manual review.
+- Over-the-air updates require governance.
+
+## Use When
+
+- The user wants Android and iOS.
+- Native custom code is limited or manageable.
+- Delivery speed and maintainability matter.

package/ai-orchestration-ecosystem/stack-presets/firebase.md

@@ -0,0 +1,27 @@
+# Stack Preset: Firebase
+
+## Best For
+
+Realtime apps, mobile-first products, quick authentication, push notifications, and apps that benefit from managed NoSQL infrastructure.
+
+## Strengths
+
+- Strong mobile ecosystem.
+- Realtime features.
+- Managed auth and hosting.
+- Good for rapid iteration.
+
+## Tradeoffs
+
+- NoSQL data modeling requires care.
+- Complex querying can become expensive or awkward.
+- Security rules must be tested.
+
+## Required Sagaz Checks
+
+- security rules
+- cost model
+- data access patterns
+- emulator usage
+- backup/export path
+- auth and permission flows

package/ai-orchestration-ecosystem/stack-presets/nextjs-vercel.md

@@ -0,0 +1,39 @@
+# Stack Preset: Next.js On Vercel
+
+## Best For
+
+Production web apps, SaaS products, dashboards, marketing sites with dynamic features, and apps that benefit from fast deployment.
+
+## Default Stack
+
+- Next.js
+- TypeScript
+- Tailwind CSS or an existing design system
+- Vercel
+- Playwright
+- GitHub Actions
+
+## Strengths
+
+- Strong ecosystem and hiring market.
+- Excellent deployment path on Vercel.
+- Good performance defaults.
+- Works well for full-stack web applications.
+- Easy to evolve from prototype to production.
+
+## Tradeoffs
+
+- Platform features can create Vercel coupling.
+- Server/client boundaries require discipline.
+- Complex apps still need architecture, testing, and observability.
+
+## Use When
+
+- The user wants a serious browser-based app.
+- SEO or performance matters.
+- Deployment simplicity matters.
+
+## Avoid When
+
+- The app is mostly native mobile.
+- The user needs a static-only site with no dynamic behavior.

package/ai-orchestration-ecosystem/stack-presets/node-api.md

@@ -0,0 +1,34 @@
+# Stack Preset: Node API
+
+## Best For
+
+Backend APIs, integrations, webhooks, automation services, and full-stack apps needing a dedicated server.
+
+## Default Stack
+
+- Node.js
+- TypeScript
+- Fastify or Express based on project needs
+- Zod or similar runtime validation
+- Postgres or managed database
+- Jest/Vitest plus integration tests
+
+## Strengths
+
+- Mature ecosystem.
+- Good fit for integrations and APIs.
+- Easy to deploy widely.
+
+## Tradeoffs
+
+- Requires explicit architecture for auth, validation, errors, logging, rate limits, and deployment.
+
+## Required Sagaz Checks
+
+- API contract
+- validation
+- authentication and authorization
+- logging and observability
+- rate limiting
+- integration tests
+- deployment and rollback

package/ai-orchestration-ecosystem/stack-presets/react-native.md

@@ -0,0 +1,25 @@
+# Stack Preset: React Native
+
+## Best For
+
+Mobile apps that need deeper native control than a fully managed Expo project.
+
+## Default Stack
+
+- React Native
+- TypeScript
+- React Navigation or Expo Router depending on project structure
+- Native build tooling
+- Detox or Maestro for mobile end-to-end tests when feasible
+
+## Strengths
+
+- Shared codebase across Android and iOS.
+- More native control than managed-only workflows.
+- Large ecosystem.
+
+## Tradeoffs
+
+- Native build complexity is higher.
+- CI setup is more involved.
+- Requires stronger platform-specific verification.

package/ai-orchestration-ecosystem/stack-presets/react-vite.md

@@ -0,0 +1,32 @@
+# Stack Preset: React With Vite
+
+## Best For
+
+Client-heavy apps, dashboards, internal tools, prototypes, and static sites that do not need a full-stack framework.
+
+## Default Stack
+
+- React
+- TypeScript
+- Vite
+- Tailwind CSS or existing CSS architecture
+- Vitest
+- Playwright when user workflows matter
+
+## Strengths
+
+- Simple mental model.
+- Fast local development.
+- Low framework overhead.
+- Easy static deployment.
+
+## Tradeoffs
+
+- Backend, auth, routing, and data strategy must be chosen separately.
+- SEO and server rendering are not the default.
+
+## Use When
+
+- The app is mostly client-side.
+- The project needs simplicity and speed.
+- The backend already exists.

package/ai-orchestration-ecosystem/stack-presets/static-site.md

@@ -0,0 +1,23 @@
+# Stack Preset: Static Site
+
+## Best For
+
+Marketing pages, documentation, portfolios, landing pages, and simple content sites.
+
+## Default Stack
+
+- Astro, Eleventy, or Vite depending on content needs
+- TypeScript when the project has interactive code
+- Netlify, Vercel, Cloudflare Pages, or GitHub Pages
+
+## Strengths
+
+- Low cost.
+- Simple hosting.
+- Strong performance and security baseline.
+- Easy maintenance.
+
+## Tradeoffs
+
+- Dynamic features require external services or backend functions.
+- Content workflows must be planned if nontechnical users edit content.

package/ai-orchestration-ecosystem/stack-presets/supabase.md

@@ -0,0 +1,28 @@
+# Stack Preset: Supabase
+
+## Best For
+
+Apps needing managed Postgres, authentication, storage, edge functions, and fast backend setup.
+
+## Strengths
+
+- Relational data model.
+- Managed auth and storage.
+- Good developer experience.
+- Works well with web and mobile apps.
+
+## Tradeoffs
+
+- Row-level security must be designed and tested carefully.
+- Vendor-specific features create some coupling.
+- Production backup and migration strategy must be explicit.
+
+## Required Sagaz Checks
+
+- data model
+- row-level security
+- migration plan
+- backup and restore plan
+- auth flows
+- environment variables
+- local or preview environment strategy

package/ai-orchestration-ecosystem/templates/changelog.md

@@ -0,0 +1,26 @@
+# Changelog
+
+## Format
+
+Use reverse chronological order.
+
+```md
+## [Version] - YYYY-MM-DD
+
+### Added
+
+### Changed
+
+### Fixed
+
+### Security
+
+### Migration Notes
+```
+
+## Rules
+
+- Mention user-visible changes.
+- Mention installation or package changes.
+- Mention breaking changes clearly.
+- Keep implementation details concise.

package/ai-orchestration-ecosystem/templates/release-notes.md

@@ -0,0 +1,21 @@
+# Release Notes
+
+## Release
+
+Version:
+Date:
+GitHub commit:
+npm package:
+
+## Summary
+
+## What Changed
+
+## Why It Matters
+
+## Verification
+
+## Upgrade Notes
+
+## Known Limitations
+

package/ai-orchestration-ecosystem/tools/tool-registry.md

@@ -0,0 +1,63 @@
+# Tool Registry
+
+## Purpose
+
+Give Sagaz a consistent way to decide which external or local tools should be recommended, verified, or used during a project.
+
+## Operating Rule
+
+Sagaz must not assume a tool is available. It should inspect the local project, verify installation when relevant, explain why the tool is useful, and ask permission before installation, authentication, publishing, deploying, or irreversible changes.
+
+## Core Tool Categories
+
+| Category | Examples | Sagaz Use |
+| --- | --- | --- |
+| Version control | Git, GitHub CLI | status, commits, branches, pull requests, releases |
+| Package managers | npm, pnpm, yarn, bun | install, scripts, audits, builds |
+| Web verification | Playwright, browser tools, Lighthouse | screenshots, interaction tests, accessibility checks |
+| Mobile delivery | Expo, EAS, Xcode, Android Studio, Gradle | Android/iOS builds and store readiness |
+| Deployment | Vercel, Netlify, Cloudflare, Render, Fly.io | preview, production deploy, rollback guidance |
+| Databases | Supabase, Firebase, Postgres, Prisma | schema, migrations, backup, policies |
+| Payments | Stripe | checkout, webhooks, test mode, compliance boundaries |
+| AI providers | OpenAI, OpenRouter, TogetherAI, Groq | model selection, routing, budget, quality checks |
+| Observability | Sentry, Logtail, Grafana, OpenTelemetry | errors, traces, logs, service health |
+| Security | npm audit, CodeQL, Dependabot, secret scanning | dependency and code risk detection |
+| CI/CD | GitHub Actions | repeatable tests, builds, release checks |
+
+## Recommendation Format
+
+```md
+Tool:
+Why it is recommended:
+Cost:
+Setup effort:
+Risk:
+Alternative:
+Permission needed:
+```
+
+## Connector Readiness
+
+Before using a tool, verify:
+
+- installed or available command
+- authentication status, if needed
+- project compatibility
+- required secrets or environment variables
+- cost or quota impact
+- rollback path
+
+## Default Choices
+
+For typical Codex projects:
+
+- GitHub CLI for GitHub operations.
+- Playwright for browser end-to-end tests.
+- GitHub Actions for CI.
+- Vercel for Next.js web deployment when the user wants simple production hosting.
+- Expo/EAS for cross-platform mobile delivery when native platform constraints allow it.
+- Supabase for fast full-stack apps needing relational data and authentication.
+
+## Safety Rule
+
+Sagaz must ask permission before installing tools, creating cloud resources, linking accounts, deploying, publishing packages, or modifying production data.

package/codex-skill/sagaz/SKILL.md

@@ -29,7 +29,10 @@ If navigation is needed, read:
 8. For production, apply production-critical: tests, build, security, env vars, deployment, rollback, and risks.
 9. For GitHub, apply proactive github-ops-guided: suggest commits, pushes, PRs, issues, releases, and checks at the right time.
 10. For production-grade engineering, apply relevant advanced protocols: 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.
-11. Do not declare done without verification evidence proportional to risk.
+11. For multi-phase or production work, apply durable run state and compact agent observability.
+12. Use the tool registry before recommending or using external tools, connectors, deployments, publishing, or account-linked actions.
+13. Use stack presets as starting points when recommending technologies, then adapt to user constraints.
+14. Do not declare done without verification evidence proportional to risk.
 
 ## Quick Selection
 
@@ -40,6 +43,9 @@ If navigation is needed, read:
 - Bugfix to release: `workflows/bugfix-to-release.md`
 - Design/UI: `squads/design-studio.md` and `protocols/design-quality.md`
 - GitHub: `squads/github-ops.md` and `protocols/github-operations.md`
+- Tools/connectors: `tools/tool-registry.md`
+- Stack presets: `stack-presets/`
+- Sagaz quality checks: `evals/sagaz-evaluation-suite.md`
 
 ## Required Handoff
 
@@ -62,6 +68,14 @@ For long-running work, create or update a file based on:
 
 `ai-orchestration-ecosystem/templates/run-state.md`
 
+Then apply:
+
+`ai-orchestration-ecosystem/protocols/durable-run-state.md`
+
+For auditability, use:
+
+`ai-orchestration-ecosystem/protocols/agent-observability.md`
+
 ## Source Of Truth
 
 The complete details are in:

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "sagaz-ai",
-  "version": "0.1.0",
+  "version": "0.1.1",
   "description": "Sagaz AI orchestration ecosystem installer for Codex Desktop.",
   "type": "module",
   "bin": {