@a-company/paradigm 5.38.0 → 6.0.4

package/dist/university-content/paths/LP-para-301.yaml

@@ -0,0 +1,84 @@
+id: LP-para-301
+title: 'PARA 301: Operations'
+description: Master the operational tools and workflows that keep a Paradigm project healthy. From history tracking and fragility analysis to sentinel observability and context management, this course covers the day-to-day operations that separate well-maintained projects from chaotic ones.
+author: paradigm
+created: '2026-04-22'
+updated: '2026-04-22'
+tags:
+  - course
+  - para-301
+ordered: true
+category: paradigm-core
+origin: imported
+source: courses/para-301.json
+steps:
+  - content: N-para-301-history-system
+    required: true
+  - content: Q-para-301-history-system
+    required: true
+    passRequired: true
+  - content: N-para-301-fragility-tracking
+    required: true
+  - content: Q-para-301-fragility-tracking
+    required: true
+    passRequired: true
+  - content: N-para-301-wisdom-system
+    required: true
+  - content: Q-para-301-wisdom-system
+    required: true
+    passRequired: true
+  - content: N-para-301-decisions
+    required: true
+  - content: Q-para-301-decisions
+    required: true
+    passRequired: true
+  - content: N-para-301-ripple-analysis
+    required: true
+  - content: Q-para-301-ripple-analysis
+    required: true
+    passRequired: true
+  - content: N-para-301-doctor-and-validation
+    required: true
+  - content: Q-para-301-doctor-and-validation
+    required: true
+    passRequired: true
+  - content: N-para-301-enforcement-levels
+    required: true
+  - content: Q-para-301-enforcement-levels
+    required: true
+    passRequired: true
+  - content: N-para-301-paradigm-shift
+    required: true
+  - content: Q-para-301-paradigm-shift
+    required: true
+    passRequired: true
+  - content: N-para-301-navigation-system
+    required: true
+  - content: Q-para-301-navigation-system
+    required: true
+    passRequired: true
+  - content: N-para-301-sentinel-observability
+    required: true
+  - content: Q-para-301-sentinel-observability
+    required: true
+    passRequired: true
+  - content: N-para-301-sync-and-maintenance
+    required: true
+  - content: Q-para-301-sync-and-maintenance
+    required: true
+    passRequired: true
+  - content: N-para-301-context-management
+    required: true
+  - content: Q-para-301-context-management
+    required: true
+    passRequired: true
+  - content: N-para-301-protocols
+    required: true
+  - content: Q-para-301-protocols
+    required: true
+    passRequired: true
+  - content: N-para-301-operations-review
+    required: true
+  - content: Q-para-301-operations-review
+    required: true
+    passRequired: true

package/dist/university-content/paths/LP-para-401.yaml

@@ -0,0 +1,74 @@
+id: LP-para-401
+title: 'PARA 401: Orchestration'
+description: Advanced course on multi-agent orchestration, MCP tool mastery, and framework-level coordination. Learn to decompose complex tasks across specialized agents, configure provider cascades, enforce governance with the PM layer, and achieve full Paradigm framework mastery.
+author: paradigm
+created: '2026-04-22'
+updated: '2026-04-22'
+tags:
+  - course
+  - para-401
+ordered: true
+category: paradigm-core
+origin: imported
+source: courses/para-401.json
+steps:
+  - content: N-para-401-mcp-tools-overview
+    required: true
+  - content: Q-para-401-mcp-tools-overview
+    required: true
+    passRequired: true
+  - content: N-para-401-multi-agent-coordination
+    required: true
+  - content: Q-para-401-multi-agent-coordination
+    required: true
+    passRequired: true
+  - content: N-para-401-agent-roles
+    required: true
+  - content: Q-para-401-agent-roles
+    required: true
+    passRequired: true
+  - content: N-para-401-provider-cascade
+    required: true
+  - content: Q-para-401-provider-cascade
+    required: true
+    passRequired: true
+  - content: N-para-401-orchestration-workflow
+    required: true
+  - content: Q-para-401-orchestration-workflow
+    required: true
+    passRequired: true
+  - content: N-para-401-quick-check
+    required: true
+  - content: Q-para-401-quick-check
+    required: true
+    passRequired: true
+  - content: N-para-401-pm-governance
+    required: true
+  - content: Q-para-401-pm-governance
+    required: true
+    passRequired: true
+  - content: N-para-401-commit-conventions
+    required: true
+  - content: Q-para-401-commit-conventions
+    required: true
+    passRequired: true
+  - content: N-para-401-mastery-review
+    required: true
+  - content: Q-para-401-mastery-review
+    required: true
+    passRequired: true
+  - content: N-para-401-agent-interop
+    required: true
+  - content: Q-para-401-agent-interop
+    required: true
+    passRequired: true
+  - content: N-para-401-agent-identity
+    required: true
+  - content: Q-para-401-agent-identity
+    required: true
+    passRequired: true
+  - content: N-para-401-notebooks-permissions
+    required: true
+  - content: Q-para-401-notebooks-permissions
+    required: true
+    passRequired: true

package/dist/university-content/paths/LP-para-451.yaml

@@ -0,0 +1,69 @@
+id: LP-para-451
+title: 'PARA 451: Agents Foundations'
+description: >-
+  Meet the team. Learn what each agent does and when to call them. PARA 451 is the
+  beginner-accessible introduction to Paradigm's most differentiated feature — its
+  agent system. The course covers the three-layer identity model (id / nickname /
+  archetype), the archetype-vs-instance distinction, the model-tier taxonomy, the
+  canonical 21-agent roster, roster management, the `paradigm shift` auto-rosterer,
+  the orchestration modes (faceted vs sequential roleplay), the partners
+  primitive, an agent-routing decision tree, and a capstone on why the team
+  pattern wins. Approximately 18 entries when complete (~35 minutes skim,
+  75-90 minutes full mastery). This course is the canonical introduction to
+  agents; the older agent entries inside PARA 401 are flagged as v6.1 retirement
+  candidates. Subsequent course PARA 551 (Agents in Practice) covers the v6.1
+  enforcement model, authority modes, soft-blocks, and notebook tier-1/tier-2
+  split.
+author: paradigm
+created: '2026-04-26'
+updated: '2026-04-26'
+tags:
+  - course
+  - para-451
+  - agents
+  - path
+ordered: true
+category: paradigm-core
+origin: authored
+source: agents-course-phase-a-design.md
+prerequisites:
+  - LP-para-101
+# Batches 1-3 (14 of ~18 planned entries) are implemented below. The remaining
+# planned entries (per .paradigm/research/agents-course-phase-a-design.md §2)
+# are the per-topic mini-quizzes (Q-para-451-identity-layers,
+# Q-para-451-archetypes-vs-instances, Q-para-451-tiers,
+# Q-para-451-roster-management, Q-para-451-orchestration-modes,
+# Q-para-451-partners) and the N-para-451-mastery-review note. Per the
+# batch-2/3 user locks, mini-quizzes are deferred to a polish pass after
+# launch — bigger when-to-invoke is the highest-leverage routing test, and the
+# capstone N-para-451-the-team-pattern serves as the conceptual close until
+# mastery-review lands.
+steps:
+  - content: N-para-451-welcome
+    required: true
+  - content: N-para-451-what-is-an-agent
+    required: true
+  - content: N-para-451-identity-layers
+    required: true
+  - content: N-para-451-archetypes-vs-instances
+    required: true
+  - content: N-para-451-tiers
+    required: true
+  - content: N-para-451-roster-reference
+    required: true
+  - content: N-para-451-roster-management
+    required: true
+  - content: N-para-451-paradigm-shift
+    required: true
+  - content: N-para-451-orchestration-modes
+    required: true
+  - content: N-para-451-partners-primitive
+    required: true
+  - content: N-para-451-agent-routing
+    required: true
+  - content: N-para-451-the-team-pattern
+    required: true
+  - content: Q-para-451-when-to-invoke
+    required: true
+  - content: Q-para-451-foundations
+    required: true

package/dist/university-content/paths/LP-para-501.yaml

@@ -0,0 +1,89 @@
+id: LP-para-501
+title: 'PARA 501: Advanced Systems'
+description: Master Paradigm's advanced operational systems — Lore for project memory, Sentinel for incident intelligence, Habits for behavioral discipline, Session Intelligence for crash recovery, and Hook Enforcement for automated compliance. Ties everything together into the complete Paradigm workflow.
+author: paradigm
+created: '2026-04-22'
+updated: '2026-04-22'
+tags:
+  - course
+  - para-501
+ordered: true
+category: paradigm-core
+origin: imported
+source: courses/para-501.json
+steps:
+  - content: N-para-501-lore-system
+    required: true
+  - content: Q-para-501-lore-system
+    required: true
+    passRequired: true
+  - content: N-para-501-sentinel-deep-dive
+    required: true
+  - content: Q-para-501-sentinel-deep-dive
+    required: true
+    passRequired: true
+  - content: N-para-501-aspect-graph-internals
+    required: true
+  - content: Q-para-501-aspect-graph-internals
+    required: true
+    passRequired: true
+  - content: N-para-501-habits-practice
+    required: true
+  - content: Q-para-501-habits-practice
+    required: true
+    passRequired: true
+  - content: N-para-501-session-intelligence
+    required: true
+  - content: Q-para-501-session-intelligence
+    required: true
+    passRequired: true
+  - content: N-para-501-hook-enforcement
+    required: true
+  - content: Q-para-501-hook-enforcement
+    required: true
+    passRequired: true
+  - content: N-para-501-advanced-workflows
+    required: true
+  - content: Q-para-501-advanced-workflows
+    required: true
+    passRequired: true
+  - content: N-para-501-aspect-graph-advanced
+    required: true
+  - content: Q-para-501-aspect-graph-advanced
+    required: true
+    passRequired: true
+  - content: N-para-501-task-management
+    required: true
+  - content: Q-para-501-task-management
+    required: true
+    passRequired: true
+  - content: N-para-501-assessment-loops
+    required: true
+  - content: Q-para-501-assessment-loops
+    required: true
+    passRequired: true
+  - content: N-para-501-symphony-a-mail
+    required: true
+  - content: Q-para-501-symphony-a-mail
+    required: true
+    passRequired: true
+  - content: N-para-501-platform-agent-ui
+    required: true
+  - content: Q-para-501-platform-agent-ui
+    required: true
+    passRequired: true
+  - content: N-para-501-conductor-workspace
+    required: true
+  - content: Q-para-501-conductor-workspace
+    required: true
+    passRequired: true
+  - content: N-para-501-symphony-networking
+    required: true
+  - content: Q-para-501-symphony-networking
+    required: true
+    passRequired: true
+  - content: N-para-501-review-compliance
+    required: true
+  - content: Q-para-501-review-compliance
+    required: true
+    passRequired: true

package/dist/university-content/paths/LP-para-601.yaml

@@ -0,0 +1,59 @@
+id: LP-para-601
+title: 'PARA 601: Paradigm Ambient'
+description: Master Paradigm's ambient coordination system — knowledge streams, event stream, attention scoring, nominations, data sovereignty, agent manifest renaissance, and context composition. The full loop from observation to adaptation.
+author: paradigm
+created: '2026-04-22'
+updated: '2026-04-22'
+tags:
+  - course
+  - para-601
+ordered: true
+category: paradigm-core
+origin: imported
+source: courses/para-601.json
+steps:
+  - content: N-para-601-learning-loop
+    required: true
+  - content: Q-para-601-learning-loop
+    required: true
+    passRequired: true
+  - content: N-para-601-knowledge-streams
+    required: true
+  - content: Q-para-601-knowledge-streams
+    required: true
+    passRequired: true
+  - content: N-para-601-event-stream
+    required: true
+  - content: Q-para-601-event-stream
+    required: true
+    passRequired: true
+  - content: N-para-601-attention-scoring
+    required: true
+  - content: Q-para-601-attention-scoring
+    required: true
+    passRequired: true
+  - content: N-para-601-nominations-debates
+    required: true
+  - content: Q-para-601-nominations-debates
+    required: true
+    passRequired: true
+  - content: N-para-601-data-sovereignty
+    required: true
+  - content: Q-para-601-data-sovereignty
+    required: true
+    passRequired: true
+  - content: N-para-601-agent-renaissance
+    required: true
+  - content: Q-para-601-agent-renaissance
+    required: true
+    passRequired: true
+  - content: N-para-601-context-composition
+    required: true
+  - content: Q-para-601-context-composition
+    required: true
+    passRequired: true
+  - content: N-para-601-maestro-team-collab
+    required: true
+  - content: Q-para-601-maestro-team-collab
+    required: true
+    passRequired: true

package/dist/university-content/paths/LP-para-701.yaml

@@ -0,0 +1,64 @@
+id: LP-para-701
+title: 'PARA 701: Agent Mastery'
+description: Master the Paradigm agent system — from the 54-agent roster to orchestration enforcement, learning loops, and the nevr.land marketplace.
+author: paradigm
+created: '2026-04-22'
+updated: '2026-04-22'
+tags:
+  - course
+  - para-701
+ordered: true
+category: paradigm-core
+origin: imported
+source: courses/para-701.json
+steps:
+  - content: N-para-701-agent-roster
+    required: true
+  - content: Q-para-701-agent-roster
+    required: true
+    passRequired: true
+  - content: N-para-701-agent-profiles
+    required: true
+  - content: Q-para-701-agent-profiles
+    required: true
+    passRequired: true
+  - content: N-para-701-agent-notebooks
+    required: true
+  - content: Q-para-701-agent-notebooks
+    required: true
+    passRequired: true
+  - content: N-para-701-agent-state
+    required: true
+  - content: Q-para-701-agent-state
+    required: true
+    passRequired: true
+  - content: N-para-701-per-project-rosters
+    required: true
+  - content: Q-para-701-per-project-rosters
+    required: true
+    passRequired: true
+  - content: N-para-701-model-tier-resolution
+    required: true
+  - content: Q-para-701-model-tier-resolution
+    required: true
+    passRequired: true
+  - content: N-para-701-orchestration-enforcement
+    required: true
+  - content: Q-para-701-orchestration-enforcement
+    required: true
+    passRequired: true
+  - content: N-para-701-symphony-visibility
+    required: true
+  - content: Q-para-701-symphony-visibility
+    required: true
+    passRequired: true
+  - content: N-para-701-learning-feedback-loop
+    required: true
+  - content: Q-para-701-learning-feedback-loop
+    required: true
+    passRequired: true
+  - content: N-para-701-agent-pods-nevrland
+    required: true
+  - content: Q-para-701-agent-pods-nevrland
+    required: true
+    passRequired: true

package/dist/university-content/quizzes/Q-para-001-build-something.yaml

@@ -0,0 +1,46 @@
+id: Q-para-001-build-something
+title: 'PARA 001: Quick Start — Build With the Team'
+description: 'Quiz for lesson: Build With the Team'
+author: paradigm
+created: '2026-04-22'
+updated: '2026-04-22'
+tags:
+  - course
+  - para-001
+symbols: []
+difficulty: beginner
+passThreshold: 0.7
+category: paradigm-core
+origin: imported
+source: courses/para-001.json
+questions:
+  - id: q1
+    question: You built a new API endpoint without running quick-check or orchestration. The code works fine. On minimal enforcement, what happens when you commit?
+    choices:
+      A: The commit is blocked — orchestration is always required
+      B: The commit succeeds but the stop hook warns that no orchestration record exists for the changed files
+      C: Nothing — minimal enforcement has no checks
+      D: The commit is reverted automatically
+      E: Git rejects the commit because the pre-commit hook fails
+    correct: B
+    explanation: On minimal enforcement, orchestration-required is set to off, so the stop hook does not block. However, the purpose-coverage check (which is set to warn on minimal) may warn if you did not create a .purpose file for the new endpoint. The commit succeeds either way — minimal enforcement never blocks. But you have no orchestration record, no Rune compliance report, and no structured review.
+  - id: q2
+    question: 'During the build step, Rune creates a symbol plan with #health-check as a component. After the builder writes the code, Rune''s compliance report says "1 component, 0 aspects — blocking." Why is this a problem?'
+    choices:
+      A: Aspects are required for documentation completeness but have no real purpose
+      B: Every component needs at least one aspect (rule, constraint, or configuration) — the 1:1 ratio means you must define what rules govern the health endpoint
+      C: Rune made an error — health endpoints do not need aspects
+      D: The builder should have created the aspect automatically
+      E: This only matters on strict enforcement
+    correct: B
+    explanation: 'Rune enforces a 1:1 component-to-aspect ratio. Even a health endpoint has rules: response format, which checks it runs, timeout behavior, whether it includes dependency status. Defining an aspect like ~health-check-format forces you to document what the endpoint actually guarantees. This is not busywork — it is how Paradigm ensures every component has a documented contract.'
+  - id: q3
+    question: 'The commit message for your feature reads: feat(#health-check): add GET /health endpoint. The Symbols: trailer says Symbols: #health-check. What does the post-commit hook do with this information?'
+    choices:
+      A: Nothing — the Symbols trailer is just for human readability
+      B: 'It parses the Symbols trailer and records the commit in Paradigm''s history system, linking the change to #health-check for traceability'
+      C: 'It validates that #health-check exists in a .purpose file'
+      D: It sends a notification to the agent team
+      E: It automatically creates a changelog entry
+    correct: B
+    explanation: 'The post-commit hook parses the Symbols: trailer and records the commit in Paradigm''s history system. This creates a traceable link: commit → symbols affected. Later, when someone asks "what changed about #health-check?" or runs paradigm_history_context, the answer includes this commit. The pre-commit hook handles index rebuilding; the post-commit hook handles history capture.'

package/dist/university-content/quizzes/Q-para-001-meet-the-team.yaml

@@ -0,0 +1,46 @@
+id: Q-para-001-meet-the-team
+title: 'PARA 001: Quick Start — Meet Your Agent Team'
+description: 'Quiz for lesson: Meet Your Agent Team'
+author: paradigm
+created: '2026-04-22'
+updated: '2026-04-22'
+tags:
+  - course
+  - para-001
+symbols: []
+difficulty: beginner
+passThreshold: 0.7
+category: paradigm-core
+origin: imported
+source: courses/para-001.json
+questions:
+  - id: q1
+    question: Your project is a React frontend with no backend. Which of these agents would paradigm shift likely NOT include in your roster?
+    choices:
+      A: Builder — every project needs code implementation
+      B: A database specialist — there is no database in a frontend-only project
+      C: Reviewer — code review is universal
+      D: compliance — symbol coverage applies to all projects
+      E: security — even frontend apps have security concerns (XSS, CSRF)
+    correct: B
+    explanation: Specialized agents like a database specialist are only rostered when the project type matches. A React frontend with no backend has no database layer, so database agents would not be selected. The core team (including the security role — frontend security matters too) appears in every roster. Specialized and ecosystem agents are added based on detection.
+  - id: q2
+    question: 'The Architect uses opus (tier-1) while the Builder uses haiku (tier-3). A junior developer asks: "Does that mean the builder writes worse code?" How do you explain?'
+    choices:
+      A: Yes — tier-3 is lower quality, but it is faster and cheaper
+      B: No — tiers match complexity, not quality. Architecture requires open-ended reasoning (opus). Building is well-defined implementation work where speed matters more (haiku).
+      C: The tiers are just labels with no real difference
+      D: The builder should be upgraded to opus for important features
+      E: All agents should use the same model for consistency
+    correct: B
+    explanation: Model tier assignment is about matching the nature of the work, not ranking quality. Architectural design is open-ended — "how should we structure this?" benefits from deeper reasoning. Implementation is well-defined — "write this function that does X" benefits from speed. A fast model writing clearly specified code often produces better results than an overthinking model.
+  - id: q3
+    question: You want to add a DevOps specialist agent to your web project's roster. What command would you use?
+    choices:
+      A: Edit roster.yaml by hand and add the agent definition
+      B: paradigm agent activate devops — it adds the agent to your project roster
+      C: paradigm shift --add-agent devops
+      D: Re-run paradigm shift and hope it detects the need
+      E: DevOps agents cannot be added to web projects
+    correct: B
+    explanation: paradigm agent activate <id> adds an agent to your project roster. This is the proper way to customize your team — the CLI updates roster.yaml, agents.yaml, and any related configuration atomically. While you could edit roster.yaml by hand, using the CLI ensures all related files stay in sync.

package/dist/university-content/quizzes/Q-para-001-shift-setup.yaml

@@ -0,0 +1,46 @@
+id: Q-para-001-shift-setup
+title: 'PARA 001: Quick Start — Your First paradigm shift'
+description: 'Quiz for lesson: Your First paradigm shift'
+author: paradigm
+created: '2026-04-22'
+updated: '2026-04-22'
+tags:
+  - course
+  - para-001
+symbols: []
+difficulty: beginner
+passThreshold: 0.7
+category: paradigm-core
+origin: imported
+source: courses/para-001.json
+questions:
+  - id: q1
+    question: You just ran paradigm shift in a Node.js project. Which of the following was NOT created or configured automatically?
+    choices:
+      A: .paradigm/config.yaml with discipline auto-detected from package.json
+      B: CLAUDE.md with AI instructions derived from your configuration
+      C: A comprehensive test suite for your existing code
+      D: Git hooks for automated compliance checking
+      E: .paradigm/roster.yaml with agents suited for a Node.js project
+    correct: C
+    explanation: paradigm shift sets up Paradigm metadata and tooling — it does not generate tests, modify your source code, or create application logic. It creates configuration, instruction files, hooks, and an agent roster. Testing is handled by the tester agent during orchestration, not during initialization.
+  - id: q2
+    question: After running paradigm shift, you edit .paradigm/config.yaml to change your enforcement level. Now CLAUDE.md is out of date. How do you update it?
+    choices:
+      A: Edit CLAUDE.md manually to match your changes
+      B: Run paradigm shift again — it regenerates CLAUDE.md from your updated config
+      C: Delete CLAUDE.md and it will regenerate on the next commit
+      D: Run paradigm sync to rebuild only the instruction files
+      E: Both B and D would work — shift re-runs all steps including sync, while sync targets just the instruction files
+    correct: E
+    explanation: CLAUDE.md is a derived file — always generated from config, never hand-edited. Both paradigm shift (full re-run) and paradigm sync (targeted) will regenerate it. Use sync when you only changed config; use shift when you want the full pipeline (migrate, scan, hooks, etc.).
+  - id: q3
+    question: A teammate says "I ran paradigm shift but it broke my project — hooks are blocking my commits." This should not happen with default settings. What likely went wrong?
+    choices:
+      A: paradigm shift always uses strict enforcement
+      B: The project already had a config.yaml with enforcement level set to strict or balanced from a previous setup
+      C: Hooks always block on the first run to teach discipline
+      D: The teammate's Git version is incompatible with Paradigm hooks
+      E: paradigm shift requires admin privileges to install hooks
+    correct: B
+    explanation: New projects default to minimal enforcement, which warns but never blocks. But paradigm shift is idempotent — if the project already had a .paradigm/config.yaml with a higher enforcement level, shift preserves that setting. The teammate's project was likely previously configured with balanced or strict enforcement. Check config.yaml and adjust enforcement.level if needed.

package/dist/university-content/quizzes/Q-para-101-component-types.yaml

@@ -0,0 +1,46 @@
+id: Q-para-101-component-types
+title: 'PARA 101: Foundations — Component Types & Hierarchy'
+description: 'Quiz for lesson: Component Types & Hierarchy'
+author: paradigm
+created: '2026-04-22'
+updated: '2026-04-22'
+tags:
+  - course
+  - para-101
+symbols: []
+difficulty: beginner
+passThreshold: 0.7
+category: paradigm-core
+origin: imported
+source: courses/para-101.json
+questions:
+  - id: q1
+    question: What does the `type` field on a component describe?
+    choices:
+      A: The programming language the component is written in
+      B: The structural role of the component (e.g., service, view, router)
+      C: The business domain the component belongs to
+      D: The test coverage level of the component
+      E: The deployment environment for the component
+    correct: B
+    explanation: The `type` field describes a component's structural role — what the code IS architecturally (service, view, router, filter, etc.). Business domain classification uses tags instead.
+  - id: q2
+    question: Where should the `parent` relationship be declared?
+    choices:
+      A: On the parent component, listing all children
+      B: In a separate relationships.yaml file
+      C: 'On the child component, referencing the parent with a # symbol'
+      D: In portal.yaml alongside gate definitions
+      E: In the config.yaml component_types glossary
+    correct: C
+    explanation: 'Parent is declared on the child component using a `parent: "#parent-name"` field. This keeps .purpose files decentralized — you don''t need to maintain rosters on parent components.'
+  - id: q3
+    question: A `PaymentService` handles payment processing and integrates with Stripe. How should it be documented?
+    choices:
+      A: '`type: integration` with no tags'
+      B: '`type: service` with `tags: [integration, feature]`'
+      C: '`tags: [service, integration]` with no type'
+      D: '`type: feature` with `tags: [service]`'
+      E: '`type: service-integration` combining both concepts'
+    correct: B
+    explanation: 'Type describes what the code IS (a service), while tags describe behavior and domain (it''s an integration and a feature). The correct approach is `type: service` with `tags: [integration, feature]`.'