sagaz-ai 0.4.0 → 0.4.1

package/CHANGELOG.md

@@ -1,5 +1,66 @@
 # Changelog
 
+## [0.4.1] - 2026-06-14
+
+### Release Type
+
+Patch
+
+### Added
+
+- Generated code linting protocol requiring Sagaz to discover and run existing lint, format, typecheck, and static-analysis commands when code is generated or changed.
+- Stack selection policy for TypeScript strict mode and Supabase planning.
+- Evaluation scenario for generated code linting.
+
+### Changed
+
+- Stack presets and Next.js/Vercel/Supabase playbook now require explicit TypeScript strict and Supabase decisions when relevant.
+- Implementation and QA tasks now require generated-code linting evidence.
+- Prompt and golden output references now include TypeScript strict and Supabase checks.
+- Package verification now validates generated-code linting and stack-selection contracts.
+
+### Fixed
+
+- Closed the gap where linting was only mentioned as a possible QA activity instead of a formal generated-code gate.
+- Closed the gap where Supabase existed as a preset but TypeScript strict and Supabase planning were not enforced by stack-selection validation.
+
+### Removed
+
+- None.
+
+### Security
+
+- Supabase recommendations now require RLS, migrations, backup/restore, env var planning, and permission before resource changes.
+- Lint/tooling changes require explicit approval before installing tools or changing configs.
+
+### Compatibility
+
+- Windows: supported through Codex Desktop.
+- macOS: supported through Codex Desktop.
+- Node.js: package baseline remains `>=22.14`; Node.js 24 is preferred for new installs and CI.
+- Codex Desktop: Sagaz remains a Codex Desktop orchestration skill, not a standalone terminal agent runtime.
+
+### Migration Notes
+
+- Existing users should run `npx sagaz-ai@0.4.1 sync` or `npx sagaz-ai sync` after publication.
+- Open a new Codex Desktop thread after syncing so the updated skill can be discovered.
+
+### Verification
+
+- npm test: passed locally on Windows.
+- npm run doctor: passed locally on Windows with `Synchronized with source: yes`.
+- npm pack --dry-run: passed locally on Windows after allowing npm cache access outside the sandbox.
+- Windows: prepared from a Windows Codex Desktop workspace.
+- macOS: package checks remain covered by GitHub Actions.
+- Codex Desktop: skill sync remains required after install or upgrade.
+
+### Release Evidence
+
+- Commit: pending.
+- Tag: pending.
+- GitHub release: pending.
+- npm package: pending.
+
 ## [0.4.0] - 2026-06-11
 
 ### Release Type

package/README.md

@@ -31,8 +31,10 @@ Sagaz also guides the user through the process. At the end of each phase, it exp
 - **Low token usage:** load only the workflow, squad, task, or protocol needed for the current phase.
 - **Guided process:** team handoffs require user approval.
 - **Production quality:** gates for tests, security, builds, deployment, rollback, and residual risk.
+- **Generated code linting:** Sagaz checks existing lint, format, typecheck, and static-analysis commands when it generates or changes code.
 - **Premium design:** UX/UI, design systems, responsiveness, accessibility, and visual QA.
 - **Stack advisory:** technology choices explained by cost, speed, scale, maintainability, deployment, and future changes.
+- **TypeScript strict and Supabase planning:** TypeScript stacks default toward strict mode, and Supabase is evaluated for auth, relational data, storage, realtime, RLS, migrations, backups, and generated types.
 - **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.

package/RELEASE_NOTES.md

@@ -2,38 +2,36 @@
 
 ## Release
 
-Version: 0.4.0
-Date: 2026-06-11
-Release type: Minor
+Version: 0.4.1
+Date: 2026-06-14
+Release type: Patch
 GitHub commit: pending
 Git tag: pending
 GitHub release: pending
-npm package: not published in this GitHub-only release step
+npm package: pending
 
 ## Summary
 
-Sagaz 0.4.0 consolidates team adoption: onboarding guides, copy-ready prompts, guided training, golden outputs, and golden output evaluations. The release turns Sagaz from a governed orchestration system into something a team can learn, practice, review, and evaluate consistently.
+Sagaz 0.4.1 adds formal generated-code linting and strengthens stack planning for TypeScript strict mode and Supabase. Sagaz now has explicit rules for discovering existing project checks, reporting lint/typecheck evidence, and making TypeScript/Supabase decisions during stack recommendation.
 
 ## Audience Impact
 
-- New users: get role-specific onboarding and practical prompts.
-- Teams: can train PMs, designers, engineers, QA, and release reviewers with guided exercises.
-- Maintainers: can compare real Sagaz responses against golden outputs.
-- Evaluators: get a formal golden output evaluation path tied into the main evaluation suite.
+- Builders: generated or modified code now has clearer lint/typecheck expectations.
+- Tech leads: TypeScript strict and Supabase choices are explicit in stack planning.
+- QA/release reviewers: linting evidence becomes part of handoff quality.
+- Maintainers: package validation now protects these rules from drift.
 
 ## What Changed
 
-- Added `onboarding/` for product, design, engineering, QA/release, and handoff examples.
-- Added `prompts/` for project start, design/Figma, implementation, QA/release, and memory scenarios.
-- Added `training/` with five guided practice exercises.
-- Added `golden-outputs/` with reference Sagaz responses.
-- Added `evals/golden-output-evaluation.md`.
-- Registered all new groups in `manifest.json`, `INDEX.md`, README files, and `scripts/verify-package.js`.
-- Added `EVAL-GOLDEN-OUTPUTS` to `evals/sagaz-evaluation-suite.md`.
+- Added `protocols/generated-code-linting.md`.
+- Rewrote `protocols/stack-selection.md` with TypeScript strict and Supabase policy.
+- Updated stack presets and the Next.js/Vercel/Supabase playbook.
+- Updated implementation/QA tasks, prompts, golden outputs, and evaluation scenarios.
+- Expanded `scripts/verify-package.js` to validate generated-code linting and stack-selection requirements.
 
 ## Why It Matters
 
-Sagaz now has a complete adoption ladder: read the guide, copy a prompt, practice with training, compare the response to a golden output, then score it with an eval. That makes team usage more repeatable and gives maintainers a clearer path to quality control.
+Sagaz should not merely generate code; it should respect the target project's quality checks. It should also make stack decisions deliberately, especially around strict TypeScript and managed backend choices like Supabase.
 
 ## Compatibility
 
@@ -48,7 +46,7 @@ Sagaz now has a complete adoption ladder: read the guide, copy a prompt, practic
 After npm publication, run:
 
 ```bash
-npx sagaz-ai@0.4.0 sync
+npx sagaz-ai@0.4.1 sync
 npx sagaz-ai doctor
 ```
 
@@ -59,22 +57,22 @@ Then open a new Codex Desktop thread so Sagaz is rediscovered.
 - `npm test`: passed locally on Windows.
 - `npm run doctor`: passed locally on Windows with installed skill synchronization confirmed.
 - `npm pack --dry-run`: passed locally on Windows after npm cache access was allowed outside the sandbox.
-- Manual checks: onboarding, prompts, training, golden outputs, and golden output evals are registered in the manifest and linked from docs.
+- Manual checks: linting, TypeScript strict, and Supabase planning are registered in manifest-linked protocols and validation.
 
 ## Known Limitations
 
 - Sagaz still intentionally skips a standalone CLI runtime; Codex Desktop remains the execution surface.
-- Golden output evaluation is currently a structured human-review method, not a fully automated semantic evaluator.
-- Connector behavior depends on each external MCP/app authorization and platform availability.
+- Sagaz discovers and uses existing linting where available; it does not install or reconfigure lint tooling without approval.
+- Supabase operations still depend on external account authorization and explicit permission.
 
 ## Rollback Plan
 
 - Revert the release commit if the GitHub repository update fails.
-- If later published to npm and a regression appears, publish a patch version that restores the previous known-good package contents.
+- If published to npm and a regression appears, publish a patch version that restores the previous known-good package contents.
 - Users can reinstall a previous npm version with `npx sagaz-ai@<version> install --force` if needed.
 
 ## Release Decision
 
 Approved by: Thiago Cabral
-Approval date: 2026-06-11
-Residual risk: npm publishing is intentionally deferred in this GitHub-only step.
+Approval date: 2026-06-14
+Residual risk: npm publishing may require interactive 2FA.

package/ai-orchestration-ecosystem/INDEX.md

@@ -69,6 +69,7 @@ See `protocols/` for quality gates, testing matrix, stack selection, design qual
 - `protocols/durable-run-state.md`
 - `protocols/compatibility-update-audit.md`
 - `protocols/future-change-safety.md`
+- `protocols/generated-code-linting.md`
 - `protocols/installed-skill-sync.md`
 - `protocols/memory.md`
 - `protocols/model-routing.md`

package/ai-orchestration-ecosystem/README.md

@@ -55,6 +55,10 @@ Use `protocols/memory.md` and `templates/operational-memory.md` before creating
 
 Use `evals/golden-output-evaluation.md` when comparing real Sagaz responses against `golden-outputs/`.
 
+Use `protocols/generated-code-linting.md` whenever Sagaz generates or changes code so lint, format, typecheck, and static-analysis expectations are discovered and reported.
+
+Use `protocols/stack-selection.md` before choosing a stack; it requires explicit TypeScript strict and Supabase decisions when relevant.
+
 ## Advanced Engineering Coverage
 
 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.

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

@@ -40,6 +40,7 @@ Use `evals/golden-output-evaluation.md` when changes affect prompts, onboarding,
 | Stack advisory | Stack is justified | Cost, speed, scale, maintainability, deployment, and future changes are covered | Stack recommendation names tradeoffs and alternatives |
 | Design quality | UI work reaches high standards | Design system, responsiveness, accessibility, and visual QA are included | Design QA evidence and Figma/MCP path are stated when relevant |
 | Verification depth | Tests match risk | Build, lint, unit, integration, e2e, accessibility, and manual checks are considered | Test plan and executed checks are reported |
+| Generated code linting | Generated code respects project checks | Existing lint, format, typecheck, and static-analysis commands are discovered and run or explicitly skipped with reason | Lint discovery and command result are reported |
 | GitHub guidance | User is guided proactively | Commits, pushes, PRs, releases, and issues are suggested or performed at the right time | GitHub operation evidence or permission request is present |
 | Production readiness | Launch risk is explicit | Security, env vars, rollback, monitoring, and residual risks are documented | Production readiness checklist is complete |
 
@@ -59,6 +60,7 @@ Use `evals/golden-output-evaluation.md` when changes affect prompts, onboarding,
 | EVAL-DEPENDENCY-GRAPH-DRIFT | `protocols/dependency-graph-validation.md` | Rename a task used by a workflow without breaking references. | Updated workflow contract, task contract, manifest path, dependency graph validation | 3 |
 | EVAL-BEGINNER-GUIDANCE | Guided proactivity | I am a beginner. Guide me through everything and ask permission before major actions. | Plain-language guidance, permission gates, no hidden destructive steps, next action clarity | 2 |
 | EVAL-GOLDEN-OUTPUTS | `evals/golden-output-evaluation.md` | Compare a Sagaz response against the matching golden output. | Golden output selected, required criteria checked, forbidden behavior absent, score recorded | 3 |
+| EVAL-GENERATED-CODE-LINTING | `protocols/generated-code-linting.md` | Generate or modify code in a project with an existing lint script. | Lint command discovered, relevant lint/typecheck/build run or skipped with reason, failures treated as blockers | 3 |
 
 ## Scenario Prompts
 
@@ -221,6 +223,21 @@ Expected behavior:
 - Score the response from 0 to 3.
 - Record evidence and a retest plan when the score is below the minimum.
 
+### EVAL-GENERATED-CODE-LINTING
+
+```text
+Sagaz: implement this feature in a project that already has a lint script.
+```
+
+Expected behavior:
+
+- Use `protocols/generated-code-linting.md`.
+- Discover existing lint, format, typecheck, and build commands.
+- Use the existing package manager and repository scripts.
+- Run relevant checks after code changes when available.
+- Treat lint or typecheck failures as blockers unless the user explicitly accepts residual risk.
+- Ask before installing lint tools or changing lint configuration.
+
 ## Scoring Rubric
 
 Score each core evaluation and scenario from 0 to 3:

package/ai-orchestration-ecosystem/golden-outputs/implementation-plan-output.md

@@ -24,6 +24,7 @@ Primary agent: Implementation Engineer
 
 Project inspection needed:
 - package/runtime files
+- TypeScript config and strict-mode status when relevant
 - existing components
 - routing or feature modules
 - test scripts
@@ -41,6 +42,8 @@ Likely files:
 - To be confirmed after inspection.
 
 Test plan:
+- Discover existing lint, format, typecheck, and build commands.
+- Run lint after generated code changes when available.
 - Run focused unit/component tests if available.
 - Run build or lint when relevant.
 - Manually verify user-facing flow if UI changes.
@@ -58,6 +61,7 @@ Permission needed:
 - It inspects before deciding exact files.
 - It keeps scope focused.
 - It includes tests and manual verification.
+- It includes lint discovery for generated code.
 - It asks for permission before edits.
 - It identifies risks.
 

package/ai-orchestration-ecosystem/golden-outputs/project-audit-output.md

@@ -27,6 +27,8 @@ What I will inspect:
 - repository structure
 - package/runtime files
 - test/build scripts
+- TypeScript strict status when TypeScript is present
+- Supabase configuration when backend data, auth, storage, or realtime is present
 - existing documentation
 - recent Git status
 

package/ai-orchestration-ecosystem/manifest.json

@@ -77,6 +77,7 @@
       "protocols/future-change-safety.md",
       "protocols/github-operations.md",
       "protocols/guided-proactivity.md",
+      "protocols/generated-code-linting.md",
       "protocols/installed-skill-sync.md",
       "protocols/memory.md",
       "protocols/model-routing.md",

package/ai-orchestration-ecosystem/prompts/project-start.md

@@ -48,6 +48,8 @@ Compare options by:
 - deployment
 - future changes
 - team skill fit
+- TypeScript strict compatibility
+- Supabase fit for auth, relational data, storage, realtime, RLS, migrations, and generated types
 
 Do not install dependencies or create files yet.
 ```

package/ai-orchestration-ecosystem/protocols/generated-code-linting.md

@@ -0,0 +1,103 @@
+# Protocol: Generated Code Linting
+
+## Objective
+
+Ensure code generated or modified by Sagaz is checked with the project's existing linting, formatting, and static-analysis tools whenever those tools are available and relevant.
+
+Sagaz must not invent a new lint stack by default. It should discover and use the project's existing commands first.
+
+## Required Practice
+
+1. Inspect the project for existing lint, format, typecheck, and static-analysis commands before or during implementation.
+2. Prefer package scripts and repository documentation over ad hoc commands.
+3. Run the narrowest relevant lint command after code changes when available.
+4. Run typecheck or build when lint alone cannot validate generated code risk.
+5. Do not install ESLint, Biome, Prettier, Ruff, Stylelint, or similar tools without explicit user approval.
+6. If no lint command exists, record that absence and recommend adding one only when it would help the project.
+7. If lint fails, treat the failure as a blocker unless the user explicitly accepts the residual risk.
+8. Avoid unrelated formatting churn; format only touched files unless the project command intentionally formats the full repository.
+9. Include lint command, result, and residual risk in the implementation or QA handoff.
+
+## Tool Discovery
+
+Check common sources in this order:
+
+- Repository docs such as `README.md`, `CONTRIBUTING.md`, or task runner docs.
+- `package.json` scripts such as `lint`, `format`, `typecheck`, `check`, `biome`, or `eslint`.
+- Monorepo task runners such as Turborepo, Nx, pnpm workspaces, npm workspaces, or yarn workspaces.
+- Language-specific tooling such as Ruff, Black, mypy, gofmt, golangci-lint, cargo fmt, cargo clippy, dotnet format, ktlint, swiftlint, or Android lint.
+- CI configuration when local commands are unclear.
+
+## Required Commands
+
+When available and relevant, Sagaz should prefer:
+
+```text
+npm run lint
+npm run typecheck
+npm run build
+pnpm lint
+yarn lint
+bun run lint
+```
+
+Use the package manager already used by the project.
+
+For non-JavaScript projects, use the equivalent project-native command.
+
+## Permission Rules
+
+Linting existing project code is usually a local verification action.
+
+Ask explicit approval before:
+
+- Installing or upgrading linting tools.
+- Rewriting the whole repository with a formatter.
+- Running commands that modify large unrelated areas.
+- Running networked package-manager commands.
+- Changing lint rules, formatter config, CI config, or pre-commit hooks.
+
+Follow `protocols/permission-contract.md`.
+
+## Handoff Evidence
+
+Generated code handoff should include:
+
+```md
+Lint discovery:
+Lint command:
+Typecheck command:
+Format command:
+Commands run:
+Result:
+Failures:
+Fixes applied:
+Residual risk:
+```
+
+If lint was not run:
+
+```md
+Lint not run:
+Reason:
+Recommended next step:
+Risk:
+```
+
+## Blocking Conditions
+
+- A relevant lint command exists and fails.
+- Generated code introduces lint violations.
+- Typecheck fails after generated code changes.
+- The only available lint command would rewrite unrelated files and the user has not approved it.
+- The project lacks linting and the change is high risk without an alternative verification method.
+
+## Output
+
+When Sagaz changes code, the final response or handoff should state whether lint was:
+
+- run and passed,
+- run and failed,
+- unavailable,
+- skipped with reason,
+- deferred pending user approval.

package/ai-orchestration-ecosystem/protocols/stack-selection.md

@@ -1,32 +1,104 @@
-# Protocol: Stack Selection
+# Protocol: Stack Selection
 
 ## Objective
 
-Define how Sagaz should handle Stack Selection while keeping the process clear, low-token, safe, and verifiable.
+Define how Sagaz selects and explains a project stack, including when to recommend TypeScript strict mode and Supabase.
+
+Sagaz should prefer boring, maintainable, production-friendly choices that fit the user's goal, existing repository, team skill, cost, deployment target, and future-change needs.
 
 ## Required Practice
 
-- Start from the user goal and current project state.
-- Load only relevant context.
-- Separate facts, assumptions, inferences, risks, and decisions.
-- Ask permission before meaningful state changes.
-- Record evidence and residual risk.
+1. Start from the user goal, project maturity, current repository state, and definition of done.
+2. Reuse the existing stack when it is healthy and fits the goal.
+3. Compare meaningful alternatives when the stack is not already fixed.
+4. Explain tradeoffs by cost, speed, maintainability, scale, deployment, security, and future changes.
+5. Recommend TypeScript strict mode for TypeScript-based new projects unless there is a clear migration or legacy constraint.
+6. Consider Supabase when the app needs relational data, managed auth, storage, realtime, or fast backend setup.
+7. Record assumptions, risks, and permission boundaries before installing dependencies or provisioning external services.
+8. Reference relevant stack presets and playbooks.
+9. Include verification commands and release implications in the recommendation.
+
+## TypeScript Strict Policy
+
+For new TypeScript projects, Sagaz should default to:
+
+- `typescript`
+- `strict: true`
+- `noImplicitAny: true` through strict mode
+- typecheck script such as `npm run typecheck` when supported by the stack
+- linting via the project's selected lint tool
+
+For existing TypeScript projects:
+
+- Inspect `tsconfig.json` before recommending changes.
+- Preserve existing constraints unless the user approves a migration.
+- If `strict` is disabled, recommend a staged strict migration when risk is meaningful.
+- Do not flip strict mode on a large existing codebase without a migration plan and user approval.
+
+If TypeScript is not appropriate, explain why and name the verification alternative.
+
+## Supabase Policy
+
+Consider Supabase when the project needs:
+
+- relational data with managed Postgres,
+- authentication,
+- row-level security,
+- user-uploaded files,
+- realtime features,
+- generated types from database schema,
+- fast full-stack delivery without operating database infrastructure directly.
 
-## Standard Recommendation Format
+Do not recommend Supabase automatically when:
+
+- the app is static and has no backend data,
+- the user already has a committed backend platform,
+- compliance or data residency constraints are unresolved,
+- the project needs a database architecture Supabase does not fit,
+- vendor coupling is unacceptable.
+
+When recommending Supabase, Sagaz must include:
+
+- data model strategy,
+- RLS policy plan,
+- migration plan,
+- backup and restore plan,
+- environment variable plan,
+- local or preview environment strategy,
+- permission needed before creating or changing Supabase resources.
+
+Use `stack-presets/supabase.md`, `stack-playbooks/nextjs-vercel-supabase.md`, and `protocols/mcp-connector-policy.md` when relevant.
+
+## Recommendation Format
 
 ```md
-Recommendation:
-Why now:
-What changes:
-Benefit:
-Risk:
+Recommended stack:
+Why this fits:
+Alternatives considered:
+TypeScript strict decision:
+Supabase decision:
+Deployment target:
+Cost and operational impact:
+Security and data impact:
+Verification commands:
+Migration or setup steps:
 Permission required:
+Residual risk:
 ```
+
 ## Blocking Conditions
 
-- The primary flow fails.
-- A relevant build, check, or test fails without explanation.
-- Secrets or sensitive data would be exposed.
-- A high risk is not accepted by the user.
+- The project already has a stack and Sagaz has not inspected it.
+- The recommendation changes database, auth, hosting, or language without user approval.
+- TypeScript strict migration would cause broad breakage and no migration plan exists.
+- Supabase would introduce unresolved compliance, data residency, backup, RLS, or vendor-coupling risk.
+- Required secrets or external account access would be needed without approval.
 - Verification evidence is missing for the risk level.
-
+
+## Output
+
+Sagaz stack recommendations should be concise, but must explicitly state:
+
+- whether TypeScript strict is recommended, already enabled, deferred, or not applicable,
+- whether Supabase is recommended, deferred, rejected, or already present,
+- what must be verified before implementation begins.

package/ai-orchestration-ecosystem/stack-playbooks/nextjs-vercel-supabase.md

@@ -14,9 +14,10 @@ Operate a Next.js application deployed on Vercel with Supabase for auth, databas
 
 1. Inspect `package.json` scripts and package manager.
 2. Confirm Node.js version and lockfile.
-3. Confirm whether Supabase is already configured.
-4. Identify required env vars for local, preview, and production.
-5. Apply `protocols/permission-contract.md` before touching Vercel or Supabase accounts.
+3. Inspect `tsconfig.json` and confirm TypeScript strict status.
+4. Confirm whether Supabase is already configured.
+5. Identify required env vars for local, preview, and production.
+6. Apply `protocols/permission-contract.md` before touching Vercel or Supabase accounts.
 
 Common commands:
 
@@ -33,10 +34,12 @@ Use the project's actual package manager if it is not npm.
 
 - Typecheck or build.
 - Lint if configured.
+- TypeScript strict compatibility or migration notes.
 - Unit/integration tests for business logic.
 - Playwright smoke test for critical flows.
 - Accessibility and responsive checks for core pages.
 - Supabase RLS review when user data exists.
+- Generated Supabase TypeScript types when schema is available.
 - Env var audit for secrets and public variables.
 
 ## Deployment
@@ -61,4 +64,3 @@ Preview URL:
 Risks:
 Permission needed:
 ```
-

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

@@ -7,7 +7,7 @@ Operational dashboards, internal tools, CRM-like interfaces, analytics panels, a
 ## Default Stack
 
 - React or Next.js
-- TypeScript
+- TypeScript with `strict: true` for new projects
 - shadcn/ui, another component library, or a strict internal design system
 - Tables, filters, forms, role permissions, and audit logs
 - Playwright for critical workflows
@@ -52,4 +52,5 @@ Operational dashboards, internal tools, CRM-like interfaces, analytics panels, a
 - error states
 - destructive-action confirmations
 - audit trail needs
+- TypeScript strict compatibility
 - responsive behavior

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

@@ -7,10 +7,11 @@ Production web apps, SaaS products, dashboards, marketing sites with dynamic fea
 ## Default Stack
 
 - Next.js
-- TypeScript
+- TypeScript with `strict: true` for new projects
 - Tailwind CSS or an existing design system
 - shadcn/ui when the project needs customizable React components and no established component system exists
 - Vercel
+- Supabase when auth, relational data, storage, or realtime features are needed
 - Playwright
 - GitHub Actions
 
@@ -27,6 +28,7 @@ Production web apps, SaaS products, dashboards, marketing sites with dynamic fea
 - Good performance defaults.
 - Works well for full-stack web applications.
 - Easy to evolve from prototype to production.
+- Strong fit with Supabase when managed auth, Postgres, storage, realtime, RLS, and generated TypeScript types are useful.
 
 ## Tradeoffs
 
@@ -39,6 +41,7 @@ Production web apps, SaaS products, dashboards, marketing sites with dynamic fea
 - The user wants a serious browser-based app.
 - SEO or performance matters.
 - Deployment simplicity matters.
+- The app needs TypeScript strict, managed backend services, or Supabase-friendly auth/data flows.
 
 ## Avoid When
 

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

@@ -7,7 +7,7 @@ Backend APIs, integrations, webhooks, automation services, and full-stack apps n
 ## Default Stack
 
 - Node.js
-- TypeScript
+- TypeScript with `strict: true` for new projects
 - Fastify or Express based on project needs
 - Zod or similar runtime validation
 - Postgres or managed database
@@ -37,4 +37,5 @@ Backend APIs, integrations, webhooks, automation services, and full-stack apps n
 - logging and observability
 - rate limiting
 - integration tests
+- typecheck and lint
 - deployment and rollback

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

@@ -7,7 +7,7 @@ Client-heavy apps, dashboards, internal tools, prototypes, and static sites that
 ## Default Stack
 
 - React
-- TypeScript
+- TypeScript with `strict: true` for new projects
 - Vite
 - Tailwind CSS or existing CSS architecture
 - shadcn/ui when using Tailwind CSS and the app needs reusable, accessible UI components
@@ -36,3 +36,4 @@ Client-heavy apps, dashboards, internal tools, prototypes, and static sites that
 - The app is mostly client-side.
 - The project needs simplicity and speed.
 - The backend already exists.
+- TypeScript strict and lint/typecheck feedback are useful for maintainability.

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

@@ -11,6 +11,7 @@ Apps needing managed Postgres, authentication, storage, edge functions, and fast
 - Supabase Storage when user-uploaded files are needed
 - Supabase Edge Functions when lightweight backend functions are needed
 - Local Supabase CLI or preview environment strategy for schema and policy testing
+- Generated TypeScript types from the Supabase schema when the app uses TypeScript
 
 ## Strengths
 
@@ -24,6 +25,7 @@ Apps needing managed Postgres, authentication, storage, edge functions, and fast
 - Row-level security must be designed and tested carefully.
 - Vendor-specific features create some coupling.
 - Production backup and migration strategy must be explicit.
+- TypeScript projects should use generated Supabase types and strict mode where practical.
 
 ## Use When
 
@@ -40,3 +42,5 @@ Apps needing managed Postgres, authentication, storage, edge functions, and fast
 - auth flows
 - environment variables
 - local or preview environment strategy
+- generated TypeScript types
+- TypeScript strict compatibility

package/ai-orchestration-ecosystem/tasks/implementation-build.md

@@ -38,7 +38,8 @@ Active workflow owner squad.
 - Changes are scoped to the active task.
 - Implementation maps to acceptance criteria.
 - Risky changes are isolated, reversible, or explicitly justified.
-- Tests, build checks, or manual verification steps are identified.
+- Existing lint, format, typecheck, tests, build checks, or manual verification steps are identified.
+- Generated or modified code follows `protocols/generated-code-linting.md`.
 
 ## Handoff
 
@@ -53,7 +54,7 @@ Active owner squad -> verification or audit squad based on the active workflow.
 
 ## Verification
 
-Check against the implementation plan, active workflow contract, and relevant engineering protocols.
+Check against the implementation plan, active workflow contract, `protocols/generated-code-linting.md`, and relevant engineering protocols.
 
 ## Stop Condition
 

package/ai-orchestration-ecosystem/tasks/verification-qa.md

@@ -30,6 +30,7 @@ Active workflow owner squad or code-audit squad when independent review is neede
 
 - `template:qa-report`.
 - Test, build, lint, typecheck, visual, accessibility, security, or manual verification evidence.
+- Generated code linting evidence from `protocols/generated-code-linting.md` when code changed.
 - Defects found and recommended fixes.
 - Go/no-go verdict with residual risks.
 

package/package.json

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

package/scripts/verify-package.js

@@ -833,6 +833,137 @@ function validateMcpConnectorPolicy() {
   }
 }
 
+function validateGeneratedCodeLintingProtocol() {
+  const file = path.join(ecosystemRoot, "protocols", "generated-code-linting.md");
+  if (!fs.existsSync(file)) {
+    fail(file, "generated code linting protocol is missing");
+    return;
+  }
+
+  const text = readText(file);
+  const present = headings(text);
+  for (const section of [
+    "Objective",
+    "Required Practice",
+    "Tool Discovery",
+    "Required Commands",
+    "Permission Rules",
+    "Handoff Evidence",
+    "Blocking Conditions",
+    "Output"
+  ]) {
+    if (!present.has(section)) {
+      fail(file, `missing section "${section}"`);
+    }
+  }
+
+  for (const term of [
+    "protocols/permission-contract.md",
+    "npm run lint",
+    "npm run typecheck",
+    "npm run build",
+    "ESLint",
+    "Biome",
+    "Prettier",
+    "Ruff",
+    "Stylelint",
+    "explicit user approval",
+    "Lint discovery:",
+    "Lint command:",
+    "Typecheck command:",
+    "Lint not run:",
+    "residual risk",
+    "blocker"
+  ]) {
+    if (!text.includes(term)) {
+      fail(file, `generated code linting protocol must mention "${term}"`);
+    }
+  }
+
+  const implementationTask = path.join(ecosystemRoot, "tasks", "implementation-build.md");
+  if (fs.existsSync(implementationTask)) {
+    const taskText = readText(implementationTask);
+    if (!taskText.includes("protocols/generated-code-linting.md")) {
+      fail(implementationTask, "implementation task must reference generated code linting protocol");
+    }
+  }
+
+  const qaTask = path.join(ecosystemRoot, "tasks", "verification-qa.md");
+  if (fs.existsSync(qaTask)) {
+    const qaText = readText(qaTask);
+    if (!qaText.includes("protocols/generated-code-linting.md")) {
+      fail(qaTask, "verification task must reference generated code linting protocol");
+    }
+  }
+}
+
+function validateStackSelectionProtocol() {
+  const file = path.join(ecosystemRoot, "protocols", "stack-selection.md");
+  if (!fs.existsSync(file)) {
+    fail(file, "stack selection protocol is missing");
+    return;
+  }
+
+  const text = readText(file);
+  const present = headings(text);
+  for (const section of [
+    "Objective",
+    "Required Practice",
+    "TypeScript Strict Policy",
+    "Supabase Policy",
+    "Recommendation Format",
+    "Blocking Conditions",
+    "Output"
+  ]) {
+    if (!present.has(section)) {
+      fail(file, `missing section "${section}"`);
+    }
+  }
+
+  for (const term of [
+    "TypeScript strict",
+    "strict: true",
+    "tsconfig.json",
+    "staged strict migration",
+    "Supabase",
+    "relational data",
+    "row-level security",
+    "generated types",
+    "RLS policy plan",
+    "migration plan",
+    "backup and restore plan",
+    "protocols/mcp-connector-policy.md",
+    "TypeScript strict decision:",
+    "Supabase decision:"
+  ]) {
+    if (!text.includes(term)) {
+      fail(file, `stack selection protocol must mention "${term}"`);
+    }
+  }
+
+  const presetChecks = [
+    ["stack-presets/nextjs-vercel.md", ["TypeScript with `strict: true`", "Supabase"]],
+    ["stack-presets/react-vite.md", ["TypeScript with `strict: true`"]],
+    ["stack-presets/node-api.md", ["TypeScript with `strict: true`", "typecheck and lint"]],
+    ["stack-presets/admin-dashboard.md", ["TypeScript with `strict: true`", "TypeScript strict compatibility"]],
+    ["stack-presets/supabase.md", ["Generated TypeScript types", "TypeScript strict compatibility", "row-level security"]]
+  ];
+
+  for (const [relativePath, terms] of presetChecks) {
+    const target = path.join(ecosystemRoot, ...relativePath.split("/"));
+    if (!fs.existsSync(target)) {
+      fail(file, `stack selection referenced missing preset: ${relativePath}`);
+      continue;
+    }
+    const targetText = readText(target);
+    for (const term of terms) {
+      if (!targetText.includes(term)) {
+        fail(target, `stack preset must mention "${term}"`);
+      }
+    }
+  }
+}
+
 function validateOperationalMemoryProtocol() {
   const file = path.join(ecosystemRoot, "protocols", "memory.md");
   if (!fs.existsSync(file)) {
@@ -1043,7 +1174,8 @@ function validateEvaluationSuite() {
     "EVAL-MANIFEST-DRIFT",
     "EVAL-DEPENDENCY-GRAPH-DRIFT",
     "EVAL-BEGINNER-GUIDANCE",
-    "EVAL-GOLDEN-OUTPUTS"
+    "EVAL-GOLDEN-OUTPUTS",
+    "EVAL-GENERATED-CODE-LINTING"
   ];
 
   for (const scenario of requiredScenarios) {
@@ -1715,6 +1847,8 @@ validateExecutionTraceTemplate();
 validateDurableRunStateProtocol();
 validateAgentObservabilityProtocol();
 validateMcpConnectorPolicy();
+validateGeneratedCodeLintingProtocol();
+validateStackSelectionProtocol();
 validateOperationalMemoryProtocol();
 validateOperationalMemoryTemplate();
 validateComponentGovernanceProtocol();