#131 adr: define governed integration SEO architecture without duplicate pages

[Anonymous]

Originally created by: TheoV823

Context

Validation against the current repo shows that Mneme already has a broader integration surface than the initial analysis assumed. The site includes native or dedicated integration pages for Claude Code, Cursor, GitHub Actions, GitHub Copilot, VS Code, JetBrains, GitLab, Perplexity, ADR import, and Claude Agent SDK.

The current /works-with/ page remains the umbrella ecosystem compatibility map and already distinguishes native integrations, designed-to-support surfaces, and works-alongside positioning. It also already ships the core compatibility framing: models change, agents change, frameworks change; the decision corpus persists.

The actual gap is not that Claude Code, Cursor, GitHub Actions, or Copilot pages are missing. The gap is that some existing integration pages may not fully capture exact-match governance search intent in titles, meta descriptions, H1s, and internal links, while a small number of genuine targets remain missing.

Decision to record

Create an ADR that defines commercial-intent integration SEO as a governed information-architecture layer without creating duplicate pages.

The ADR should establish:

• /works-with/ remains the broad ecosystem compatibility map.
• /integrations/ remains the hub for native or documented integration pages.
• Existing integration pages should be strengthened in place where they already map to the search intent.
• Parallel *-governance pages must not be created when an existing canonical integration page already targets the same intent.
• Dedicated new pages are allowed only where no existing canonical page exists or where the intent is materially different.
• Native integration language is allowed only for documented native integrations.
• Works-alongside pages must use careful compatibility language and must not imply vendor partnership.
• Commercial-intent pages must connect back to concepts, demos, docs, works-with, and pilot conversion paths.

Existing pages to improve in place

Do not create duplicate pages for these. Strengthen the existing canonical pages instead:

1. /integrations/claude-code/ — improve title/meta/H1 around Claude Code governance if needed.
2. /integrations/cursor/ — improve title/meta/H1 around Cursor governance if needed.
3. /integrations/github-actions/ — improve title/meta/H1 around GitHub Actions AI governance if needed.
4. /integrations/copilot/ — preserve careful works-alongside positioning; improve governance search intent without overclaiming native integration.

Genuine new targets

These appear to be real gaps rather than duplicate targets:

1. /integrations/warp/ or equivalent works-alongside page for Warp AI terminal governance.
2. /use-cases/ci-governance-for-ai-generated-code/ for CI-focused AI-generated code governance, distinct from editor/coding-assistant governance.

Concepts graph implication

The concepts graph should not add each tool-specific page as a core concept node. Instead, Tier 4 pages should attach to existing concept nodes as applied execution surfaces.

Relevant concept anchors:

• Execution Surfaces
• Governance Propagation
• Model-Independent Governance
• Governance Before Generation
• Verification Contracts
• Enforcement Provenance

The concepts index may add an Applied Execution Surfaces rail or supporting section, but Claude Code, Cursor, GitHub Actions, Copilot, Warp, and CI/CD should remain examples of where the ontology lands, not new core concepts.

Guardrails

• Do not imply official partnership unless explicitly true.
• Do not create duplicate pages that cannibalize existing canonical integration pages.
• Use native integration only for documented native integrations.
• Use works alongside, compatible with, or designed to support for broader ecosystem pages.
• Pages must not be thin SEO pages; each should include workflow context, governance failure mode, Mneme enforcement seam, example, related concepts, and conversion path.
• Existing page URL equity should be preserved unless there is a strong migration/canonical reason.

Acceptance criteria

• ADR added under docs/adr/ with status accepted or proposed.
• ADR references /works-with/, /integrations/, existing integration pages, concept pages, and pilot/conversion paths.
• ADR defines naming, canonicalization, and claim-level rules for integration SEO pages.
• Follow-up implementation issue or checklist focuses on:
• in-place SEO strengthening for existing canonical integration pages
• new Warp page only if no canonical target exists
• new CI-governance-for-AI-generated-code use case page
• optional concepts graph Applied Execution Surfaces bridge
• No duplicate *-governance pages are created for already-shipped canonical integration pages.