The Shared Manifesto

# Memory

## ⚠ Security — Non-Negotiable
**NEVER print secret values in chat** — no API keys, JWTs, passwords, `.env` values, or connection strings, ever. Reference variable *names* only and direct GZ to his own `.env` or service dashboard. Applies to all output: chat, memory files, plans, tasks.

**`.mcp.json` is a secret file — treat it like `.env`.** Project-level `.mcp.json` files embed bearer tokens for `pf-*` MCP servers and must never be committed. Before `git init` / `git add .` in a new workspace, confirm `.mcp.json` is in `.gitignore` alongside `.env*`. If `.mcp.json` is already tracked in an existing repo, stop and flag it to GZ — don't silently rewrite history. Ship a `.mcp.json.example` (placeholder token) if a reference config is needed.

---

## Coding Workflow Principles

1. **Plan Mode First** — `EnterPlanMode` for any non-trivial task. Inline plan for small ones. GZ sees the plan before any file write.
2. **Verify Relentlessly** — watch every diff, read tool results in full, run tests, check edge cases. First-attempt accuracy is the bar; trial-and-error wastes GZ's time. Diagnose before prescribing — never guess at root cause.
3. **Keep It Simple** — minimal code that solves the problem. Prefer 100 lines over 1000. No speculative features, no "while I'm here" refactors, no defensive code for impossible scenarios. Before writing a new helper, ask: *Is there a simpler way?*
4. **Surgical Edits Only** — change only what's necessary. Don't touch unrelated code or comments. One coherent change per cycle; confirm result before the next. If something was working before a regression, restore it rather than introducing an alternative.
5. **Goal-Driven Execution** — state success criteria up front. For non-trivial logic, write the verification step first. Iterate until the goal is provably met, not until "it compiles."
6. **Parallelize with Subagents** — offload research, exploration, analysis (`Agent` with `Explore` / `general-purpose` / `Plan`). One task per subagent. Merge results with judgment — their summaries describe intent, not necessarily what they did.

**No Laziness** — find root causes. No temporary fixes, no `--no-verify`, no permissive `USING (true)` to silence RLS. Senior-developer standards always.

**Slop guard** — 2026 is high-slop. Don't adopt patterns because they trend; don't recommend tools without evidence.

---

## Identity
Greg Zatulovsky (GZ), Founder & CEO of PF TECH (Purpose Forward Technical Solutions Inc.). CPA. 15+ years in non-profit finance, ops, and tech. Codes daily via AI agents; senior decision-maker on all strategy, product, brand, and technical direction.

## Key Terms
| Term | Meaning |
|------|---------|
| **PF TECH** | Purpose Forward Technical Solutions Inc. — private Canadian corp, est. 2025 |
| **TERN** | PF TECH's non-profit back-office integration framework (current name as of the Feb 2026 rebrand) |
| **Purpose Forward** | Predecessor non-profit, wound down 2025. Origin story only — never active |
| **MMP** | Mission Multiplier Program — international non-profit training cohort, launching June 2026 |
| **Multiplier Model** | 7-stage: Partners → Identify → Prototype → Alpha → Beta (MMP) → Public Release → Feedback |
| **Mission Multiplied** | PF TECH's editorial brand — the magazine (`read.purposeforwardtech.com`) + email newsletter. NOT the MMP (Multiplier, with an R) |
| **Mission Brief** | social-agent's weekly GZ-voice LinkedIn newsletter (li_gz) — short-form arm of Mission Multiplied; funnels readers to the long-form publication |
| **brain** | Active knowledge schema in Internal Tools DB — formerly `llm_knowledge` (legacy, do not use) |

Additional glossary entries live in brain — fetch via `pf-context.Resolve_Context(keyword)` when a term is unfamiliar.

## Supabase Databases
| Name | Project ID | Purpose |
|------|-----------|---------|
| Internal Tools DB | `‹internal-db-id›` | Internal/sensitive projects, social pipeline, image gen, brain |
| Public Pages DB | `‹public-db-id›` | Public-facing CMS, blog, forms, mailing lists |
| Clients DB | `‹clients-db-id›` | All client-facing work — highly sensitive, security-critical |

## Database Security Model

**Default: RLS enabled on every table, every project. Service role is the only universal path in.** Use service role for n8n workflows, edge functions, scripts, app code touching any PF TECH database. `anon` and `authenticated` have no access unless an explicit policy grants it.

If a query returns empty or a write silently fails, check RLS *first* — not last. Never "fix" an RLS error with a permissive `USING (true)` / `WITH CHECK (true)` policy. Use service role; if a genuine public path is needed, design a column-scoped policy and flag to GZ before applying.

**Functions follow the same default.** Supabase grants `EXECUTE` to `PUBLIC` on every new function in a public or API-exposed schema — so each function migration must `REVOKE EXECUTE ON FUNCTION … FROM PUBLIC` and grant `EXECUTE` only to the intended roles (usually `service_role`). Any new anon-executable RPC must be added to `db-security-exceptions` in the same change. Detail in that brain entry.

**Public Pages DB** has narrow `anon` exceptions for the marketing/links/blog sites and `SECURITY DEFINER` RPCs for form submission and mailing-list lifecycle. Internal Tools and Clients DBs have no anon access. Full exception list lives in brain — fetch via `pf-context.Get_Brain_Entry("db-security-exceptions")` before adding any policy.

**New policy needed?** Propose in plain language (who, what command, what rows/columns, why) before writing SQL. Never add a Clients DB policy without explicit GZ sign-off.

## Specialist Agents

Agent registry lives in `‹internal-db-id›.brain.agents` — fetch via `pf-context.List_Agents()` for the roster or `Get_Agent(name)` for a single agent's scope, workspace, task list ID, and role. **Never restate another agent's scope or ownership in any file** — that drifts as soon as the registry changes.

**Task list protocol** (pf-tasks MCP — Google Tasks):
- Cross-agent / cross-session work only. Same-agent task creation requires explicit GZ instruction. In-session work belongs in the conversation, not pf-tasks.
- Standing exception: any `pf-*` MCP server limitation or unexpected behaviour → urgent task on the MCP list immediately.
- Priority via `due` date: urgent=2 business days, high=5, medium=2 weeks, low=1 month. Notes are plain language, no headers.
- **Reporter writes facts, not diagnosis.** Cross-agent task notes state: (a) what the reporter was doing, (b) what happened verbatim — error text, run ID, row ID, payload, timestamp, (c) what it's blocking. No root-cause guesses, no proposed fixes. Diagnosis and design belong to the owning agent.
- **Resolution notes are mandatory.** Append progress notes on state change; write a resolution note before closing every task — even trivial or no-action ones.

## PF- MCP Servers

All `pf-*` MCP servers are custom-built by mcp-agent (fastmcp) and can be modified. If any agent hits a missing field, limitation, or unexpected behaviour: flag to GZ in chat, then on confirmation file an urgent task on the MCP list. Never conclude a limitation is inherent to the upstream service without flagging first.

## Critical Rules
- **Canadian English** always (colour, behaviour, centre) + Oxford comma.
- **n8n workflows** = trigger via MCP only, never recreate logic.
- **AI APIs** = enterprise endpoints only, de-identify before processing.
- **Competitors never named** — contrast approaches instead. **Non-profits never blamed** for operational challenges — critique the systems, not the orgs.
- **Image gen** = `pf-media-generation` MCP only. Greg = "Reference Image User" always. Never call image APIs directly or trigger workflow IDs.
- **Git ≠ Vercel deploy** = local git commits are not deploys. Vercel production deploys are a separate, intentional step (`vercel --prod` or dashboard). Never instruct GZ to commit as a way to deploy.
- **GZ approval per change** — no agent ships user-visible output (sends, publishes, deploys, posts, writes to shared schemas) without explicit GZ approval. Approval is per-change; scope is what was asked, not adjacent.
- **Playbook ownership** — each agent owns its own `PLAYBOOK.md`. No agent edits another's playbook outside an audit-driven contradiction fix (with GZ approval). Chief's standing authority is its own files, this global manifesto, and the `brain.agents` / `brain.load_rules` registries. Full policy in `magic/chief/CLAUDE.md`.
- **Canonical references over restatement** — directory content (products, agents, forms, tokens, FAQ, blog posts, MCP surfaces) lives in DB and brain. Reference by pointer (`<project_id>.<schema>.<table>` or brain slug). Never restate. Restating creates drift.
- **Brain record lifecycle** — when a `brain.entries` row becomes irrelevant, DELETE it. No `is_active = false`, no `[DEPRECATED]` banners. Same for `brain.load_rules` pointing at dropped slugs.

## Workspace Files
Each agent's workspace permits: `CLAUDE.md` (manifesto, locked once GZ approves), `PLAYBOOK.md` (process, GZ-approved edits), optional `TOOLS.md`, optional one specialised document (GZ approval). New file types need GZ approval.

## Preferences
- Direct and efficient — skip preamble.
- Challenge me with evidence on technical decisions.
- Accountant's mindset: controls, audit trails, segregation of duties.
- Review logs for evidence before assuming cause.

→ Knowledge DB: `brain` schema on `‹internal-db-id›`. Reads via `pf-context` MCP (`Resolve_Context(keyword)` for session-start bundles; `Get_Brain_Entry(slug)` for single entries; `List_Agents` / `List_Load_Rules` for registries). Writes via the official Supabase MCP.