aw-spec-cli 0.1.4 → 0.1.5

package/assets/.kilocode/workflows/aw-spec-taskstoissues.md

@@ -1,107 +0,0 @@
----
-name: "aw-spec-taskstoissues"
-description: "Convert existing tasks into actionable, dependency-ordered GitHub issues for the feature based on available design artifacts."
-argument-hint: "Optional filter or label for GitHub issues"
-compatibility: "Requires aw-spec project structure with .aw-spec/ directory"
-metadata:
-  author: "github-aw-spec"
-  source: "templates/commands/taskstoissues.md"
-user-invocable: true
-disable-model-invocation: false
----
-
-
-## User Input
-
-```text
-$ARGUMENTS
-```
-
-You **MUST** consider the user input before proceeding (if not empty).
-
-## Pre-Execution Checks
-
-**Check for extension hooks (before tasks-to-issues conversion)**:
-- Check if `.aw-spec/extensions.yml` exists in the project root.
-- If it exists, read it and look for entries under the `hooks.before_taskstoissues` key
-- If the YAML cannot be parsed or is invalid, skip hook checking silently and continue normally
-- Filter out hooks where `enabled` is explicitly `false`. Treat hooks without an `enabled` field as enabled by default.
-- For each remaining hook, do **not** attempt to interpret or evaluate hook `condition` expressions:
-  - If the hook has no `condition` field, or it is null/empty, treat the hook as executable
-  - If the hook defines a non-empty `condition`, skip the hook and leave condition evaluation to the HookExecutor implementation
-- When constructing slash commands from hook command names, replace dots (`.`) with hyphens (`-`). For example, `aw-spec.git.commit` → `/aw-spec-git-commit`.
-- For each executable hook, output the following based on its `optional` flag:
-  - **Optional hook** (`optional: true`):
-    ```
-    ## Extension Hooks
-
-    **Optional Pre-Hook**: {extension}
-    Command: `/{command}`
-    Description: {description}
-
-    Prompt: {prompt}
-    To execute: `/{command}`
-    ```
-  - **Mandatory hook** (`optional: false`):
-    ```
-    ## Extension Hooks
-
-    **Automatic Pre-Hook**: {extension}
-    Executing: `/{command}`
-    EXECUTE_COMMAND: {command}
-
-    Wait for the result of the hook command before proceeding to the Outline.
-    ```
-- If no hooks are registered or `.aw-spec/extensions.yml` does not exist, skip silently
-
-## Outline
-
-1. Run `.aw-spec/scripts/bash/check-prerequisites.sh --json --require-tasks --include-tasks` from repo root and parse FEATURE_DIR and AVAILABLE_DOCS list. All paths must be absolute. For single quotes in args like "I'm Groot", use escape syntax: e.g 'I'\''m Groot' (or double-quote if possible: "I'm Groot").
-1. **IF EXISTS**: Load `.aw-spec/memory/constitution.md` for project principles and governance constraints.
-1. From the executed script, extract the path to **tasks**.
-1. Get the Git remote by running:
-
-```bash
-git config --get remote.origin.url
-```
-
-> [!CAUTION]
-> ONLY PROCEED TO NEXT STEPS IF THE REMOTE IS A GITHUB URL
-
-1. For each task in the list, use the GitHub MCP server to create a new issue in the repository that is representative of the Git remote.
-
-> [!CAUTION]
-> UNDER NO CIRCUMSTANCES EVER CREATE ISSUES IN REPOSITORIES THAT DO NOT MATCH THE REMOTE URL
-
-## Post-Execution Checks
-
-**Check for extension hooks (after tasks-to-issues conversion)**:
-Check if `.aw-spec/extensions.yml` exists in the project root.
-- If it exists, read it and look for entries under the `hooks.after_taskstoissues` key
-- If the YAML cannot be parsed or is invalid, skip hook checking silently and continue normally
-- Filter out hooks where `enabled` is explicitly `false`. Treat hooks without an `enabled` field as enabled by default.
-- For each remaining hook, do **not** attempt to interpret or evaluate hook `condition` expressions:
-  - If the hook has no `condition` field, or it is null/empty, treat the hook as executable
-  - If the hook defines a non-empty `condition`, skip the hook and leave condition evaluation to the HookExecutor implementation
-- When constructing slash commands from hook command names, replace dots (`.`) with hyphens (`-`). For example, `aw-spec.git.commit` → `/aw-spec-git-commit`.
-- For each executable hook, output the following based on its `optional` flag:
-  - **Optional hook** (`optional: true`):
-    ```
-    ## Extension Hooks
-
-    **Optional Hook**: {extension}
-    Command: `/{command}`
-    Description: {description}
-
-    Prompt: {prompt}
-    To execute: `/{command}`
-    ```
-  - **Mandatory hook** (`optional: false`):
-    ```
-    ## Extension Hooks
-
-    **Automatic Hook**: {extension}
-    Executing: `/{command}`
-    EXECUTE_COMMAND: {command}
-    ```
-- If no hooks are registered or `.aw-spec/extensions.yml` does not exist, skip silently

package/assets/docs/UI.Visualization/PACKAGING.md

@@ -1,191 +0,0 @@
-# UI.Visualization — Foundation Packaging Rules
-
-> **Why this exists.** This packaging model replaces reconstruction with a
-> **byte-for-byte bundle of the real, verified Next.js template**.
->
-> You author the UI foundation **once** (a Next.js app that actually builds and runs),
-> pack it into a single text file, and the scaffolder **unpacks + renames** it.
-> No regeneration, no drift — the same guarantee that `VerticalSlice` provides for the backend.
-
----
-
-## The single artifact
-
-```
-docs/UI.Visualization/
-├── UI.Visualization.pack.txt      ← THE BUNDLE: every source file in one text file
-├── PACKAGING.md                             ← this file
-├── pack-foundation.ps1                      ← produces the pack from the template folder (Windows)
-├── pack-foundation.sh                       ← produces the pack from the template folder (macOS/Linux)
-├── pack-reference-foundation.ps1            ← produces a reference/sample pack
-├── pack-reference-foundation.sh
-├── unpack-foundation.ps1                    ← extracts + renames into a target app (used by skill)
-├── unpack-foundation.sh
-├── unpack-reference-foundation.ps1
-└── unpack-reference-foundation.sh
-```
-
-The source template lives at:
-
-```
-templates/UI.Visualization/
-```
-
----
-
-## The sentinel convention
-
-The template is authored under the sentinel app name:
-
-```
-UI.Visualization
-```
-
-The scaffolder rewrites the sentinel in **four case forms** (ordinal, case-sensitive, longest-first),
-applied to **file contents and to file/folder paths**:
-
-| Form         | Sentinel                       | Example target (`PharmaViz`)    | Where it appears                          |
-|--------------|--------------------------------|---------------------------------|-------------------------------------------|
-| dotted       | `UI.Visualization`   | `PharmaViz`                     | `package.json` name (dotted form), README |
-| underscored  | `UI_Visualization`   | `PharmaViz`                     | any underscored identifiers               |
-| lower-hyphen | `ui-visualization`   | `pharmaviz`                     | npm package name, Docker image tag        |
-| lower-dot    | `ui.visualization`   | `pharmaviz`                     | any lowercased identifiers                |
-
-### What does NOT get renamed
-
-- `AppWeaver.*` framework package references in `package.json` (there are none in this UI template — all deps are third-party).
-- The generic sample pages (`/heatmap`, `/bubble`, etc.) — these are example content the caller replaces with their own pages.
-
----
-
-## How to author the template (do this once per change)
-
-1. Work in `templates/UI.Visualization/`.
-
-2. Use `UI.Visualization` as the sentinel wherever the app name belongs:
-   - `package.json` → `"name": "ui-visualization"` (lower-hyphen form)
-   - `README.md` → title
-   - `src/app/layout.tsx` → `<title>UI.Visualization</title>` and metadata
-   - Any other branding strings
-
-3. Verify the template builds and runs clean:
-   ```bash
-   cd templates/UI.Visualization
-   npm install
-   npm run build    # must exit 0, no TypeScript errors
-   npm run dev      # browse to http://localhost:3000, all 10 chart pages render
-   ```
-
-4. Fix every error here, in the real template, where the compiler tells you exactly what's wrong.
-
----
-
-## How to build the bundle
-
-From `docs/UI.Visualization/`:
-
-**macOS / Linux:**
-```bash
-./pack-foundation.sh \
-    --source-dir ../../../../templates/UI.Visualization \
-    --out-file   ./UI.Visualization.pack.txt
-```
-
-**Windows (PowerShell):**
-```powershell
-./pack-foundation.ps1 `
-    -SourceDir ../../../../templates/UI.Visualization `
-    -OutFile   ./UI.Visualization.pack.txt
-```
-
-The packer:
-- Walks the template, **excluding** build/IDE and JS output artifacts:
-  - dirs: `node_modules .next .turbo dist out coverage .cache bin obj .vs .git logs`
-  - files: `*.tsbuildinfo  next-env.d.ts  *.log  .env.*  *.pem  *.key  secrets.json`
-- **Fails closed on detected secrets** — scans file contents for credential markers and refuses to pack unless `--allow-secrets` / `-AllowSecrets` is passed.
-- Stores text files **verbatim** and binary files (e.g. `.xlsx`) **base64-encoded**.
-- Writes a header containing `foundation`, `sentinel`, file count, format version, and the replacement contract.
-- **Warns** if the sentinel token appears in zero files.
-
-Re-run it whenever the template changes; commit the regenerated `UI.Visualization.pack.txt`.
-
----
-
-## How to build the reference pack
-
-The reference pack is used by `/aw-spec-addcomponent` and `/aw-spec-implement` unpack workflows
-when a feature reference example exists under `templates/features/`.
-
-```bash
-./pack-reference-foundation.sh \
-    --source-dir ../../../../templates/features/UIVisualization.SimpleSample \
-    --out-file   ./UI.Visualization.Reference.pack.txt
-```
-
-*(Create the `SimpleSample` folder when you have a working feature example to bundle.)*
-
----
-
-## Pack file format (`aw-spec-pack/v1`)
-
-Same format as `VerticalSlice.pack.txt`:
-
-```
-# AW-SPEC FOUNDATION PACK
-# foundation: UI.Visualization
-# sentinel: UI.Visualization
-# generated: 2026-06-26T10:00:00.0000000Z
-# files: 32
-# format: aw-spec-pack/v1
-# --- replacement contract ... ---
-# ============================================================
-
-<<<FILE path="package.json">>>
-...verbatim file content...
-<<<ENDFILE>>>
-<<<FILE path="src/app/layout.tsx">>>
-...
-<<<ENDFILE>>>
-<<<FILE path="public/sample-data.xlsx" encoding="base64">>>
-AAABAAE...
-<<<ENDFILE>>>
-```
-
----
-
-## How scaffolding consumes the bundle
-
-`/aw-spec-foundation UI.Visualization <AppName> [OutputDir]`
-runs `unpack-foundation.sh` (or `.ps1`), which reads the sentinel from the pack header,
-derives the four target case forms, and writes the renamed files to the output directory.
-
-```bash
-# macOS / Linux
-./unpack-foundation.sh \
-    --pack-file   ./UI.Visualization.pack.txt \
-    --target-app-name PharmaViz \
-    --out-dir     ~/projects/
-
-# Windows
-./unpack-foundation.ps1 `
-    -PackFile        ./UI.Visualization.pack.txt `
-    -TargetAppName   PharmaViz `
-    -OutDir          ~/projects/
-```
-
-After unpacking:
-```bash
-cd ~/projects/PharmaViz     # or wherever OutDir puts it
-npm install
-npm run dev                  # → http://localhost:3000
-```
-
----
-
-## Maintenance checklist
-
-- [ ] Template builds clean (`npm run build`, no TypeScript errors).
-- [ ] Sentinel `UI.Visualization` appears in `package.json`, `README.md`, `layout.tsx`.
-- [ ] No `node_modules/`, `.next/`, or generated files committed into the pack.
-- [ ] `pack-foundation.sh` reported a non-zero sentinel hit count.
-- [ ] `UI.Visualization.pack.txt` regenerated and committed after any change.