sagaz-ai 0.3.0 → 0.3.2

package/CHANGELOG.md

@@ -1,5 +1,116 @@
 # Changelog
 
+## [0.3.2] - 2026-06-11
+
+### Release Type
+
+Patch
+
+### Added
+
+- Operational memory protocol for recurring project and team preferences across Sagaz runs.
+- Operational memory template for `.sagaz/operational-memory.md` style project memory.
+- Package validation for operational memory sections, safety terms, permission references, and template structure.
+
+### Changed
+
+- README, ecosystem README, INDEX, and manifest now expose operational memory as an official Sagaz capability.
+
+### Fixed
+
+- Replaced the previous generic memory protocol with a concrete approval-based operational memory contract.
+
+### Removed
+
+- None.
+
+### Security
+
+- Operational memory explicitly forbids secrets, credentials, session data, production data, and sensitive personal data.
+- Durable project or team memory requires explicit user approval.
+
+### 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.3.2 sync` or `npx sagaz-ai sync` to refresh the installed Codex Desktop skill.
+- 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.3.1] - 2026-06-11
+
+### Release Type
+
+Patch
+
+### Added
+
+- Sagaz adoption guide for first use in another project, team onboarding, invocation prompts, cross-platform notes, permission model, and evidence expectations.
+
+### Changed
+
+- README, ecosystem README, INDEX, manifest, and package verifier now register the adoption guide as an official ecosystem document.
+
+### Fixed
+
+- None.
+
+### Removed
+
+- None.
+
+### Security
+
+- No security changes.
+
+### 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.3.1 sync` or `npx sagaz-ai sync` to refresh the installed Codex Desktop skill.
+- 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.3.0] - 2026-06-11
 
 ### Release Type

package/README.md

@@ -36,6 +36,7 @@ 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.
+- **Operational memory:** optional project or team memory records recurring preferences without storing secrets or bypassing approvals.
 - **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.
@@ -168,6 +169,14 @@ Then open a new Codex Desktop thread and run:
 Sagaz: explain the available workflows.
 ```
 
+For the first real use in another project, start with:
+
+```text
+Sagaz: audit this project and tell me what workflow, stack playbook, risks, tests, and next implementation step you recommend. Do not change files yet.
+```
+
+The detailed adoption guide lives at `ai-orchestration-ecosystem/ADOPTION.md`.
+
 ### Manual Installation
 
 #### 1. Clone Or Download The Repository

package/RELEASE_NOTES.md

@@ -2,9 +2,9 @@
 
 ## Release
 
-Version: 0.3.0
+Version: 0.3.2
 Date: 2026-06-11
-Release type: Minor
+Release type: Patch
 GitHub commit: pending
 Git tag: pending
 GitHub release: pending
@@ -12,38 +12,33 @@ npm package: pending
 
 ## Summary
 
-Sagaz 0.3.0 completes the main non-CLI governance layer for Codex Desktop orchestration. It adds operational runbooks, complete scenario examples, a capabilities matrix, formal permission policy, stack playbooks, execution trace evidence, and MCP connector governance.
+Sagaz 0.3.2 adds operational memory: a safe, explicit, approval-based way to record recurring project and team preferences across Sagaz runs without storing secrets or bypassing current user instructions.
 
 ## Audience Impact
 
-- New users: clearer operating model, examples, stack guidance, and permission expectations before using Sagaz.
-- Existing users: should refresh the installed skill with `npx sagaz-ai sync`.
-- Maintainers: stronger package checks now catch stack playbook, observability, permission, and connector-policy drift.
-- Design team: Figma MCP usage is governed as a formal connector workflow for app-like mockups and design artifacts.
-- Engineering team: workflow evidence now includes traceable commands, decisions, failures, permissions, and handoffs.
+- New users: can understand how Sagaz handles recurring preferences before using it across multiple projects.
+- Existing users: can sync the installed skill and use the new memory protocol/template in real projects.
+- Teams: get a safer shared preference artifact for stack, design, verification, GitHub, deployment, and handoff expectations.
+- Maintainers: package validation now protects the memory protocol and template from accidental drift.
 
 ## What Changed
 
-- Added an operations runbook for everyday Sagaz use.
-- Added complete examples for common delivery scenarios.
-- Added a capabilities matrix against other orchestration ecosystems.
-- Added a formal permission contract for Windows and macOS Codex Desktop usage.
-- Added stack-specific playbooks.
-- Added an execution trace template and stronger observability protocol.
-- Added MCP connector policy across design, deploy, package, data, browser, and AI providers.
-- Expanded package verification to enforce the new governance files.
+- Replaced the generic `protocols/memory.md` with a concrete operational memory contract.
+- Added `templates/operational-memory.md`.
+- Registered the memory template in `manifest.json`.
+- Linked operational memory from README, ecosystem README, and INDEX.
+- Added verifier checks for memory levels, approval language, storage path, sensitive-data exclusions, and required template fields.
 
 ## Why It Matters
 
-Sagaz now has clearer rules for how agents should choose tools, request permission, preserve workflow state, hand off work, verify stack-specific outcomes, and operate MCP connectors without drifting into ad hoc behavior.
+Sagaz can now carry stable preferences between projects in an auditable way while still respecting the current repository, current user request, and explicit permission gates. The memory system is intentionally file-based, reviewable, and scoped.
 
 ## Compatibility
 
-- Windows: supported and locally verified from a Codex Desktop workspace.
-- macOS: supported through Codex Desktop and GitHub Actions runner validation.
+- Windows: supported through Codex Desktop.
+- macOS: supported through Codex Desktop.
 - Node.js: `>=22.14` remains the package minimum; Node.js 24 is preferred for new installs and CI.
 - Codex Desktop: required.
-- GitHub Actions: package checks run on Ubuntu, Windows, and macOS.
 - npm package: still an installer/distribution package, not a standalone Sagaz runtime.
 
 ## Migration Notes
@@ -51,7 +46,7 @@ Sagaz now has clearer rules for how agents should choose tools, request permissi
 Run:
 
 ```bash
-npx sagaz-ai@0.3.0 sync
+npx sagaz-ai@0.3.2 sync
 npx sagaz-ai doctor
 ```
 
@@ -62,12 +57,12 @@ 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: Git status reviewed before release preparation.
+- Manual checks: memory protocol and template are registered in the manifest and linked from docs.
 
 ## Known Limitations
 
 - Sagaz still intentionally skips a standalone CLI runtime; Codex Desktop remains the execution surface.
-- GitHub release and npm publishing remain explicit approval steps.
+- Operational memory is advisory and must not override current user instructions or repository evidence.
 - Connector behavior depends on each external MCP/app authorization and platform availability.
 
 ## Rollback Plan

package/ai-orchestration-ecosystem/ADOPTION.md

@@ -0,0 +1,178 @@
+# Sagaz Adoption Guide
+
+Use this guide when starting Sagaz in another project or onboarding a team to Sagaz inside Codex Desktop.
+
+## Purpose
+
+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.
+
+It assumes Sagaz is already installed with `npx sagaz-ai install` or `npx sagaz-ai sync`.
+
+## Requirements
+
+- Codex Desktop on Windows or macOS.
+- Node.js `22.14+`; Node.js 24 LTS is preferred.
+- npm available in the terminal.
+- Git installed when the project is version controlled.
+- GitHub CLI (`gh`) when Sagaz should create branches, pull requests, issues, releases, or inspect checks.
+- 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.
+
+Before starting a real project, run:
+
+```bash
+npx sagaz-ai doctor
+```
+
+If the installed skill is out of sync, run:
+
+```bash
+npx sagaz-ai sync
+```
+
+Then open a new Codex Desktop thread so the refreshed skill is discovered.
+
+## First Use In Another Project
+
+1. Open the target project folder in Codex Desktop.
+2. Start a new thread after installing or syncing Sagaz.
+3. Invoke Sagaz with a direct goal and any known constraints.
+4. Let Sagaz inspect the project before making changes.
+5. Approve each major handoff, external operation, dependency install, GitHub operation, deployment, package publish, or destructive action.
+6. Keep the final handoff and run-state artifacts inside the project when the work is meaningful or long-lived.
+
+## Invocation Pattern
+
+Use `Sagaz:` at the beginning of the message.
+
+For a new product:
+
+```text
+Sagaz: create a production-ready web SaaS for appointment scheduling.
+
+Requirements:
+- user login
+- calendar scheduling
+- admin dashboard
+- premium but practical UI
+- deployment on Vercel
+- GitHub release flow
+```
+
+For an existing project:
+
+```text
+Sagaz: inspect this project and prepare a safe implementation plan before changing code.
+
+Goal:
+- add subscription billing
+- preserve the current UX
+- use the existing stack when reasonable
+- include tests and deployment notes
+```
+
+For a bug:
+
+```text
+Sagaz: diagnose and fix the production checkout failure.
+
+Rules:
+- identify likely root cause first
+- make the smallest safe fix
+- run focused tests
+- prepare a release handoff
+```
+
+For design work with Figma MCP:
+
+```text
+Sagaz: coordinate the design team using Figma MCP to create app-like mockups that can be inspected as real application flows.
+
+Include:
+- target users
+- main screens
+- component states
+- interaction notes
+- visual QA checklist
+```
+
+## Recommended First Response From Sagaz
+
+Sagaz should respond with:
+
+- The selected workflow.
+- The selected squad or agents.
+- The assumptions it is making.
+- The files, commands, or connectors it needs to inspect.
+- The permission level required for the next step.
+- The expected first handoff artifact.
+
+Sagaz should avoid starting large implementation work before it understands the project structure, stack, risks, and definition of done.
+
+## Team Operating Model
+
+Use this rhythm for team adoption:
+
+1. Product confirms objective, users, constraints, and definition of done.
+2. Technology confirms stack, architecture, dependencies, and operating costs.
+3. Design confirms UX, UI system, accessibility, responsiveness, and visual QA expectations.
+4. Engineering implements in small verifiable steps.
+5. QA verifies behavior, regressions, accessibility, build, and deployment readiness.
+6. GitHub Ops prepares commit, branch, pull request, checks, release notes, tag, and release when approved.
+7. The final handoff records evidence, residual risk, rollback plan, and next recommended work.
+
+## Cross-Platform Notes
+
+Sagaz should treat Windows and macOS as first-class Codex Desktop environments.
+
+- Prefer commands that work in the user's current shell.
+- Use PowerShell syntax on Windows and POSIX shell syntax on macOS.
+- Record when a command or dependency is platform-specific.
+- Verify path examples before presenting them.
+- Do not assume Linux-only tooling unless the project or CI requires it.
+
+## Permission Model
+
+Sagaz follows `protocols/permission-contract.md`.
+
+Low-risk inspection can usually proceed directly. These actions require explicit approval:
+
+- Installing dependencies.
+- Writing or deleting files when implementation has not been clearly authorized.
+- Running commands that access networked registries or external services.
+- Creating, pushing, tagging, or releasing in GitHub.
+- Deploying to hosting providers.
+- Publishing packages.
+- Handling secrets, credentials, production data, billing, or destructive operations.
+
+## Evidence To Keep
+
+For serious work, Sagaz should maintain or produce:
+
+- `templates/run-state.md`
+- `templates/execution-trace.md`
+- `templates/implementation-plan.md`
+- `templates/qa-report.md`
+- `templates/final-handoff.md`
+- `templates/future-change-guide.md`
+- `templates/release-notes.md` when release work is involved.
+
+## Good First Team Exercise
+
+Use a low-risk existing repository and ask:
+
+```text
+Sagaz: audit this project and tell me what workflow, stack playbook, risks, tests, and next implementation step you recommend. Do not change files yet.
+```
+
+This verifies that the team understands Sagaz handoffs, permission gates, stack reasoning, and evidence before using it on production work.
+
+## Success Criteria
+
+Sagaz adoption is working when:
+
+- The team can invoke Sagaz consistently in new and existing projects.
+- Sagaz chooses workflows and stack playbooks without bloating context.
+- The team sees clear permission prompts before risky actions.
+- Handoffs explain what changed, what was verified, and what remains risky.
+- GitHub, design, deployment, and package operations happen only after approval.
+- Windows and macOS users can follow the same operating model with platform-appropriate commands.

package/ai-orchestration-ecosystem/INDEX.md

@@ -3,6 +3,7 @@
 ## Quick Entry
 
 - `ACTIVATE.md`: ready-to-use activation prompts.
+- `ADOPTION.md`: first-use guide for adopting Sagaz in another project or team.
 - `quickstart.md`: minimum operating rules.
 - `README.md`: ecosystem overview.
 - `manifest.json`: internal component registry for validation and navigation.
@@ -117,6 +118,7 @@ See `protocols/` for quality gates, testing matrix, stack selection, design qual
 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.
 
 - `templates/execution-trace.md`
+- `templates/operational-memory.md`
 
 ## Governance
 
@@ -127,4 +129,8 @@ See `templates/` for task briefs, product specs, technical specs, design systems
 - `governance/versioning.md`
 - `governance/ecosystem-maintenance.md`
 - `governance/package-release-policy.md`
+
+## Adoption
+
+- `ADOPTION.md`
 

package/ai-orchestration-ecosystem/README.md

@@ -5,15 +5,17 @@ A local AI orchestration ecosystem for Codex, focused on autonomous teams, consi
 ## How To Use
 
 1. Read `governance/operations-runbook.md` for the daily operating procedure.
-2. Read `quickstart.md`.
-3. Choose the smallest sufficient workflow or squad.
-4. Use formal tasks, handoffs, and quality gates.
-5. Create or update run state for medium/large work.
-6. Verify before declaring done.
+2. Read `ADOPTION.md` when starting Sagaz in another project or onboarding a team.
+3. Read `quickstart.md`.
+4. Choose the smallest sufficient workflow or squad.
+5. Use formal tasks, handoffs, and quality gates.
+6. Create or update run state for medium/large work.
+7. Verify before declaring done.
 
 ## Structure
 
 - `manifest.json`: internal component registry used to validate and navigate the ecosystem.
+- `ADOPTION.md`: first-use guide for adopting Sagaz in another project or team.
 - `workflows/`: named end-to-end flows.
 - `squads/`: specialized teams.
 - `agents/`: role definitions.
@@ -45,6 +47,8 @@ Use `protocols/agent-observability.md` and `templates/execution-trace.md` for mu
 
 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.
 
+Use `protocols/memory.md` and `templates/operational-memory.md` before creating durable project or team preferences for future Sagaz runs.
+
 ## 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/manifest.json

@@ -122,6 +122,7 @@
       "templates/implementation-plan.md",
       "templates/execution-trace.md",
       "templates/mobile-release-checklist.md",
+      "templates/operational-memory.md",
       "templates/product-spec.md",
       "templates/qa-report.md",
       "templates/refactor-safety-contract.md",
@@ -165,6 +166,7 @@
     ],
     "docs": [
       "ACTIVATE.md",
+      "ADOPTION.md",
       "INDEX.md",
       "README.md",
       "quickstart.md"

package/ai-orchestration-ecosystem/protocols/memory.md

@@ -1,32 +1,148 @@
-# Protocol: Memory
+# Protocol: Operational Memory
 
 ## Objective
 
-Define how Sagaz should handle Memory while keeping the process clear, low-token, safe, and verifiable.
+Define how Sagaz records recurring user, team, stack, delivery, and quality preferences across projects without storing secrets, private data, or unverified assumptions as durable memory.
+
+Operational memory is a lightweight project or team artifact. It is not a hidden database, not a substitute for current project inspection, and not permission to act without approval.
+
+## Scope
+
+Use this protocol for preferences that are stable enough to help future Sagaz runs, such as:
+
+- Preferred stack defaults.
+- Design and UX expectations.
+- Testing and verification habits.
+- GitHub, branch, commit, pull request, and release preferences.
+- Deployment and hosting preferences.
+- Communication and handoff style.
+- Team-specific stop conditions.
+- Recurring constraints for Windows, macOS, or Codex Desktop.
+
+Do not use operational memory for:
+
+- Secrets, tokens, passwords, keys, credentials, or session data.
+- Personal sensitive data.
+- Production data.
+- Legal, financial, medical, or employment decisions.
+- Temporary guesses that were not confirmed by the user.
+- Instructions that conflict with the current user request, repository state, or `protocols/permission-contract.md`.
+
+## Memory Levels
+
+- `M0 ephemeral`: context useful only inside the current response or tool step.
+- `M1 thread`: context useful for the current Codex Desktop thread.
+- `M2 project`: preferences useful for the current repository or workspace.
+- `M3 team`: preferences the user explicitly wants Sagaz to remember across projects.
+
+Sagaz may infer M0 and M1 from the current conversation. M2 and M3 require explicit user approval before being written or updated.
 
 ## 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. Inspect current project state before applying memory to a concrete task.
+2. Treat memory as advisory, not authoritative.
+3. Prefer current user instructions over stored preferences.
+4. Ask before creating or updating M2 or M3 memory.
+5. Record source, date, owner, confidence, scope, and expiry for each durable entry.
+6. Keep memory compact and easy to audit.
+7. Reconfirm stale or risky preferences before using them.
+8. Use `templates/operational-memory.md` for durable M2 or M3 entries.
+9. Reference `protocols/permission-contract.md` before any action that changes local state, remote state, deployments, packages, billing, credentials, or GitHub history.
+10. Reference `protocols/agent-observability.md` when memory affects a multi-phase or high-risk workflow.
 
-## Standard Recommendation Format
+## Approval Rules
+
+Sagaz must ask explicit approval before:
+
+- Creating a project memory file.
+- Adding a new durable preference.
+- Promoting a thread preference to project or team memory.
+- Applying a stored preference that affects architecture, cost, security, data, deployment, release, or public output.
+- Removing, renaming, or changing the meaning of an existing durable preference.
+
+Approval prompt format:
 
 ```md
-Recommendation:
-Why now:
-What changes:
-Benefit:
+Memory update proposed:
+Scope:
+Preference:
+Source:
+Why it helps:
 Risk:
-Permission required:
+Expiry or review date:
+Approval needed:
+```
+
+## Storage Convention
+
+Preferred project-local path:
+
+```text
+.sagaz/operational-memory.md
+```
+
+If the project should not store Sagaz artifacts, use a user-approved location and record that location in the handoff.
+
+Do not create hidden memory outside the workspace without explicit user approval.
+
+## Entry Format
+
+Each durable memory entry must include:
+
+```md
+Preference ID:
+Scope: M2 project | M3 team
+Status: active | proposed | deprecated
+Owner:
+Source:
+Created:
+Last reviewed:
+Review by:
+Confidence: low | medium | high
+Preference:
+Applies when:
+Do not apply when:
+Permission impact:
+Evidence:
 ```
+
+## Conflict Handling
+
+When memory conflicts with a current instruction or repository evidence:
+
+1. Follow the current user instruction when it is safe and clear.
+2. Explain the conflict briefly.
+3. Ask before updating or deprecating the memory entry.
+4. Record the decision in run state or execution trace when the task is meaningful.
+
+## Review And Expiry
+
+Use review dates to prevent stale preferences from becoming invisible defaults.
+
+- M2 project memory should be reviewed after major stack, deployment, or team changes.
+- M3 team memory should be reviewed at least every 90 days or before a major release.
+- Any memory involving cost, security, compliance, deployment, or public communication should be reconfirmed before use when stale.
+
 ## 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.
-- Verification evidence is missing for the risk level.
-
+- The user has not approved durable memory creation or update.
+- The proposed memory includes secrets or sensitive data.
+- The memory conflicts with `protocols/permission-contract.md`.
+- The current repository state contradicts the stored preference and the conflict is not resolved.
+- The memory would cause unapproved external operations, publishing, deployment, billing, or destructive changes.
+- The memory entry lacks source, scope, or review date.
+
+## Output
+
+When using operational memory, Sagaz should say:
+
+```md
+Memory used:
+Scope:
+Source:
+Applied to:
+Confidence:
+Permission impact:
+```
+
+When proposing a memory update, Sagaz should ask for approval using the approval prompt format and wait for the user before writing durable memory.

package/ai-orchestration-ecosystem/templates/operational-memory.md

@@ -0,0 +1,49 @@
+# Operational Memory
+
+## Metadata
+
+```yaml
+project:
+owner:
+scope: M2 project
+created:
+last_reviewed:
+review_by:
+storage_location:
+```
+
+## Operating Rules
+
+- Use this file only with `protocols/memory.md`.
+- Do not store secrets, tokens, passwords, keys, credentials, session data, production data, or sensitive personal data.
+- Current user instructions and current repository state override stored preferences.
+- Reconfirm stale, risky, or high-impact preferences before use.
+
+## Preferences
+
+| Preference ID | Scope | Status | Owner | Source | Created | Last reviewed | Review by | Confidence |
+| --- | --- | --- | --- | --- | --- | --- | --- | --- |
+| MEM-001 | M2 project | proposed |  |  |  |  |  | medium |
+
+## Preference Details
+
+### MEM-001
+
+Preference:
+
+Applies when:
+
+Do not apply when:
+
+Permission impact:
+
+Evidence:
+
+Notes:
+
+## Deprecated Preferences
+
+Move old preferences here instead of deleting them when history is useful.
+
+| Preference ID | Deprecated on | Reason | Replacement |
+| --- | --- | --- | --- |

package/package.json

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

package/scripts/verify-package.js

@@ -203,7 +203,7 @@ function validateManifest() {
 
     const baseDirectory = path.join(ecosystemRoot, directory);
     const actual = directory === "."
-      ? ["ACTIVATE.md", "INDEX.md", "README.md", "quickstart.md"]
+      ? ["ACTIVATE.md", "ADOPTION.md", "INDEX.md", "README.md", "quickstart.md"]
       : walkMarkdown(baseDirectory).map((markdownFile) => path.relative(ecosystemRoot, markdownFile).split(path.sep).join("/"));
     const expected = new Set(actual);
     const declared = new Set(entries);
@@ -813,6 +813,85 @@ function validateMcpConnectorPolicy() {
   }
 }
 
+function validateOperationalMemoryProtocol() {
+  const file = path.join(ecosystemRoot, "protocols", "memory.md");
+  if (!fs.existsSync(file)) {
+    fail(file, "operational memory protocol is missing");
+    return;
+  }
+
+  const text = readText(file);
+  const present = headings(text);
+  for (const section of [
+    "Objective",
+    "Scope",
+    "Memory Levels",
+    "Required Practice",
+    "Approval Rules",
+    "Storage Convention",
+    "Entry Format",
+    "Conflict Handling",
+    "Review And Expiry",
+    "Blocking Conditions",
+    "Output"
+  ]) {
+    if (!present.has(section)) {
+      fail(file, `missing section "${section}"`);
+    }
+  }
+
+  for (const term of [
+    "templates/operational-memory.md",
+    "protocols/permission-contract.md",
+    "protocols/agent-observability.md",
+    ".sagaz/operational-memory.md",
+    "M0 ephemeral",
+    "M1 thread",
+    "M2 project",
+    "M3 team",
+    "secrets",
+    "sensitive data",
+    "explicit user approval",
+    "Approval needed:",
+    "Review by:",
+    "Permission impact:"
+  ]) {
+    if (!text.includes(term)) {
+      fail(file, `operational memory protocol must mention "${term}"`);
+    }
+  }
+}
+
+function validateOperationalMemoryTemplate() {
+  const file = path.join(ecosystemRoot, "templates", "operational-memory.md");
+  if (!fs.existsSync(file)) {
+    fail(file, "operational memory template is missing");
+    return;
+  }
+
+  const text = readText(file);
+  const present = headings(text);
+  for (const section of ["Metadata", "Operating Rules", "Preferences", "Preference Details", "Deprecated Preferences"]) {
+    if (!present.has(section)) {
+      fail(file, `missing section "${section}"`);
+    }
+  }
+
+  for (const term of [
+    "protocols/memory.md",
+    "Do not store secrets",
+    "Current user instructions",
+    "Preference ID",
+    "Permission impact",
+    "Evidence",
+    "Review by"
+  ]) {
+    if (!text.includes(term)) {
+      fail(file, `operational memory template must mention "${term}"`);
+    }
+  }
+}
+
 function validateDurableRunStateProtocol() {
   const file = path.join(ecosystemRoot, "protocols", "durable-run-state.md");
   if (!fs.existsSync(file)) {
@@ -1561,6 +1640,8 @@ validateExecutionTraceTemplate();
 validateDurableRunStateProtocol();
 validateAgentObservabilityProtocol();
 validateMcpConnectorPolicy();
+validateOperationalMemoryProtocol();
+validateOperationalMemoryTemplate();
 validateComponentGovernanceProtocol();
 validateEvaluationSuite();
 validateReleaseVersioningGate();