Alpha Build 0.5

.claude/commands/openspec/apply.md

@@ -0,0 +1,23 @@
+---
+name: OpenSpec: Apply
+description: Implement an approved OpenSpec change and keep tasks in sync.
+category: OpenSpec
+tags: [openspec, apply]
+---
+<!-- OPENSPEC:START -->
+**Guardrails**
+- Favor straightforward, minimal implementations first and add complexity only when it is requested or clearly required.
+- Keep changes tightly scoped to the requested outcome.
+- Refer to `openspec/AGENTS.md` (located inside the `openspec/` directory—run `ls openspec` or `openspec update` if you don't see it) if you need additional OpenSpec conventions or clarifications.
+
+**Steps**
+Track these steps as TODOs and complete them one by one.
+1. Read `changes/<id>/proposal.md`, `design.md` (if present), and `tasks.md` to confirm scope and acceptance criteria.
+2. Work through tasks sequentially, keeping edits minimal and focused on the requested change.
+3. Confirm completion before updating statuses—make sure every item in `tasks.md` is finished.
+4. Update the checklist after all work is done so each task is marked `- [x]` and reflects reality.
+5. Reference `openspec list` or `openspec show <item>` when additional context is required.
+
+**Reference**
+- Use `openspec show <id> --json --deltas-only` if you need additional context from the proposal while implementing.
+<!-- OPENSPEC:END -->

.claude/commands/openspec/archive.md

@@ -0,0 +1,27 @@
+---
+name: OpenSpec: Archive
+description: Archive a deployed OpenSpec change and update specs.
+category: OpenSpec
+tags: [openspec, archive]
+---
+<!-- OPENSPEC:START -->
+**Guardrails**
+- Favor straightforward, minimal implementations first and add complexity only when it is requested or clearly required.
+- Keep changes tightly scoped to the requested outcome.
+- Refer to `openspec/AGENTS.md` (located inside the `openspec/` directory—run `ls openspec` or `openspec update` if you don't see it) if you need additional OpenSpec conventions or clarifications.
+
+**Steps**
+1. Determine the change ID to archive:
+   - If this prompt already includes a specific change ID (for example inside a `<ChangeId>` block populated by slash-command arguments), use that value after trimming whitespace.
+   - If the conversation references a change loosely (for example by title or summary), run `openspec list` to surface likely IDs, share the relevant candidates, and confirm which one the user intends.
+   - Otherwise, review the conversation, run `openspec list`, and ask the user which change to archive; wait for a confirmed change ID before proceeding.
+   - If you still cannot identify a single change ID, stop and tell the user you cannot archive anything yet.
+2. Validate the change ID by running `openspec list` (or `openspec show <id>`) and stop if the change is missing, already archived, or otherwise not ready to archive.
+3. Run `openspec archive <id> --yes` so the CLI moves the change and applies spec updates without prompts (use `--skip-specs` only for tooling-only work).
+4. Review the command output to confirm the target specs were updated and the change landed in `changes/archive/`.
+5. Validate with `openspec validate --strict` and inspect with `openspec show <id>` if anything looks off.
+
+**Reference**
+- Use `openspec list` to confirm change IDs before archiving.
+- Inspect refreshed specs with `openspec list --specs` and address any validation issues before handing off.
+<!-- OPENSPEC:END -->

.claude/commands/openspec/proposal.md

@@ -0,0 +1,28 @@
+---
+name: OpenSpec: Proposal
+description: Scaffold a new OpenSpec change and validate strictly.
+category: OpenSpec
+tags: [openspec, change]
+---
+<!-- OPENSPEC:START -->
+**Guardrails**
+- Favor straightforward, minimal implementations first and add complexity only when it is requested or clearly required.
+- Keep changes tightly scoped to the requested outcome.
+- Refer to `openspec/AGENTS.md` (located inside the `openspec/` directory—run `ls openspec` or `openspec update` if you don't see it) if you need additional OpenSpec conventions or clarifications.
+- Identify any vague or ambiguous details and ask the necessary follow-up questions before editing files.
+- Do not write any code during the proposal stage. Only create design documents (proposal.md, tasks.md, design.md, and spec deltas). Implementation happens in the apply stage after approval.
+
+**Steps**
+1. Review `openspec/project.md`, run `openspec list` and `openspec list --specs`, and inspect related code or docs (e.g., via `rg`/`ls`) to ground the proposal in current behaviour; note any gaps that require clarification.
+2. Choose a unique verb-led `change-id` and scaffold `proposal.md`, `tasks.md`, and `design.md` (when needed) under `openspec/changes/<id>/`.
+3. Map the change into concrete capabilities or requirements, breaking multi-scope efforts into distinct spec deltas with clear relationships and sequencing.
+4. Capture architectural reasoning in `design.md` when the solution spans multiple systems, introduces new patterns, or demands trade-off discussion before committing to specs.
+5. Draft spec deltas in `changes/<id>/specs/<capability>/spec.md` (one folder per capability) using `## ADDED|MODIFIED|REMOVED Requirements` with at least one `#### Scenario:` per requirement and cross-reference related capabilities when relevant.
+6. Draft `tasks.md` as an ordered list of small, verifiable work items that deliver user-visible progress, include validation (tests, tooling), and highlight dependencies or parallelizable work.
+7. Validate with `openspec validate <id> --strict` and resolve every issue before sharing the proposal.
+
+**Reference**
+- Use `openspec show <id> --json --deltas-only` or `openspec show <spec> --type spec` to inspect details when validation fails.
+- Search existing requirements with `rg -n "Requirement:|Scenario:" openspec/specs` before writing new ones.
+- Explore the codebase with `rg <keyword>`, `ls`, or direct file reads so proposals align with current implementation realities.
+<!-- OPENSPEC:END -->

.claude/settings.local.json

@@ -0,0 +1,28 @@
+{
+  "permissions": {
+    "allow": [
+      "Bash(mkdir:*)",
+      "Bash(openspec validate:*)",
+      "Bash(openspec list:*)",
+      "Bash(npm init:*)",
+      "Bash(npm install:*)",
+      "Bash(npm run build:*)",
+      "Bash(npm show:*)",
+      "Bash(npm run test)",
+      "Bash(openspec archive:*)",
+      "Bash(dir:*)",
+      "Bash(node test-mcp-prompts.mjs:*)",
+      "Bash(node dist/server.js:*)",
+      "Bash(node debug-mcp.mjs:*)",
+      "Bash(findstr:*)",
+      "Bash(node test-mcp-sdk.mjs:*)",
+      "Bash(node scripts/validate-knowledge.mjs:*)",
+      "Bash(npx openspec:*)",
+      "Bash(node:*)",
+      "Bash(GITHUB_TOKEN=\"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\" node \"C:/temp/Packager-MCP/test-github.mjs\")",
+      "Bash(find:*)"
+    ],
+    "deny": [],
+    "ask": []
+  }
+}

.github/ISSUE_TEMPLATE/knowledge-update.md

@@ -0,0 +1,36 @@
+---
+name: Knowledge Base Update
+about: Request an update to the knowledge base content
+title: '[KB] '
+labels: knowledge-update
+assignees: ''
+---
+
+## Update Type
+
+- [ ] Content correction (error in existing documentation)
+- [ ] New content request (missing documentation)
+- [ ] PSADT version update (new PSADT release)
+- [ ] Example request (new deployment example)
+
+## Description
+
+<!-- Describe the knowledge base update needed -->
+
+## Affected Files
+
+<!-- List the files that need to be updated, if known -->
+
+- [ ] `src/knowledge/psadt/`
+- [ ] `src/knowledge/installers/`
+- [ ] `src/knowledge/patterns/`
+- [ ] `src/knowledge/reference/`
+- [ ] `ReferenceKnowledge/`
+
+## Source Reference
+
+<!-- If applicable, provide a link to the source material or official documentation -->
+
+## Additional Context
+
+<!-- Add any other context about the request here -->

.github/ISSUE_TEMPLATE/new-example.md

@@ -0,0 +1,56 @@
+---
+name: New Deployment Example
+about: Submit or request a new PSADT deployment example
+title: '[Example] '
+labels: example, knowledge-update
+assignees: ''
+---
+
+## Application Information
+
+| Field | Value |
+|-------|-------|
+| Application Name | |
+| Application Version | |
+| Installer Type | MSI / EXE / MSIX |
+| Publisher | |
+
+## Installer Details
+
+**Installer Technology** (for EXE):
+- [ ] Inno Setup
+- [ ] NSIS / Nullsoft
+- [ ] InstallShield
+- [ ] WiX Burn
+- [ ] Other: ___
+
+**Silent Install Arguments**:
+```
+```
+
+**Silent Uninstall Arguments**:
+```
+```
+
+## Detection Method
+
+<!-- Describe how to detect if the application is installed -->
+
+- Detection Type: File / Registry / MSI Product Code / Script
+- Detection Details:
+
+## PSADT Script (if available)
+
+<!-- If you have a working PSADT script, paste it here or attach as a file -->
+
+```powershell
+# Paste script here
+```
+
+## Notable Challenges
+
+<!-- Describe any challenges encountered during packaging -->
+
+## Additional Context
+
+<!-- Add any other context about the example here -->

.github/workflows/validate-knowledge.yml

@@ -0,0 +1,48 @@
+name: Validate Knowledge Base
+
+on:
+  push:
+    paths:
+      - 'src/knowledge/**'
+      - 'ReferenceKnowledge/**'
+      - 'scripts/validate-knowledge.mjs'
+  pull_request:
+    paths:
+      - 'src/knowledge/**'
+      - 'ReferenceKnowledge/**'
+      - 'scripts/validate-knowledge.mjs'
+  workflow_dispatch:
+
+jobs:
+  validate:
+    runs-on: ubuntu-latest
+
+    steps:
+      - name: Checkout repository
+        uses: actions/checkout@v4
+
+      - name: Setup Node.js
+        uses: actions/setup-node@v4
+        with:
+          node-version: '20'
+
+      - name: Install dependencies
+        run: npm ci
+
+      - name: Validate knowledge base
+        run: npm run validate:knowledge
+
+      - name: Check for markdownlint (optional)
+        id: check-mdl
+        run: |
+          if command -v markdownlint &> /dev/null; then
+            echo "available=true" >> $GITHUB_OUTPUT
+          else
+            echo "available=false" >> $GITHUB_OUTPUT
+          fi
+        continue-on-error: true
+
+      - name: Run markdownlint (if available)
+        if: steps.check-mdl.outputs.available == 'true'
+        run: markdownlint 'src/knowledge/**/*.md' --config .markdownlint.json
+        continue-on-error: true

.gitignore

@@ -0,0 +1,9 @@
+node_modules/
+dist/
+*.log
+
+# Config files with secrets
+packager-mcp.yaml
+packager-mcp.yml
+config.yaml
+config.yml

.markdownlint.json

@@ -0,0 +1,18 @@
+{
+  "default": true,
+  "MD013": {
+    "line_length": 200,
+    "code_blocks": false,
+    "tables": false
+  },
+  "MD024": {
+    "allow_different_nesting": true
+  },
+  "MD033": {
+    "allowed_elements": ["br", "details", "summary", "sup", "sub"]
+  },
+  "MD041": false,
+  "MD046": {
+    "style": "fenced"
+  }
+}

AGENTS.md

@@ -0,0 +1,18 @@
+<!-- OPENSPEC:START -->
+# OpenSpec Instructions
+
+These instructions are for AI assistants working in this project.
+
+Always open `@/openspec/AGENTS.md` when the request:
+- Mentions planning or proposals (words like proposal, spec, change, plan)
+- Introduces new capabilities, breaking changes, architecture shifts, or big performance/security work
+- Sounds ambiguous and you need the authoritative spec before coding
+
+Use `@/openspec/AGENTS.md` to learn:
+- How to create and apply change proposals
+- Spec format and conventions
+- Project structure and guidelines
+
+Keep this managed block so 'openspec update' can refresh the instructions.
+
+<!-- OPENSPEC:END -->