Morphism Prompt Inventory

assetactive

Provenance: Ingested from C:\Users\mesha\Downloads\morphism-prompt-inventory.md (~94 KB, 88 tagged prompts) on 2026-03-28. Original file dated 2026-03-25, structured inventory of feature prompts, project ideas, templates, research prompts, and content prompts for the Morphism ecosystem.

Morphism Prompt Inventory

1. Ecosystem Summary

Morphism is trust infrastructure for AI-assisted software delivery. Its tagline: "Govern AI-assisted software delivery before it drifts." The platform addresses a critical blind spot in modern engineering: when AI agents open PRs, modify configs, update docs, and influence release decisions, observability alone is not enough. Morphism provides governance, policy control, audit trails, and drift detection so teams can adopt AI agents without losing control.

Core Problem: Context Contamination

When AI agents rely on global caches and cross-repo memory, they carry assumptions across projects, producing plausible but incorrect code. Morphism defines a four-layer contamination taxonomy:

| Layer | Type | Description | |-------|------|-------------| | L1 | Structural | Wrong repos in context | | L2 | State | Stale project facts | | L3 | Intent | Session goal drift | | L4 | Semantic | Wrong architectural assumptions |

Three-Layer Defense Model

  1. Contextual Agent Boundaries via MCP — advisory guardrails through the Model Context Protocol server.
  2. Explicit State Over Fuzzy Memory — SSOT (Single Source of Truth) stored in .morphism/ per project.
  3. Continuous Output Validation — morphism validate catches drift in CI pipelines.

Tech Stack

  • Frontend: Next.js 15, React, Tailwind, Turborepo
  • Backend: TypeScript/Node.js, Python 3.11+
  • Database: Supabase (PostgreSQL)
  • Auth: Clerk | Payments: Stripe (per-seat) | Hosting: Vercel
  • CI/CD: GitHub Actions (CI, deploy, drift, intelligence workflows)
  • Analytics: Plausible, Sentry | Search: Pinecone
  • Python Core: Category theory engine, governance scripts, maturity scoring
  • License: BUSL-1.1

Product Surface

| Surface | Scope | |---------|-------| | CLI (@morphism-systems/cli) | 16 commands across Free/Pro/Team/Enterprise tiers | | MCP Server (@morphism-systems/mcp-server) | 15+ governance tools for editors/agents | | Dashboard (apps/morphism/, Next.js 15) | 14 features across tiers | | API | Route-level tier gating | | SDK (packages/sdk/) | Programmatic access |

Current State (2026-03-25)

  • Shipped: Clerk auth, Stripe billing, production deployment, governance hardening, tier gate enforcement (MCP + API), CLI v0.1.11, 25+ governance scripts, 15+ MCP tools, 7 kernel invariants.
  • Open P0: Social proof on landing page, feature evidence on pricing, copy deduplication, code block styling.
  • Backlog: Context Contamination defense (FC-1 through FC-4 all open), CLI tier gating incomplete, 6 open GitHub issues (#89–#94).

2. Feature Prompts

Context Contamination Defense

FP-001 — Implement morphism sync-registry (FC-1)

  • Domain: [MORPH]
  • Area: CLI
  • Priority: #p0
  • Tags: #feature, #prompt, #context-contamination, #L1-structural
  • Prompt: Design and implement the morphism sync-registry CLI command that provides L1 structural defense against context contamination. The command should maintain a local registry of repos and their boundaries, detect when an agent's context includes files from unrelated repos, and emit warnings or errors. Define the registry schema in .morphism/registry.json, support manual and auto-discovery modes, and integrate with the MCP server so agents receive boundary advisories at session start.
  • Context: FC-1 from the product spec. Structural contamination (wrong repos in context) is the most common and easiest-to-detect form. This is the entry point of the four-layer defense and the first feature users will interact with. Blocks FC-2 through FC-4 conceptually.

FP-002 — Implement morphism context --full (FC-2)

  • Domain: [MORPH]
  • Area: CLI
  • Priority: #p0
  • Tags: #feature, #prompt, #context-contamination, #L2-state
  • Prompt: Design and implement morphism context --full for L2 state defense. The command should dump the complete project state from .morphism/ into a structured context payload that agents can consume, replacing fuzzy memory with explicit facts. Include project version, last validated commit, active policies, known drift score, and dependency versions. Output formats: JSON (for MCP), human-readable table (for CLI), and YAML (for CI). Add a --diff flag to show what changed since the last context snapshot.
  • Context: FC-2 from the product spec. State contamination occurs when agents rely on stale project facts. This command provides a canonical "ground truth" snapshot so agents never need to guess.

FP-003 — Implement morphism scope-guard --auto (FC-3)

  • Domain: [MORPH]
  • Area: CLI / MCP
  • Priority: #p1
  • Tags: #feature, #prompt, #context-contamination, #L3-intent
  • Prompt: Design and implement morphism scope-guard --auto for L3 intent defense. This feature should monitor an active agent session and detect when the agent's actions diverge from the declared session goal. Define a session goal schema, implement a lightweight intent classifier that compares file-change patterns against the stated goal, and emit drift warnings when the delta exceeds a configurable threshold. Support both CLI (polling) and MCP (real-time advisory) modes.
  • Context: FC-3 from the product spec. Intent contamination is when a session starts with one goal but drifts to another. This is harder to detect than L1/L2 but critical for multi-step agent tasks.

FP-004 — Implement morphism validate --facts (FC-4)

  • Domain: [MORPH]
  • Area: CLI / Kernel
  • Priority: #p1
  • Tags: #feature, #prompt, #context-contamination, #L4-semantic
  • Prompt: Design and implement morphism validate --facts for L4 semantic defense. This command should verify that agent outputs are consistent with the project's architectural facts (language, framework versions, design patterns, API contracts). Build a fact registry in .morphism/facts.yaml, implement a fact-checker that compares generated code against registered facts, and produce a detailed mismatch report. The three sub-deliverables from FC-4 are: (1) fact registry schema, (2) fact-check engine, (3) CI integration hook.
  • Context: FC-4 from the product spec. Semantic contamination (wrong architectural assumptions) is the hardest to detect and most damaging. This closes the defense loop.

CLI Features

FP-005 — CLI Tier Gate Enforcement

  • Domain: [MORPH]
  • Area: CLI
  • Priority: #p0
  • Tags: #feature, #prompt, #tier-gating, #monetization
  • Prompt: Complete tier gate enforcement for all 16 CLI commands. Currently, MCP tools and API routes have tier gating but CLI commands do not. Implement a middleware layer in packages/cli/ that checks the user's subscription tier (Free/Pro/Team/Enterprise) before executing gated commands. Display a clear upgrade prompt when a user hits a tier wall. Ensure the gating logic is shared with the existing tier enforcement in packages/shared/.
  • Context: Tier gating is partially shipped for MCP and API but CLI commands still need it. This is a monetization blocker for the Pro tier.

FP-006 — morphism doctor Enhanced Diagnostics

  • Domain: [MORPH]
  • Area: CLI
  • Priority: #p1
  • Tags: #feature, #prompt, #dx, #onboarding
  • Prompt: Enhance morphism doctor to run a comprehensive health check that covers: (1) CLI version currency, (2) .morphism/ directory integrity, (3) governance policy validity, (4) MCP server connectivity, (5) Supabase/Clerk/Stripe key validity (for dashboard users), (6) CI workflow file presence, and (7) Kappa drift score freshness. Output a color-coded report with fix suggestions for each failing check. Add --fix flag for auto-remediation of common issues.
  • Context: morphism doctor is part of the pilot-first workflow. A richer diagnostic reduces support burden and improves first-run success rate.

FP-007 — morphism init Project Templates

  • Domain: [MORPH]
  • Area: CLI
  • Priority: #p2
  • Tags: #feature, #prompt, #onboarding, #templates
  • Prompt: Extend morphism init to offer project templates during initialization. Support at least three templates: (1) minimal (single-repo, Free tier), (2) team (multi-contributor, Pro tier policies), (3) enterprise (compliance-focused, Team tier policies). Each template should scaffold .morphism/ config, default policies, CI workflow files, and a starter governance report. Use an interactive prompt (inquirer-style) to guide the user through template selection.
  • Context: New users currently get a bare-bones .morphism/ directory. Templates reduce time-to-value and demonstrate tier features upfront.

FP-008 — morphism audit Command

  • Domain: [MORPH]
  • Area: CLI
  • Priority: #p1
  • Tags: #feature, #prompt, #compliance, #audit
  • Prompt: Implement a morphism audit CLI command that generates a comprehensive audit report for a project. The report should include: governance policy compliance status, drift history (Kappa over time), agent activity log, SSOT verification results, and unresolved contradictions. Output as JSON, Markdown, or HTML. Support --since for time-bounded audits and --format for output selection. This feeds the Team/Enterprise compliance story.
  • Context: Enterprise buyers need audit artifacts for SOC2/ISO 27001. This command packages existing governance data into a compliance-friendly format.

FP-009 — morphism diff Cross-Session Comparison

  • Domain: [MORPH]
  • Area: CLI
  • Priority: #p2
  • Tags: #feature, #prompt, #observability
  • Prompt: Implement morphism diff to compare governance state between two points in time (commits, dates, or session IDs). Show changes in: drift score (Kappa delta), policy additions/removals, SSOT mutations, and agent activity. Integrate with the existing governance_diff MCP tool but provide a richer CLI output with color-coded diffs and summary statistics.
  • Context: Teams need to understand how governance posture changes over time, especially after merges or agent-heavy sprints.

FP-010 — morphism export Telemetry & Intelligence Export

  • Domain: [MORPH]
  • Area: CLI
  • Priority: #p2
  • Tags: #feature, #prompt, #data, #intelligence
  • Prompt: Build a morphism export command that packages governance telemetry, drift history, and agent intelligence data into portable formats (CSV, JSON, Parquet). Support filtering by date range, agent ID, and policy domain. This enables teams to feed Morphism data into their existing BI/analytics tools. Leverage the existing export_agent_intelligence.py script but wrap it in a proper CLI interface with argument validation and progress reporting.
  • Context: The export_agent_intelligence.py script exists but isn't exposed through the CLI. Enterprise users need data portability.

MCP Server

FP-011 — MCP Tool: context_boundary_check

  • Domain: [MORPH]
  • Area: MCP
  • Priority: #p1
  • Tags: #feature, #prompt, #mcp, #context-contamination
  • Prompt: Add a context_boundary_check tool to packages/mcp-server/ that agents call before starting work. The tool receives the agent's current context (file list, repo refs) and returns a boundary report: which files are in-scope, which are out-of-scope per the sync registry, and which facts may be stale. This is the MCP-side integration for FC-1 and FC-2, making defense advisories available directly in the agent's tool loop.
  • Context: The MCP server already has 15+ governance tools but none specifically address context contamination at the boundary level. This bridges the product spec to the agent interface.

FP-012 — MCP Tool: session_goal_register

  • Domain: [MORPH]
  • Area: MCP
  • Priority: #p1
  • Tags: #feature, #prompt, #mcp, #intent-tracking
  • Prompt: Add session_goal_register and session_goal_check tools to the MCP server. session_goal_register accepts a natural-language goal statement and decomposes it into structured intent fields (target files, expected change type, scope). session_goal_check compares current session activity against the registered goal and returns a drift score. These tools are the MCP-side integration for FC-3 (scope-guard).
  • Context: Intent drift is invisible to agents unless they have a mechanism to check themselves. These tools make self-checking a first-class capability.

FP-013 — MCP Tool: policy_suggest

  • Domain: [MORPH]
  • Area: MCP
  • Priority: #p2
  • Tags: #feature, #prompt, #mcp, #governance
  • Prompt: Add a policy_suggest MCP tool that analyzes recent agent activity patterns and suggests new governance policies. For example, if agents frequently modify database migration files without running validation, suggest a "migration-validation-required" policy. The tool should query the session history in Supabase, identify recurring patterns that lack policy coverage, and return structured policy suggestions with rationale.
  • Context: Governance policies are currently author-defined. This tool enables the self-learning loop described in learn_from_session.py by surfacing policy gaps to the user.

FP-014 — MCP Tool: categorical_composition_verify

  • Domain: [MORPH]
  • Area: MCP / Kernel
  • Priority: #p2
  • Tags: #feature, #prompt, #mcp, #category-theory
  • Prompt: Add a categorical_composition_verify MCP tool that checks whether a sequence of governance transformations composes correctly in the category-theoretic sense. Given a chain of functor applications (e.g., validate → score → heal), verify that the composition preserves the kernel invariants (I-1 through I-7). Return a composition diagram and any detected invariant violations.
  • Context: The existing categorical tools (categorical_functor_verify, categorical_natural_transform_check) operate on individual morphisms. This tool validates the full pipeline composition.

FP-015 — MCP Tool: workspace_health_summary

  • Domain: [MORPH]
  • Area: MCP
  • Priority: #p1
  • Tags: #feature, #prompt, #mcp, #observability
  • Prompt: Add a workspace_health_summary MCP tool that provides a one-call overview of project governance health. Combine results from governance_validate, compute_kappa, ssot_verify, and governance_status into a single structured summary with a traffic-light health indicator (green/yellow/red). Agents should call this at session start to understand the governance posture before making changes.
  • Context: Currently agents need to call multiple MCP tools to get a full picture. This reduces tool-call overhead and improves agent decision quality.

Dashboard

FP-016 — Dashboard: Drift Timeline Visualization

  • Domain: [MORPH]
  • Area: Dashboard
  • Priority: #p1
  • Tags: #feature, #prompt, #dashboard, #visualization
  • Prompt: Build a drift timeline chart in the Next.js dashboard that plots Kappa drift score over time (daily/weekly/monthly). Use a line chart with threshold bands (green: κ < 0.1, yellow: 0.1–0.3, red: > 0.3). Each data point should be clickable to show the commit or session that caused the drift change. Include a comparison mode to overlay multiple repos or branches. Use the existing design tokens from packages/design-tokens/.
  • Context: Drift is the core metric but currently only visible via CLI. A visual timeline makes governance posture legible to non-CLI users (leads, directors).

FP-017 — Dashboard: Agent Activity Feed

  • Domain: [MORPH]
  • Area: Dashboard
  • Priority: #p1
  • Tags: #feature, #prompt, #dashboard, #observability
  • Prompt: Implement a real-time agent activity feed in the dashboard that shows: which agents are active, what files they're modifying, which policies they've triggered, and their current drift impact. Use Supabase real-time subscriptions for live updates. Each activity entry should link to the relevant governance validation result. Support filtering by agent, repo, and time range.
  • Context: Shared rollout visibility is a core product feature listed on the website. The activity feed is the primary UI for this.

FP-018 — Dashboard: Policy Editor

  • Domain: [MORPH]
  • Area: Dashboard
  • Priority: #p2
  • Tags: #feature, #prompt, #dashboard, #governance
  • Prompt: Build a visual policy editor in the dashboard that allows users to create, edit, and test governance policies without writing YAML/JSON by hand. Provide a form-based interface for common policy types (file restrictions, approval gates, drift thresholds) and a raw editor for advanced users. Include a "dry run" mode that simulates the policy against recent agent activity to show what would have been flagged.
  • Context: Policy authoring is currently CLI/file-based, which is a barrier for team leads who prefer GUI workflows. Unlocks Pro tier stickiness.

FP-019 — Dashboard: Tier Comparison & Upgrade Flow

  • Domain: [MORPH]
  • Area: Dashboard
  • Priority: #p0
  • Tags: #feature, #prompt, #dashboard, #monetization
  • Prompt: Build a tier comparison page in the dashboard that shows the user's current plan, feature usage against limits, and a clear upgrade path. Show feature evidence for each tier (not just feature names — show actual screenshots or demos of what Pro/Team unlocks). Include Stripe-powered upgrade buttons with inline checkout. This addresses the open P0: "feature evidence on pricing."
  • Context: Open P0 item. Users need to see why they should upgrade, not just that they can. Feature evidence is the conversion lever.

FP-020 — Dashboard: Social Proof Integration

  • Domain: [MORPH]
  • Area: Dashboard / Landing
  • Priority: #p0
  • Tags: #feature, #prompt, #dashboard, #marketing
  • Prompt: Add social proof elements to the landing page and dashboard: customer logos, usage statistics (agents governed, policies enforced, drift prevented), and testimonial cards. For early stage, generate compelling "by the numbers" metrics from internal usage data. Implement a testimonial collection flow where pilot users can submit quotes. This addresses the open P0: "social proof on landing."
  • Context: Open P0 item. The landing page currently lacks trust signals. Social proof is the highest-leverage conversion element for a trust infrastructure product.

Governance & Kernel

FP-021 — Governance Self-Learning Pipeline

  • Domain: [MORPH]
  • Area: Kernel
  • Priority: #p1
  • Tags: #feature, #prompt, #intelligence, #self-learning
  • Prompt: Productize the learn_from_session.py script into a full self-learning pipeline. After each agent session, automatically extract governance observations (policy violations, drift patterns, effective strategies), store them in a structured knowledge base (Supabase + Pinecone), and surface recommendations for policy updates. Build a feedback loop where users can accept or reject recommendations, and use acceptance rates to tune future suggestions.
  • Context: learn_from_session.py exists as a script but isn't integrated into the product loop. Self-learning governance is the differentiated intelligence layer.

FP-022 — Policy Pack Marketplace

  • Domain: [MORPH]
  • Area: Governance
  • Priority: #p2
  • Tags: #feature, #prompt, #governance, #marketplace
  • Prompt: Design a policy pack system where governance policies can be bundled, versioned, and shared. Define the policy pack schema (pack.yaml with name, version, policies[], compatibility, tier requirement). Build CLI commands: morphism pack install <name>, morphism pack create, morphism pack publish. Support a curated marketplace on the dashboard for discovering community and official packs (e.g., "SOC2 Starter", "AI Safety Basics", "Node.js Best Practices").
  • Context: Policy packs are mentioned in the Phase 2 roadmap. They're the key mechanism for making team workflow sticky and enabling community contributions.

FP-023 — Kernel Invariant Runtime Monitor

  • Domain: [MORPH]
  • Area: Kernel
  • Priority: #p1
  • Tags: #feature, #prompt, #kernel, #invariants
  • Prompt: Build a runtime monitor that continuously validates the 7 kernel invariants (I-1 through I-7) against live system state. For each invariant, define a concrete check: I-1 (verify no duplicate truth sources), I-2 (verify drift metrics are decreasing or flagged), I-3 (verify all governance actions are logged), I-4 (verify agent scope matches declared intent), I-5 (verify entropy metrics are monotonically decreasing post-heal), I-6 (verify refusal events are recorded), I-7 (verify agents have minimal required permissions). Emit alerts when invariants are violated. Relates to issue #89 (governance-runtime-truthfulness).
  • Context: The kernel invariants are defined conceptually but not continuously enforced at runtime. Issue #89 specifically calls for runtime truthfulness checks.

FP-024 — Multi-Repo Governance Orchestration

  • Domain: [MORPH]
  • Area: Governance
  • Priority: #p2
  • Tags: #feature, #prompt, #multi-repo, #enterprise
  • Prompt: Design a multi-repo governance orchestrator that applies policies consistently across multiple repositories in an organization. Define an org-level config (.morphism/org.yaml) that specifies shared policies, cross-repo drift thresholds, and inheritance rules. Build morphism org init, morphism org sync, and morphism org status commands. The dashboard should show an org-level governance overview with per-repo drill-down.
  • Context: Multi-repo rollout is a Phase 2 roadmap item. Enterprise customers typically have 10-100+ repos and need consistent governance across all of them.

FP-025 — Script Freshness Governance

  • Domain: [MORPH]
  • Area: Governance / Scripts
  • Priority: #p1
  • Tags: #feature, #prompt, #governance, #maintenance
  • Prompt: Implement the script freshness governance system described in issue #94. Build a metadata system that tracks when each of the 25+ governance scripts was last run, last modified, and last validated. Define freshness thresholds (e.g., scripts not run in 30 days are stale). Add morphism scripts status to show freshness, morphism scripts run-stale to execute overdue scripts, and morphism scripts retire to archive obsolete scripts. Integrate with CI to flag stale scripts as governance debt.
  • Context: Issue #94 (script-freshness-governance). With 25+ scripts, some inevitably become stale. This prevents governance rot.

FP-026 — OpenAPI Route Parity Gate

  • Domain: [MORPH]
  • Area: API / Governance
  • Priority: #p1
  • Tags: #feature, #prompt, #api, #parity
  • Prompt: Implement the OpenAPI route parity gate from issue #91. Build a CI check that compares the OpenAPI spec against actual implemented routes in the Next.js API. Detect: undocumented routes, documented-but-unimplemented routes, type mismatches between spec and handler, and missing tier-gate annotations. Fail CI when parity score drops below a configurable threshold. Add morphism api parity CLI command for local checks.
  • Context: Issue #91 (openapi-route-parity-gate). API route parity is a governance concern — an undocumented route is an ungoverned route.

FP-027 — Release Pin Sync Automation

  • Domain: [MORPH]
  • Area: CI/CD / Governance
  • Priority: #p1
  • Tags: #feature, #prompt, #releases, #automation
  • Prompt: Implement release pin sync from issue #90. Build an automated system that ensures version pins across package.json, lockfiles, CI workflows, and documentation stay synchronized after releases. Detect version drift between the CLI package, MCP server, shared package, and dashboard. Add a morphism release check command and a CI workflow step that blocks releases when pins are out of sync.
  • Context: Issue #90 (release-pin-sync-automation). Version pin drift across the monorepo causes subtle bugs and breaks governance assumptions.

FP-028 — Archive Revival Pipeline

  • Domain: [MORPH]
  • Area: Governance / Maintenance
  • Priority: #p2
  • Tags: #feature, #prompt, #archive, #revival
  • Prompt: Build a pipeline for reviving archived components as described in issues #92 and #93. Create a structured assessment process: (1) evaluate archived code for current relevance, (2) identify breaking API changes since archival, (3) generate a migration plan, (4) execute revival with automated tests. Specifically target the context-optimizer and inventory-service from the archive repo, assessing whether they should be revived, rewritten, or permanently retired.
  • Context: Issues #92 and #93. Archived code represents prior investment. A structured revival process prevents both wasteful rewrites and dangerous resurrections.

FP-029 — Contradiction Detection Engine

  • Domain: [MORPH]
  • Area: Kernel / Intelligence
  • Priority: #p1
  • Tags: #feature, #prompt, #intelligence, #contradictions
  • Prompt: Productize the contradiction finder audit into a permanent engine. Continuously scan .morphism/ config, governance policies, documentation, and code for contradictions (e.g., a policy requiring X while code does Y, or two docs stating conflicting versions). Use the Pinecone index to detect semantic contradictions across documents. Store detected contradictions with severity scores, and surface them in both CLI (morphism contradictions) and dashboard views.
  • Context: The contradiction finder was run as a one-time audit. Making it continuous prevents governance debt accumulation and supports I-1 (One Truth Per Domain).

FP-030 — Maturity Score Dashboard Widget

  • Domain: [MORPH]
  • Area: Dashboard / Kernel
  • Priority: #p2
  • Tags: #feature, #prompt, #dashboard, #maturity
  • Prompt: Expose the maturity_score.py governance maturity scoring in the dashboard as an interactive widget. Show the overall maturity score (0–100) with a breakdown by dimension: policy coverage, drift control, audit completeness, agent compliance, and documentation quality. Include a "how to improve" section for each dimension with actionable next steps. Track maturity over time with a trend line. Support comparisons across repos in multi-repo setups.
  • Context: maturity_score.py exists as a script but results aren't visible in the product. Maturity scoring is a natural upsell lever — "your score is 45, Pro features would get you to 75."

Plugin & Extension System

FP-031 — Plugin System Architecture

  • Domain: [MORPH]
  • Area: Kernel / Platform
  • Priority: #p2
  • Tags: #feature, #prompt, #plugins, #extensibility
  • Prompt: Design the plugin system architecture for Morphism. Define the plugin lifecycle (install, configure, enable, disable, uninstall), the plugin API surface (which kernel hooks plugins can tap into), and the security model (plugins run sandboxed, cannot bypass governance). Create the plugin manifest schema (morphism-plugin.yaml), build morphism plugin install/list/remove commands, and implement the plugin loader in the kernel. packages/plugin-bundle/ already exists — audit it and either extend or replace.
  • Context: packages/plugin-bundle/ exists but the full plugin system isn't designed. Extensibility is critical for ecosystem growth and covers use cases Morphism can't build in-house.

3. Project Ideas

PI-001 — VS Code Extension for Morphism

  • ID: PI-001
  • Title: VS Code Governance Extension
  • Scale: Medium (1–2 weeks)
  • Domain: [DEV]
  • Tags: #project, #idea, #vscode, #dx
  • Description: Build a VS Code extension that surfaces Morphism governance data directly in the editor. Show inline drift warnings on files that have drifted from SSOT, display the current Kappa score in the status bar, provide a sidebar panel for policy violations, and offer quick-fix actions for common governance issues. Integrate with the MCP server for real-time updates. This is the natural IDE complement to the CLI-first workflow.
  • Success criteria: Extension published to VS Code Marketplace, shows real-time Kappa score, highlights policy violations inline, supports one-click morphism validate from the editor.

PI-002 — GitHub Marketplace Action

  • ID: PI-002
  • Title: Morphism Governance GitHub Action
  • Scale: Small (1–2 days)
  • Domain: [DEV]
  • Tags: #project, #idea, #github, #ci
  • Description: Package morphism validate and morphism audit as a GitHub Marketplace action that teams can add to any workflow with a single YAML line. The action should run validation, report Kappa drift in PR comments, block merges when drift exceeds thresholds, and post governance badges to the repo README. This is the lowest-friction CI integration path and serves as a top-of-funnel acquisition channel.
  • Success criteria: Published on GitHub Marketplace, installs with uses: morphism-systems/governance-action@v1, posts drift reports as PR comments, supports configurable merge-blocking thresholds.

PI-003 — Governance Visualization Dashboard (Standalone)

  • ID: PI-003
  • Title: Governance Graph Explorer
  • Scale: Medium (1–2 weeks)
  • Domain: [MORPH]
  • Tags: #project, #idea, #visualization, #governance
  • Description: Build a standalone visualization tool (React + D3) that renders the governance dependency graph. Show relationships between policies, kernel invariants, MCP tools, CLI commands, and governance scripts. Highlight coverage gaps (invariants without runtime checks, policies without enforcement tools). Use the output of docs_graph.py as the data source. Deploy as a page within the existing dashboard or as an independent tool for internal use.
  • Success criteria: Interactive graph with clickable nodes, coverage gap highlighting, exportable SVG/PNG, data sourced from live governance state.

PI-004 — Category Theory Validation Test Suite

  • ID: PI-004
  • Title: Formal Category Theory Property Tests
  • Scale: Medium (1–2 weeks)
  • Domain: [RES]
  • Tags: #project, #idea, #category-theory, #testing
  • Description: Build a comprehensive property-based test suite for the category theory engine in src/morphism/. Use Hypothesis (Python) to generate random governance morphisms, functors, and natural transformations, then verify the category theory axioms hold: identity laws, associativity of composition, functor preservation, and naturality conditions. This provides mathematical confidence that the governance engine's categorical foundations are sound, not just assumed.
  • Success criteria: 100+ property tests covering all categorical operations, CI integration with coverage reporting, documented list of any axiom violations found and fixed.

PI-005 — Morphism Playground (Interactive Demo)

  • ID: PI-005
  • Title: Web-Based Governance Playground
  • Scale: Medium (1–2 weeks)
  • Domain: [MORPH]
  • Tags: #project, #idea, #demo, #onboarding
  • Description: Build an interactive web playground where potential users can try Morphism governance without installing anything. Provide a simulated repo with pre-configured .morphism/ state, let users run CLI commands in a browser terminal (using xterm.js + a lightweight backend), and show governance results in real-time. Include guided scenarios: "detect drift," "enforce a policy," "heal a violation." This replaces the cold install experience with a warm, guided trial.
  • Success criteria: Browser-based terminal with working morphism validate, morphism status, morphism doctor; at least 3 guided scenarios; < 3 second load time; no account required.

PI-006 — Synthetic Benchmark Suite

  • ID: PI-006
  • Title: Agent Governance Benchmark Generator
  • Scale: Medium (1–2 weeks)
  • Domain: [RES]
  • Tags: #project, #idea, #benchmarks, #testing
  • Description: Build a synthetic benchmark suite that generates realistic agent activity patterns for testing Morphism's governance capabilities. Create generators for: normal development patterns, context contamination scenarios (all four layers), policy violation patterns, and adversarial agent behaviors. Use the benchmarks/ directory as the home. The suite should produce reproducible test datasets and include a scoring harness that measures governance detection accuracy, false positive rate, and response latency.
  • Success criteria: Generators for all 4 contamination layers, 1000+ synthetic events per scenario, scoring harness with precision/recall metrics, CI-integrated regression benchmarks.

PI-007 — Enterprise Compliance Mapper

  • ID: PI-007
  • Title: SOC2/ISO 27001 Control Mapping Tool
  • Scale: Large (1+ months)
  • Domain: [MORPH]
  • Tags: #project, #idea, #compliance, #enterprise
  • Description: Build a tool that maps Morphism's governance capabilities to enterprise compliance frameworks (SOC2 Type II, ISO 27001, NIST CSF). For each compliance control, identify which Morphism features provide evidence, which governance scripts produce audit artifacts, and where gaps exist. Generate a compliance readiness report that shows coverage percentage per framework. This is the key enterprise sales enablement artifact — it lets security teams evaluate Morphism against their existing compliance requirements.
  • Success criteria: Mapping tables for SOC2, ISO 27001, and NIST CSF; automated gap analysis; exportable compliance readiness report; integrated into morphism audit --compliance command.

PI-008 — Multi-Model Governance Simulator

  • ID: PI-008
  • Title: Cross-LLM Governance Behavior Simulator
  • Scale: Large (1+ months)
  • Domain: [RES]
  • Tags: #project, #idea, #multi-model, #simulation
  • Description: Build a simulator that tests governance behavior across different LLM providers (GPT-4, Claude, Gemini, open-source models). Each model may exhibit different compliance patterns, context handling quirks, and drift tendencies. The simulator runs identical governance scenarios across models, measures divergence in behavior, and identifies model-specific governance rules that Morphism should support. This informs the product roadmap for multi-model governance and provides publishable research data.
  • Success criteria: Simulator supports 3+ LLM providers, runs 10+ governance scenarios, produces comparative behavior reports, identifies at least 5 model-specific governance considerations.

PI-009 — Morphism CLI Shell Completions & TUI

  • ID: PI-009
  • Title: CLI Shell Completions and Terminal UI
  • Scale: Small (1–2 days)
  • Domain: [DEV]
  • Tags: #project, #idea, #cli, #dx
  • Description: Add shell completion scripts (bash, zsh, fish) for all morphism CLI commands and build an optional Terminal UI (TUI) mode using Ink (React for CLI). The TUI should provide a dashboard-like experience in the terminal: Kappa score gauge, policy status table, recent agent activity list, and quick-action buttons for common commands. This improves developer experience for power users who live in the terminal.
  • Success criteria: Shell completions for bash/zsh/fish installable via morphism completions install, TUI mode via morphism ui with live-updating Kappa gauge and policy table.

PI-010 — Open-Source Governance Rule Library

  • ID: PI-010
  • Title: Community Governance Rules Repository
  • Scale: Medium (1–2 weeks)
  • Domain: [MORPH]
  • Tags: #project, #idea, #open-source, #community
  • Description: Create an open-source repository (morphism-systems/governance-rules) containing community-contributed governance rules and policy packs. Define a contribution format (rule schema, test fixtures, documentation template), build a CI pipeline that validates contributed rules against the Morphism policy engine, and create a simple web interface for browsing available rules. This builds community while making Morphism more valuable out of the box.
  • Success criteria: Public repo with 20+ initial rules across 5+ categories, contributor guide, CI validation, browsable web catalog linked from docs.

PI-011 — Provegate Integration

  • ID: PI-011
  • Title: Provegate + Morphism Bridge
  • Scale: Medium (1–2 weeks)
  • Domain: [RES]
  • Tags: #project, #idea, #epistemic, #integration
  • Description: Build an integration bridge between the epistemic-stack (three MCP servers for justified, revisable beliefs) and Morphism's governance layer. Map epistemic beliefs to governance facts, use belief revision as a mechanism for updating SSOT state, and use justification tracking to provide audit trails for governance decisions. This creates a unique "governed epistemics" capability where both the beliefs and the governance of those beliefs are formally tracked.
  • Success criteria: MCP bridge tool connecting epistemic-stack to Morphism governance, belief-to-fact mapping, justification audit trail, demo showing governed belief revision.

PI-012 — Drift Alerting System

  • ID: PI-012
  • Title: Real-Time Drift Alerting (Slack/Email/Webhook)
  • Scale: Small (1–2 days)
  • Domain: [MORPH]
  • Tags: #project, #idea, #alerting, #integration
  • Description: Build a drift alerting system that sends notifications when Kappa exceeds configurable thresholds. Support Slack webhooks, email (via Supabase/Resend), and generic webhook endpoints. Allow per-repo and per-policy alert configuration. Include alert deduplication (don't spam for the same drift), escalation rules (warn at 0.1, alert at 0.3, page at 0.5), and an alert history view in the dashboard.
  • Success criteria: Slack webhook integration working, configurable thresholds, deduplication, alert history in dashboard, < 60 second alert latency.

PI-013 — Governance SDK for Python

  • ID: PI-013
  • Title: Python SDK for Morphism Governance
  • Scale: Medium (1–2 weeks)
  • Domain: [DEV]
  • Tags: #project, #idea, #sdk, #python
  • Description: Build a Python SDK (pip install morphism-governance) that wraps Morphism's API and governance engine. The Python ecosystem has heavy AI/ML agent usage (LangChain, AutoGen, CrewAI) and needs native governance integration. The SDK should support: validate, score, compute_kappa, ssot_verify, and policy_check operations. Include decorators for governance-aware function execution (@governed, @scope_bound).
  • Success criteria: Published on PyPI, covers all core governance operations, includes @governed decorator, integration examples for LangChain and CrewAI, 90%+ test coverage.

PI-014 — Governance Diff Bot for PRs

  • ID: PI-014
  • Title: PR Governance Diff Bot
  • Scale: Small (1–2 days)
  • Domain: [DEV]
  • Tags: #project, #idea, #github, #automation
  • Description: Build a GitHub bot that automatically comments on PRs with governance impact analysis. For each PR, compute: Kappa delta (how the PR changes drift score), policy violations introduced, SSOT changes, and invariant impacts. Present results as a formatted table in the PR comment with pass/fail status. Support configurable blocking (PRs that degrade governance below a threshold cannot merge). Lighter weight than a full GitHub Action — just the bot.
  • Success criteria: Bot responds to PR events within 30 seconds, produces formatted governance report, supports merge-blocking, configurable via .morphism/bot.yaml.

PI-015 — neper + Morphism Integration for Agent Training

  • ID: PI-015
  • Title: Governance-Aware Agent Training Pipeline
  • Scale: Large (1+ months)
  • Domain: [RES]
  • Tags: #project, #idea, #training, #neper
  • Description: Integrate Morphism governance data with the neper LLM training/alignment platform to create governance-aware agent fine-tuning. Use Morphism's session observations, policy compliance data, and drift patterns as training signal to fine-tune agents that are inherently more governance-compliant. Generate synthetic training data from the benchmark suite (PI-006), evaluate agents on governance compliance metrics, and publish results as a research contribution to the AI safety community.
  • Success criteria: Training pipeline that ingests Morphism telemetry, fine-tuned model showing measurable governance compliance improvement, evaluation harness with compliance metrics, research writeup.

4. Template Prompts

TP-001 — Module Specification Template

  • ID: TP-001
  • Title: Module Spec Generator
  • Domain: [DEV]
  • Tags: #template, #prompt, #reusable, #spec
  • Template: 
    Generate a detailed module specification for a Morphism module that {MODULE_PURPOSE}.

The module lives in {PACKAGE_PATH} within the monorepo and belongs to the {SYSTEM_AREA} surface (CLI/MCP/Dashboard/Kernel).

Include: (1) Module purpose and responsibilities, (2) Public API with TypeScript/Python type signatures, (3) Dependencies on other Morphism packages, (4) Kernel invariants this module must uphold ({RELEVANT_INVARIANTS}), (5) Tier gating requirements ({TIER_LEVEL}), (6) Test strategy with edge cases, (7) Integration points with existing MCP tools and CLI commands.
  • Variables:
    • {MODULE_PURPOSE}: What the module does
    • {PACKAGE_PATH}: Monorepo path
    • {SYSTEM_AREA}: CLI, MCP, Dashboard, Kernel, or API
    • {RELEVANT_INVARIANTS}: Which of I-1 through I-7 apply
    • {TIER_LEVEL}: Free, Pro, Team, or Enterprise

TP-002 — Governance Rule Authoring Template

  • ID: TP-002
  • Title: Governance Rule Author
  • Domain: [MORPH]
  • Tags: #template, #prompt, #reusable, #governance

TP-003 — Policy Pack Creation Template

  • ID: TP-003
  • Title: Policy Pack Scaffolder
  • Domain: [MORPH]
  • Tags: #template, #prompt, #reusable, #governance, #packs

TP-004 — Architecture Decision Record (ADR) Template

  • ID: TP-004
  • Title: ADR Generator
  • Domain: [DEV]
  • Tags: #template, #prompt, #reusable, #architecture

TP-005 — MCP Tool Implementation Template

  • ID: TP-005
  • Title: MCP Tool Scaffolder
  • Domain: [DEV]
  • Tags: #template, #prompt, #reusable, #mcp

TP-006 — CLI Command Scaffolding Template

  • ID: TP-006
  • Title: CLI Command Scaffolder
  • Domain: [DEV]
  • Tags: #template, #prompt, #reusable, #cli

TP-007 — Dashboard Feature Spec Template

  • ID: TP-007
  • Title: Dashboard Feature Spec Writer
  • Domain: [MORPH]
  • Tags: #template, #prompt, #reusable, #dashboard

TP-008 — Audit/Compliance Report Template

  • ID: TP-008
  • Title: Compliance Report Generator
  • Domain: [MORPH]
  • Tags: #template, #prompt, #reusable, #compliance, #audit

TP-009 — Session Handoff Documentation Template

  • ID: TP-009
  • Title: Agent Session Handoff
  • Domain: [MORPH]
  • Tags: #template, #prompt, #reusable, #handoff, #context

TP-010 — Competitive Analysis Template

  • ID: TP-010
  • Title: Competitive Analysis Report
  • Domain: [MORPH]
  • Tags: #template, #prompt, #reusable, #competitive

TP-011 — Governance Script Documentation Template

  • ID: TP-011
  • Title: Script Documentation Writer
  • Domain: [DEV]
  • Tags: #template, #prompt, #reusable, #scripts, #docs

TP-012 — API Route Specification Template

  • ID: TP-012
  • Title: API Route Spec Writer
  • Domain: [DEV]
  • Tags: #template, #prompt, #reusable, #api

TP-013 — Bug Triage & Investigation Template

  • ID: TP-013
  • Title: Bug Investigation Prompt
  • Domain: [DEV]
  • Tags: #template, #prompt, #reusable, #bugs

TP-014 — Sprint Planning Prompt Template

  • ID: TP-014
  • Title: Sprint Planning Assistant
  • Domain: [MORPH]
  • Tags: #template, #prompt, #reusable, #planning

TP-015 — Incident Post-Mortem Template

  • ID: TP-015
  • Title: Governance Incident Post-Mortem
  • Domain: [MORPH]
  • Tags: #template, #prompt, #reusable, #incident

5. Research & Analysis Prompts

(RP-001 through RP-015 — Category Theory Gaps, Kappa Statistical Properties, Contamination Algorithms, Competitive Landscape, MCP Protocol Evolution, Compliance Mapping, Agent Drift Patterns, Multi-Model Governance, OSS Framework Comparison, Kappa-Delta Composition, Context Window Budget, SSOT State Patterns, Formal Verification, Agent Permission Models, Governance Observability)

6. Content & Documentation Prompts

(CP-001 through CP-012 — Getting Started Guide, Architecture Deep-Dive, Category Theory for Engineers, Context Contamination Blog Post, Video Tutorial Script, API Reference, Case Study Template, Governance Whitepaper, MCP Integration Guide, Kernel Invariants Guide, Release Notes Guide, FAQ)

7. Cross-Reference Index

| ID | Title | CLI | MCP | Dashboard | Kernel | Governance | API | Pitch/Marketing | Research | |----|-------|-----|-----|-----------|--------|------------|-----|-----------------|----------| | FP-001 | sync-registry (FC-1) | ✓ | ✓ | | | ✓ | | | | | FP-002 | context --full (FC-2) | ✓ | ✓ | | | ✓ | | | | | FP-003 | scope-guard --auto (FC-3) | ✓ | ✓ | | | ✓ | | | | | FP-004 | validate --facts (FC-4) | ✓ | | | ✓ | ✓ | | | | | FP-005 | CLI Tier Gate Enforcement | ✓ | | | | | | | | | FP-016 | Drift Timeline Visualization | | | ✓ | | | ✓ | | | | FP-019 | Tier Comparison & Upgrade | | | ✓ | | | | ✓ | | | FP-020 | Social Proof Integration | | | ✓ | | | | ✓ | | | PI-001 | VS Code Extension | | ✓ | | | | | | | | PI-002 | GitHub Marketplace Action | ✓ | | | | ✓ | | | | | PI-011 | Provegate Bridge | | ✓ | | ✓ | ✓ | | | ✓ |

Total items: 88 (31 Feature Prompts + 15 Project Ideas + 15 Template Prompts + 15 Research Prompts + 12 Content Prompts)

This inventory is a living document. Update last-used and version in the YAML header with each revision.