acstack 0.53.1 → 0.54.1

package/skills/sync/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: sync
-description: Update living specs in .acstack/specs/ from recent code changes. Called automatically by /commit for retroactive spec updates. Can also be invoked manually.
+description: Update living specs in the project folder's specs/ from recent code changes. Called automatically by /commit for retroactive spec updates. Can also be invoked manually.
 argument-hint: "[file-paths or 'staged']"
 ---
 
@@ -15,7 +15,8 @@ You **MUST** consider the user input before proceeding (if not empty).
 ## Purpose
 
 This skill analyzes code changes. It updates the cumulative living specs in
-`.acstack/specs/` to reflect what changed. It is the "fast path" mechanism
+`<project folder>/specs/` to reflect what changed. The project folder is the
+path `~/.claude/acstack/bin/acstack project-data path` prints. It is the "fast path" mechanism
 that keeps specs current even when a workflow skips full spec planning.
 
 ## Step 1: determine change scope
@@ -81,11 +82,11 @@ domain.
 5. Stage what `document` wrote
 
     `document` writes `DESIGN.md` and `.impeccable/design.json`. Stage both
-    with the commit; stage updated specs only when the user opted into tracking them.
+    with the commit. Specs follow the staging rule in Integration with /commit.
 
 ## Step 3: map changes to domains
 
-1. Read `.acstack/domain-map.yaml`
+1. Read `<project folder>/domain-map.yaml`
 2. Match changed files against domain path patterns
 3. Group changes by domain
 4. Skip files outside all domains (tests, config, docs)
@@ -96,7 +97,7 @@ If the diff affects no domains, report "No spec-relevant changes". Then exit.
 
 For each affected domain:
 
-1. Read `.acstack/specs/[domain]/spec.md` (if it exists)
+1. Read `<project folder>/specs/[domain]/spec.md` (if it exists)
 2. Analyze changes:
     - New functions/endpoints/components -> ADDED requirements
     - Modified signatures or behavior -> MODIFIED requirements
@@ -109,9 +110,9 @@ Write each functional requirement (FR) entry per the `writing` skill.
 ```markdown
 ### FR-014: The handoff anchor loads once
 
-- **Description**: The SessionStart hook injects `.acstack/HANDOFF.md` after a
-  compaction, then moves the file into `.acstack/handoffs/`.
-- **Behavior**: Given `.acstack/HANDOFF.md` carries the `acstack_handoff`
+- **Description**: The SessionStart hook injects `<project folder>/HANDOFF.md` after a
+  compaction, then moves the file into `<project folder>/handoffs/`.
+- **Behavior**: Given `<project folder>/HANDOFF.md` carries the `acstack_handoff`
   marker, When a session starts with source `compact`, Then the hook injects
   the file and retires it.
 - **Source**: `hooks/session-start-handoff.sh`
@@ -129,8 +130,8 @@ Write each merged FR per the `writing` skill.
 
 ## Step 6: glossary check
 
-Glossaries live in `.acstack/CONTEXT.md` (cross-domain terms) and
-`.acstack/specs/[domain]/CONTEXT.md` (domain terms). If neither exists, skip.
+Glossaries live in `<project folder>/CONTEXT.md` (cross-domain terms) and
+`<project folder>/specs/[domain]/CONTEXT.md` (domain terms). If neither exists, skip.
 
 For each glossary term, check the diff. Look for a renamed or deleted
 identifier that matches it: function, class, table, config key, route. If
@@ -162,8 +163,9 @@ When `/commit` calls this skill:
 
 1. Receives the staged diff as context
 2. Runs silently (no user prompts)
-3. Returns modified specs for staging only when native `.gitignore` rules allow tracking
-    - Keep ignored specs updated locally; never force-add them or change the Git index to bypass the user's choice
+3. Returns modified specs for staging only when they sit inside the current working tree
+    - That happens only in tracked mode, when you commit in the main checkout
+    - Otherwise the specs stay updated in the project folder and out of the commit
 4. Adds `DESIGN.md` and `.impeccable/design.json` when Step 2 refreshed them
 5. Outputs minimal detail so it does not interrupt the commit flow
 

package/skills/terminal-workspace/SKILL.md

@@ -27,7 +27,7 @@ ACStack does not need any of this. Offer it, do not assume it.
 ```mermaid
 flowchart TD
     IN["Twelve components, one YAML file<br/>(machine-level, not per-project)"] --> ST["See what this machine has<br/>(setup.sh status)"]
-    ST --> CF["Copy the config, walk the choices<br/>(~/.config/acstack/terminal-workspace.yaml)"]
+    ST --> CF["Copy the config, walk the choices<br/>(~/.acstack/terminal-workspace.yaml)"]
     CF --> AP["Install binaries, write the keys<br/>(setup.sh apply)"]
     AP --> Q{"How does the user reach<br/>this machine?"}
     Q -->|"an SSH shell"| KB["Free the keys the emulator swallows<br/>(client-keybindings.md)"]
@@ -58,7 +58,7 @@ flowchart TD
 
 This is **machine-level, not per-project**. It installs binaries and writes
 keybindings for the user account, so it does not belong in
-`.acstack/project.yaml`.
+the project folder's `project.yaml`.
 
 Count components when you mean config keys, and tools when you mean binaries.
 The config holds twelve component sections, plus an `enabled` master switch
@@ -76,7 +76,7 @@ Read [`components.md`](components.md) when the user asks what a component does,
 
 The two files this skill works with:
 
-- **Config**: `~/.config/acstack/terminal-workspace.yaml`, copied from `assets/terminal-workspace/config.example.yaml`
+- **Config**: `~/.acstack/terminal-workspace.yaml`, copied from `assets/terminal-workspace/config.example.yaml`
 - **Script**: `assets/terminal-workspace/setup.sh` in this plugin
 
 Yazi's `i` opens Markdown in Frogmouth (`pipx install frogmouth`); existing `i` bindings take precedence, and `e` keeps editing in `$EDITOR`.
@@ -125,7 +125,7 @@ Its last lines say where a copy and an open will land on this machine. Section
 Copy the example config before the first `apply`:
 
 ```bash
-cp "$(dirname "$SETUP")/config.example.yaml" ~/.config/acstack/terminal-workspace.yaml
+mkdir -p ~/.acstack && cp "$(dirname "$SETUP")/config.example.yaml" ~/.acstack/terminal-workspace.yaml
 ```
 
 Then read [`config-choices.md`](config-choices.md) and ask about the settings it lists, in its order.

package/skills/terminal-workspace/headless-clipboard.md

@@ -69,7 +69,7 @@ for the opener. One can be up while the other is down.
 
 The opener has no key in this config, so do not invent one. `acstack-open` takes
 that route only when two things hold. A token file sits at
-`~/.config/acstack/opener.token`. The service answers on
+`~/.acstack/opener.token`. The service answers on
 `http://127.0.0.1:19989` with that token.
 
 Setting `ACSTACK_OPEN_OPENER=off` in the environment skips the route.

package/skills/terminal-workspace/turn-off-and-update.md

@@ -32,7 +32,7 @@ and leaves the rest of the user's neovim config alone. Neither `disable` nor
 - It removes agentic-retro's extension only when `apply` was the one to write it
 - It keeps the pi binary, its logins and its sessions
 - It touches nothing in a `settings.json` that does not parse, and says so
-- It records what it added in `~/.config/acstack/terminal-workspace.pi.json`
+- It records what it added in `~/.acstack/terminal-workspace.pi.json`
 
 `yazi`, `markdown` and `remote` have no `disable` path. `disable` refuses for
 those three and names the edit that turns one off. Set the component's

package/skills/test-conventions/SKILL.md

@@ -7,7 +7,7 @@ description: Test placement rules and framework conventions. Invoke before writi
 
 ## Decision Tree: Where Does My Test Go?
 
-Read `.acstack/project.yaml` for `directories.source`, `directories.tests`, and `frontend` config.
+Read `<project folder>/project.yaml` for `directories.source`, `directories.tests`, and `frontend` config. The project folder is the path `~/.claude/acstack/bin/acstack project-data path` prints.
 
 ```
 Backend code?             → <tests-dir>/<mirror-source-path>/test_<module>.py
@@ -25,7 +25,7 @@ Mirror the source directory structure. Example: `src/auth/sessions.py` → `test
 - Shared fixtures → `<tests-dir>/conftest.py` (Python) or shared setup files
 - Use markers for slow/integration tests (configured in `test_markers.exclude`)
 - Use the project's test runner for focused checks; the verification owner gathers full completion evidence under `orchestrator/AGENTS.md`
-- When test collection is configured, compare `.acstack/.test-baseline` if present; investigate removed coverage and honor project baseline requirements
+- When test collection is configured, compare `<project folder>/.test-baseline` if present; investigate removed coverage and honor project baseline requirements
 
 ## Layer 2: Frontend Unit Tests