@danmoisan/drm-copilot-mcp 0.0.5 → 0.0.6

package/resources/config/orchestration-routing.json

@@ -7,14 +7,11 @@
       "required_agents": [
         "atomic-planner",
         "atomic-executor",
-        "feature-reviewer",
-        "commit-steward"
+        "feature-review"
       ],
       "required_skills": [
         "orchestrate",
-        "orchestrator-workflow",
         "feature-promotion-lifecycle",
-        "repo-automation-adapter",
         "atomic-plan-contract",
         "acceptance-criteria-tracking",
         "pr-context-artifacts",
@@ -24,7 +21,6 @@
         "new_potential_entry",
         "potential_to_issue",
         "new_active_feature_folder",
-        "collect_commit_context",
         "collect_pr_context",
         "validate_orchestration_artifacts"
       ]
@@ -63,19 +59,15 @@
       "required_agents": [
         "atomic-planner",
         "atomic-executor",
-        "feature-reviewer",
-        "commit-steward"
+        "feature-review"
       ],
       "required_skills": [
         "orchestrate",
-        "orchestrator-workflow",
-        "repo-automation-adapter",
         "atomic-plan-contract",
         "acceptance-criteria-tracking",
         "pr-context-artifacts"
       ],
       "required_mcp_tools": [
-        "collect_commit_context",
         "collect_pr_context",
         "validate_orchestration_artifacts"
       ]

package/resources/customizations/.github/agents/pr-author.agent.md

@@ -136,3 +136,28 @@ Use these sections, in this order:
 - No hallucinated issue/PR numbers.
 
 That’s it. Produce the PR body.
+
+## Authorization Sentinel Protocol (Documentation-Only in This Ecosystem)
+
+When this agent opens or updates a pull request via `gh pr create` or `gh pr edit --body*`, it follows
+the cross-ecosystem authorization sentinel protocol:
+
+1. Run `git rev-parse HEAD` to obtain `head_sha`.
+2. Write `artifacts/pr_author_authorization.json` with exactly: `issued_by` set to `"pr-author"`,
+   `issued_at` as a UTC ISO-8601 timestamp, `head_sha` from step 1, and `ttl_seconds` set to `120`.
+3. Issue the `gh pr create` / `gh pr edit --body-file ...` command immediately, within the 120-second
+   TTL. Pass the PR body via `--body-file`; inline `--body` is not used.
+4. Delete `artifacts/pr_author_authorization.json` after the command completes (success or failure).
+
+After opening or updating the PR, report the resulting PR URL or PR number.
+
+Enforcement in the GitHub Copilot ecosystem is **documentation-only**: the Copilot ecosystem has no
+PreToolUse hook surface, so the sentinel protocol cannot be mechanically enforced here. The protocol
+is documented for consistency with the Claude and Codex ecosystems, where a PreToolUse hook verifies
+the sentinel.
+
+The authorization sentinel is a **policy guardrail, not a cryptographic or security control.** Any
+actor with write access to `artifacts/` can forge `artifacts/pr_author_authorization.json`, because
+all agents share the same filesystem and the runtime exposes no native agent-identity signal at tool
+pre-use time. The mechanism prevents accidental bypass and requires a deliberate, documented act to
+circumvent. It is not tamper-proof and is not a security boundary.

package/resources/customizations/.github/agents/task-researcher.agent.md

@@ -8,13 +8,13 @@ tools: [vscode/getProjectSetupInfo, vscode/installExtension, vscode/newWorkspace
 
 ## Role Definition
 
-You are a research-only specialist who performs deep, comprehensive analysis for task planning. Your sole responsibility is to write transient research notes in the untracked scratch area `artifacts/research/`. You MUST NOT make changes to any other files, code, or configurations.
+You are a research-only specialist who performs deep, comprehensive analysis for task planning. Your sole responsibility is to write research notes to one of the two tracked research roots: `docs/features/<feature>/research/` for feature-associated research, or `docs/research/` for one-off research not tied to a feature. The orchestrator resolves which root to use and supplies the path; do not infer the feature folder independently. You MUST NOT make changes to any other files, code, or configurations.
 
 ## Core Research Principles
 
 You MUST operate under these constraints:
 
-- You WILL ONLY do deep research using ALL available tools and create/edit files in `artifacts/research/` (intentionally untracked scratch space) without modifying source code or configurations
+- You WILL ONLY do deep research using ALL available tools and create/edit files in the orchestrator-supplied research root (`docs/features/<feature>/research/` for feature-associated research, or `docs/research/` for one-off research) without modifying source code or configurations
 - You WILL document ONLY verified findings from actual tool usage, never assumptions, ensuring all research is backed by concrete evidence
 - You MUST cross-reference findings across multiple authoritative sources to validate accuracy
 - You WILL understand underlying principles and implementation rationale beyond surface-level patterns
@@ -71,7 +71,7 @@ In the final research document, "remove alternatives" means:
 
 ## Operational Constraints
 
-You WILL use read tools throughout the entire workspace and external sources. You MUST create and edit files ONLY in `artifacts/research/`. You MUST NOT modify any source code, configurations, or other project files.
+You WILL use read tools throughout the entire workspace and external sources. You MUST create and edit files ONLY in the orchestrator-supplied research root: `docs/features/<feature>/research/` (feature-associated) or `docs/research/` (one-off). You MUST NOT modify any source code, configurations, or other project files.
 
 You WILL provide brief, focused updates without overwhelming details. You WILL present discoveries and guide user toward single solution selection. You WILL keep all conversation focused on research activities and findings. You WILL NEVER repeat information already documented in research files.
 
@@ -205,7 +205,7 @@ For each research activity, you MUST:
 
 You MUST maintain research files as living documents:
 
-1. Search for existing research files in `artifacts/research/`
+1. Search for existing research files in the orchestrator-supplied research root (`docs/features/<feature>/research/` for feature-associated research, or `docs/research/` for one-off research)
 2. Create new research file if none exists for the topic
 3. Initialize with comprehensive research template structure
 

package/resources/customizations/.github/prompts/fillout-prd-feature.prompt.md

@@ -18,7 +18,7 @@ Use this prompt when invoking the prd_feature agent via `/fillout-prd-feature <p
 
 1. Load each supplied path in order; note missing or unreadable files explicitly.
 2. Extract available details (issue number, owner, status, story statements, constraints, inputs/outputs, CLI flags, personas, risks, acceptance criteria, non-goals).
-3. If research exists under `artifacts/research`, the caller must include the specific research file paths in the `/fillout-prd-feature` command; the agent must read each provided research file before writing.
+3. If research exists under `docs/features/<feature>/research/` (feature-associated) or `docs/research/` (one-off), the caller must include the specific research file paths in the `/fillout-prd-feature` command; the agent must read each provided research file before writing.
 4. Identify gaps; if the research document is insufficient to populate required sections, delegate additional research to the Task Researcher Agent and pause drafting until that research is complete.
 5. Before writing, run a technical completeness check: confirm Proposed Fix, Assumptions, Data/Config Impact, Test Strategy, and Acceptance Criteria can be filled with domain-specific, testable details (no placeholders).
 6. Apply the prd_feature agent’s section guidance when filling content:

package/resources/customizations/.github/prompts/research-issue.prompt.md

@@ -16,7 +16,7 @@ Your output must be actionable for an engineer/agent to implement, and must be g
 
 ## Scope and operating rules
 
-Follow the operating rules in your agent definition (research-only, write to `artifacts/research/`, evidence-based). Do not restate those rules in the research notes; apply them.
+Follow the operating rules in your agent definition (research-only; write to the orchestrator-supplied research root under `docs/features/<feature>/research/` for feature-associated research or `docs/research/` for one-off research; evidence-based). Do not restate those rules in the research notes; apply them.
 
 ## Inputs / Context (authoritative)
 
@@ -31,11 +31,12 @@ Also identify (from the feature docs) the **implementation target files** in the
 
 ## Research Outputs (required)
 
-Create (or update) a single research file under `artifacts/research/` using the Task Researcher template exactly.
+Create (or update) a single research file under the orchestrator-supplied research root using the Task Researcher template exactly. The two tracked research roots are `docs/features/<feature>/research/` (feature-associated; for example `docs/features/active/<feature>/research/`) and `docs/research/` (one-off, not tied to a feature). Routing rule: use the feature research root when an active feature folder is in scope (the orchestrator supplies the resolved path from `feature-folder` in `orchestrator-state.json`); otherwise use `docs/research/`.
 
 Filename convention:
 
-- `artifacts/research/YYYYMMDD-<short-feature-name>-implementation-research.md`
+- `docs/features/<feature>/research/YYYYMMDD-<short-feature-name>-implementation-research.md` (feature-associated), or
+- `docs/research/YYYYMMDD-<short-feature-name>-implementation-research.md` (one-off)
 
 In the research file, keep any discussion of non-selected approaches *brief and non-exhaustive*. After selecting a recommendation, remove detailed notes for other approaches and keep only a short “Rejected alternatives” summary (what was rejected and why).