@productbrain/mcp 0.0.1-beta.4482 → 0.0.1-beta.4490

package/dist/{chunk-DWLUS53G.js → chunk-DITNFWCP.js}

@@ -16146,11 +16146,12 @@ DEC (decisions), STR (strategy), TEN (tensions), FEAT (features),
 BET (bets), INS (insights), ARCH (architecture), TEAM (teams),
 ROL (roles), MAP (maps), MTRC (tracking-events), ST (semantic-types)
 
-## Valid Relation Types (21)
+## Valid Relation Types (24)
 informs, governs, surfaces_tension_in, defines_term_for, belongs_to,
 references, related_to, fills_slot, commits_to, informed_by, depends_on,
 conflicts_with, confused_with, replaces, part_of, constrains,
-governed_by, alternative_to, has_proposal, requests_promotion_of, resolves
+governed_by, alternative_to, has_proposal, requests_promotion_of, resolves,
+anchored_to, authority_domain, domain_routed_to
 
 ## Lifecycle Status
 All entries: \`draft\` | \`active\` | \`deprecated\` | \`archived\`
@@ -16260,7 +16261,7 @@ Implementation: \`src/lib/analytics.ts\`. Workspace-scoped events MUST use \`wit
 Browse: \`entries action=list collection=tracking-events\`.`
   );
   sections.push(
-    "## Knowledge Graph\nEntries are connected via typed relations (`entryRelations` table). Relations are bidirectional and collection-agnostic \u2014 any entry can link to any other entry.\n\n**Recommended relation types** (extensible \u2014 any string accepted):\n- `governs` \u2014 a rule constrains behavior of a feature\n- `defines_term_for` \u2014 a glossary term is canonical vocabulary for a feature/area\n- `belongs_to` \u2014 a feature belongs to a product area or parent concept\n- `informs` \u2014 a decision or insight informs a feature\n- `fills_slot` \u2014 an ingredient entry fills a slot in a map\n- `surfaces_tension_in` \u2014 a tension exists within a feature area\n- `related_to`, `depends_on`, `replaces`, `conflicts_with`, `references`, `confused_with`\n\nEach relation type is defined as a glossary entry (prefix `GT-REL-*`) to prevent terminology drift.\n\n**Tools:**\n- `context action=gather` \u2014 get the full context around any entry (multi-hop graph traversal)\n- `relations action=suggest` \u2014 discover potential connections for an entry\n- `relations action=create` \u2014 create a typed link between two entries\n- `relations action=find` \u2014 list direct relations for an entry\n\n**Convention:** When creating or updating entries in governed collections, always use `relations action=suggest` to discover and create relevant relations."
+    "## Knowledge Graph\nEntries are connected via typed relations (`entryRelations` table). Relations are bidirectional and collection-agnostic \u2014 any entry can link to any other entry.\n\n**Recommended relation types** (extensible \u2014 any string accepted):\n- `governs` \u2014 a rule constrains behavior of a feature\n- `defines_term_for` \u2014 a glossary term is canonical vocabulary for a feature/area\n- `belongs_to` \u2014 a feature belongs to a product area or parent concept (WP-641 typed successors: `anchored_to`, `authority_domain`)\n- `informs` \u2014 a decision or insight informs a feature\n- `fills_slot` \u2014 an ingredient entry fills a slot in a map\n- `surfaces_tension_in` \u2014 a tension exists within a feature area\n- `related_to`, `depends_on`, `replaces`, `conflicts_with`, `references`, `confused_with`\n\nEach relation type is defined as a glossary entry (prefix `GT-REL-*`) to prevent terminology drift. **Workflow-owned, NOT generic:** `domain_routed_to` (a question routed to a domain) \u2014 use the `question` tool (`action=create`/`adopt`, `domain=<slug>`), never `relations action=create`; the generic door has no replace/re-judge logic, so a raw write can leave duplicate routing edges and a stale suggested owner.\n\n**Tools:**\n- `context action=gather` \u2014 get the full context around any entry (multi-hop graph traversal)\n- `relations action=suggest` \u2014 discover potential connections for an entry\n- `relations action=create` \u2014 create a typed link between two entries\n- `relations action=find` \u2014 list direct relations for an entry\n\n**Convention:** When creating or updating entries in governed collections, always use `relations action=suggest` to discover and create relevant relations."
   );
   sections.push(
     "## Creating Knowledge\n**Entries:** Use `capture` as the primary tool for creating new entries. It handles the full workflow in one call:\n1. Creates the entry with collection-aware defaults (auto-fills dates, infers domains, sets priority)\n2. Auto-links related entries from across the chain (up to 5 confident matches)\n3. Returns a quality scorecard (X/10) with actionable improvement suggestions\n\n**Smart profiles** exist for: `tensions`, `business-rules`, `glossary`, `decisions`, `features`, `audiences`, `strategy`, `standards`, `maps`, `chains`, `tracking-events`.\nAll other collections use the `ENT-{random}` fallback profile.\n\n**Processes:** Use `chain action=create` with a template (e.g., `strategy-coherence`, `idm-proposal`). Fill links with `chain action=edit`.\n\n**Maps** (PB_MODULES=gitchain): Use `map action=create` with a template (e.g., `lean-canvas`). Fill slots with `map action=slot.add`. Commit with `map action=version.commit`.\nNote: committing a map version creates a snapshot but does NOT change the entry status. To activate: `entries action=update entryId=MAP-xxx status=active autoPublish=true`.\nUse `map action=suggest` to discover ingredients for empty slots.\n\n**Prompts** (invoke via MCP prompt protocol):\n- `name-check` \u2014 verify a name against glossary conventions\n- `draft-decision-record` \u2014 scaffold a decision entry\n- `review-against-rules` \u2014 check work against business rules for a domain\n- `draft-rule-from-context` \u2014 create a new business rule from context\n\nUse `quality action=check` to score existing entries retroactively.\nUse `entries action=update` for post-creation adjustments (status changes, field updates, deprecation)."
@@ -17046,4 +17047,4 @@ export {
   createProductBrainServer,
   initFeatureFlags
 };
-//# sourceMappingURL=chunk-DWLUS53G.js.map
+//# sourceMappingURL=chunk-DITNFWCP.js.map