@thiagodiogo/pscode 2.0.0 → 2.1.0

package/schemas/workspace-planning/schema.yaml

@@ -1,72 +1,72 @@
-name: workspace-planning
-version: 1
-description: Workspace planning workflow for cross-area changes
-artifacts:
-  - id: proposal
-    generates: proposal.md
-    description: Shared workspace proposal with the product goal, scope, affected areas, and impact
-    template: proposal.md
-    instruction: |
-      Create the workspace-level proposal that captures the shared product goal once.
-
-      Sections:
-      - **Why**: Explain the product goal or problem in 1-2 concise paragraphs.
-      - **What Changes**: List the cross-area behavior, workflow, or capability changes.
-      - **Affected Areas**: Name known affected areas using registered workspace link names where applicable. If scope is still being explored, say what remains unresolved.
-      - **Capabilities**: Identify workspace-scoped capabilities that need specs. Area-specific requirements should later live under `specs/<area-or-repo>/<capability>/spec.md`.
-      - **Impact**: Summarize user-facing impact, planning impact, and likely implementation homes without creating repo-local artifacts.
-
-      Keep linked repos and folders as exploration context until an explicit implementation workflow selects an affected area.
-    requires: []
-
-  - id: specs
-    generates: "specs/**/*.md"
-    description: Workspace-scoped specs organized by affected area and capability
-    template: spec.md
-    instruction: |
-      Create workspace-scoped specification files that define WHAT should change.
-
-      Use `specs/<area-or-repo>/<capability>/spec.md` for area-specific requirements. The first path segment should be a registered workspace link name when a registered area owns the requirement. If the area is unresolved, use an exploratory area name and make the unresolved question explicit in the requirement or scenario.
-
-      These specs are planning artifacts under the workspace change root. Do not create repo-local spec files in linked repos during workspace planning.
-
-      Delta operations (use ## headers):
-      - **ADDED Requirements**: New workspace-scoped behavior.
-      - **MODIFIED Requirements**: Changed behavior; include the full updated requirement.
-      - **REMOVED Requirements**: Deprecated behavior with Reason and Migration.
-      - **RENAMED Requirements**: Name changes only; use FROM:/TO: format.
-
-      Each requirement must use SHALL/MUST language and include at least one `#### Scenario:` block.
-    requires:
-      - proposal
-
-  - id: design
-    generates: design.md
-    description: Cross-area technical design and coordination decisions
-    template: design.md
-    instruction: |
-      Create the cross-area design document for workspace planning.
-
-      Focus on decisions that affect multiple areas, handoffs between areas, shared constraints, sequencing risks, and how the workspace plan should stay the source of truth. Avoid line-by-line implementation details and do not instruct agents to edit linked repos until an explicit implementation workflow provides an allowed edit root.
-    requires:
-      - proposal
-
-  - id: tasks
-    generates: tasks.md
-    description: Coordination checklist for workspace planning and later affected-area implementation
-    template: tasks.md
-    instruction: |
-      Create the workspace coordination task list.
-
-      Group tasks by phase or affected area as useful. Each actionable item must be a checkbox using `- [ ]`. When implementation tasks are area-specific, name the affected area and keep the task at planning granularity until a later implementation workflow selects an allowed edit root.
-    requires:
-      - specs
-      - design
-
-apply:
-  requires: [tasks]
-  tracks: tasks.md
-  instruction: |
-    Read the workspace planning context from status and instructions output before applying.
-    Select an affected area and confirm an allowed edit root before making implementation edits.
-    Until an explicit implementation context is available, treat linked repos and folders as read-only exploration context.
+name: workspace-planning
+version: 1
+description: Workspace planning workflow for cross-area changes
+artifacts:
+  - id: proposal
+    generates: proposal.md
+    description: Shared workspace proposal with the product goal, scope, affected areas, and impact
+    template: proposal.md
+    instruction: |
+      Create the workspace-level proposal that captures the shared product goal once.
+
+      Sections:
+      - **Why**: Explain the product goal or problem in 1-2 concise paragraphs.
+      - **What Changes**: List the cross-area behavior, workflow, or capability changes.
+      - **Affected Areas**: Name known affected areas using registered workspace link names where applicable. If scope is still being explored, say what remains unresolved.
+      - **Capabilities**: Identify workspace-scoped capabilities that need specs. Area-specific requirements should later live under `specs/<area-or-repo>/<capability>/spec.md`.
+      - **Impact**: Summarize user-facing impact, planning impact, and likely implementation homes without creating repo-local artifacts.
+
+      Keep linked repos and folders as exploration context until an explicit implementation workflow selects an affected area.
+    requires: []
+
+  - id: specs
+    generates: "specs/**/*.md"
+    description: Workspace-scoped specs organized by affected area and capability
+    template: spec.md
+    instruction: |
+      Create workspace-scoped specification files that define WHAT should change.
+
+      Use `specs/<area-or-repo>/<capability>/spec.md` for area-specific requirements. The first path segment should be a registered workspace link name when a registered area owns the requirement. If the area is unresolved, use an exploratory area name and make the unresolved question explicit in the requirement or scenario.
+
+      These specs are planning artifacts under the workspace change root. Do not create repo-local spec files in linked repos during workspace planning.
+
+      Delta operations (use ## headers):
+      - **ADDED Requirements**: New workspace-scoped behavior.
+      - **MODIFIED Requirements**: Changed behavior; include the full updated requirement.
+      - **REMOVED Requirements**: Deprecated behavior with Reason and Migration.
+      - **RENAMED Requirements**: Name changes only; use FROM:/TO: format.
+
+      Each requirement must use SHALL/MUST language and include at least one `#### Scenario:` block.
+    requires:
+      - proposal
+
+  - id: design
+    generates: design.md
+    description: Cross-area technical design and coordination decisions
+    template: design.md
+    instruction: |
+      Create the cross-area design document for workspace planning.
+
+      Focus on decisions that affect multiple areas, handoffs between areas, shared constraints, sequencing risks, and how the workspace plan should stay the source of truth. Avoid line-by-line implementation details and do not instruct agents to edit linked repos until an explicit implementation workflow provides an allowed edit root.
+    requires:
+      - proposal
+
+  - id: tasks
+    generates: tasks.md
+    description: Coordination checklist for workspace planning and later affected-area implementation
+    template: tasks.md
+    instruction: |
+      Create the workspace coordination task list.
+
+      Group tasks by phase or affected area as useful. Each actionable item must be a checkbox using `- [ ]`. When implementation tasks are area-specific, name the affected area and keep the task at planning granularity until a later implementation workflow selects an allowed edit root.
+    requires:
+      - specs
+      - design
+
+apply:
+  requires: [tasks]
+  tracks: tasks.md
+  instruction: |
+    Read the workspace planning context from status and instructions output before applying.
+    Select an affected area and confirm an allowed edit root before making implementation edits.
+    Until an explicit implementation context is available, treat linked repos and folders as read-only exploration context.

package/schemas/workspace-planning/templates/design.md

@@ -1,33 +1,33 @@
-## Context
-
-Summarize the workspace planning context, relevant linked areas, and constraints.
-
-## Goals / Non-Goals
-
-**Goals:**
--
-
-**Non-Goals:**
-- Creating repo-local implementation artifacts before an affected area is selected.
-
-## Decisions
-
-### Decision: <title>
-
-<decision and rationale>
-
-Alternative considered: <alternative and why it was not chosen>
-
-## Risks / Trade-offs
-
-- <risk> -> <mitigation>
-
-## Coordination Notes
-
-- Affected areas:
-- Open handoffs:
-- Implementation entry criteria:
-
-## Open Questions
-
--
+## Context
+
+Summarize the workspace planning context, relevant linked areas, and constraints.
+
+## Goals / Non-Goals
+
+**Goals:**
+-
+
+**Non-Goals:**
+- Creating repo-local implementation artifacts before an affected area is selected.
+
+## Decisions
+
+### Decision: <title>
+
+<decision and rationale>
+
+Alternative considered: <alternative and why it was not chosen>
+
+## Risks / Trade-offs
+
+- <risk> -> <mitigation>
+
+## Coordination Notes
+
+- Affected areas:
+- Open handoffs:
+- Implementation entry criteria:
+
+## Open Questions
+
+-

package/schemas/workspace-planning/templates/proposal.md

@@ -1,28 +1,28 @@
-## Why
-
-Describe the shared product goal, problem, or opportunity that makes this workspace-level change worth planning.
-
-## What Changes
-
--
-
-## Affected Areas
-
-- Known:
-- Unresolved:
-
-## Capabilities
-
-### New Capabilities
-
--
-
-### Modified Capabilities
-
--
-
-## Impact
-
-- Workspace planning:
-- Linked repos or folders:
-- User-facing behavior:
+## Why
+
+Describe the shared product goal, problem, or opportunity that makes this workspace-level change worth planning.
+
+## What Changes
+
+-
+
+## Affected Areas
+
+- Known:
+- Unresolved:
+
+## Capabilities
+
+### New Capabilities
+
+-
+
+### Modified Capabilities
+
+-
+
+## Impact
+
+- Workspace planning:
+- Linked repos or folders:
+- User-facing behavior:

package/schemas/workspace-planning/templates/spec.md

@@ -1,9 +1,9 @@
-## ADDED Requirements
-
-### Requirement: <workspace requirement name>
-The workspace plan SHALL describe the required behavior and affected area without creating repo-local artifacts during planning.
-
-#### Scenario: <scenario name>
-- **GIVEN** <context>
-- **WHEN** <action>
-- **THEN** <observable result>
+## ADDED Requirements
+
+### Requirement: <workspace requirement name>
+The workspace plan SHALL describe the required behavior and affected area without creating repo-local artifacts during planning.
+
+#### Scenario: <scenario name>
+- **GIVEN** <context>
+- **WHEN** <action>
+- **THEN** <observable result>

package/schemas/workspace-planning/templates/tasks.md

@@ -1,15 +1,15 @@
-## 1. Workspace Planning
-
-- [ ] 1.1 Confirm the shared product goal and unresolved scope questions.
-- [ ] 1.2 Identify affected areas using registered workspace link names where applicable.
-- [ ] 1.3 Review workspace-scoped specs and design before selecting implementation areas.
-
-## 2. Affected Area Implementation
-
-- [ ] 2.1 Select an affected area and confirm its allowed edit root before implementation.
-- [ ] 2.2 Create or update repo-local implementation artifacts only after the area is selected.
-
-## 3. Verification
-
-- [ ] 3.1 Verify workspace planning artifacts remain the source of truth.
-- [ ] 3.2 Record manual acceptance evidence and follow-up fixes.
+## 1. Workspace Planning
+
+- [ ] 1.1 Confirm the shared product goal and unresolved scope questions.
+- [ ] 1.2 Identify affected areas using registered workspace link names where applicable.
+- [ ] 1.3 Review workspace-scoped specs and design before selecting implementation areas.
+
+## 2. Affected Area Implementation
+
+- [ ] 2.1 Select an affected area and confirm its allowed edit root before implementation.
+- [ ] 2.2 Create or update repo-local implementation artifacts only after the area is selected.
+
+## 3. Verification
+
+- [ ] 3.1 Verify workspace planning artifacts remain the source of truth.
+- [ ] 3.2 Record manual acceptance evidence and follow-up fixes.

package/scripts/postinstall.js

@@ -1,83 +1,83 @@
-#!/usr/bin/env node
-
-/**
- * Postinstall script that hints about shell completions
- *
- * Completion installation is opt-in: the user must run
- * `pscode completion install` explicitly. This script only
- * prints a one-line tip after npm install.
- *
- * The tip is suppressed when:
- * - CI=true environment variable is set
- * - PSCODE_NO_COMPLETIONS=1 environment variable is set
- * - dist/ directory doesn't exist (dev setup scenario)
- *
- * The script never fails npm install - all errors are caught and handled gracefully.
- */
-
-import { promises as fs } from 'fs';
-import path from 'path';
-import { fileURLToPath } from 'url';
-
-const __filename = fileURLToPath(import.meta.url);
-const __dirname = path.dirname(__filename);
-
-/**
- * Check if we should skip installation
- */
-function shouldSkipInstallation() {
-  // Skip in CI environments
-  if (process.env.CI === 'true' || process.env.CI === '1') {
-    return { skip: true, reason: 'CI environment detected' };
-  }
-
-  // Skip if user opted out
-  if (process.env.PSCODE_NO_COMPLETIONS === '1') {
-    return { skip: true, reason: 'PSCODE_NO_COMPLETIONS=1 set' };
-  }
-
-  return { skip: false };
-}
-
-/**
- * Check if dist/ directory exists
- */
-async function distExists() {
-  const distPath = path.join(__dirname, '..', 'dist');
-  try {
-    const stat = await fs.stat(distPath);
-    return stat.isDirectory();
-  } catch {
-    return false;
-  }
-}
-
-/**
- * Main function
- */
-async function main() {
-  try {
-    // Check if we should skip
-    const skipCheck = shouldSkipInstallation();
-    if (skipCheck.skip) {
-      // Silent skip - no output
-      return;
-    }
-
-    // Check if dist/ exists (skip silently if not - expected during dev setup)
-    if (!(await distExists())) {
-      return;
-    }
-
-    // Completions are opt-in — just print a hint
-    console.log(`\nTip: Run 'pscode completion install' for shell completions`);
-  } catch (error) {
-    // Fail gracefully - never break npm install
-  }
-}
-
-// Run main and handle any unhandled errors
-main().catch(() => {
-  // Silent failure - never break npm install
-  process.exit(0);
-});
+#!/usr/bin/env node
+
+/**
+ * Postinstall script that hints about shell completions
+ *
+ * Completion installation is opt-in: the user must run
+ * `pscode completion install` explicitly. This script only
+ * prints a one-line tip after npm install.
+ *
+ * The tip is suppressed when:
+ * - CI=true environment variable is set
+ * - PSCODE_NO_COMPLETIONS=1 environment variable is set
+ * - dist/ directory doesn't exist (dev setup scenario)
+ *
+ * The script never fails npm install - all errors are caught and handled gracefully.
+ */
+
+import { promises as fs } from 'fs';
+import path from 'path';
+import { fileURLToPath } from 'url';
+
+const __filename = fileURLToPath(import.meta.url);
+const __dirname = path.dirname(__filename);
+
+/**
+ * Check if we should skip installation
+ */
+function shouldSkipInstallation() {
+  // Skip in CI environments
+  if (process.env.CI === 'true' || process.env.CI === '1') {
+    return { skip: true, reason: 'CI environment detected' };
+  }
+
+  // Skip if user opted out
+  if (process.env.PSCODE_NO_COMPLETIONS === '1') {
+    return { skip: true, reason: 'PSCODE_NO_COMPLETIONS=1 set' };
+  }
+
+  return { skip: false };
+}
+
+/**
+ * Check if dist/ directory exists
+ */
+async function distExists() {
+  const distPath = path.join(__dirname, '..', 'dist');
+  try {
+    const stat = await fs.stat(distPath);
+    return stat.isDirectory();
+  } catch {
+    return false;
+  }
+}
+
+/**
+ * Main function
+ */
+async function main() {
+  try {
+    // Check if we should skip
+    const skipCheck = shouldSkipInstallation();
+    if (skipCheck.skip) {
+      // Silent skip - no output
+      return;
+    }
+
+    // Check if dist/ exists (skip silently if not - expected during dev setup)
+    if (!(await distExists())) {
+      return;
+    }
+
+    // Completions are opt-in — just print a hint
+    console.log(`\nTip: Run 'pscode completion install' for shell completions`);
+  } catch (error) {
+    // Fail gracefully - never break npm install
+  }
+}
+
+// Run main and handle any unhandled errors
+main().catch(() => {
+  // Silent failure - never break npm install
+  process.exit(0);
+});