spec-gen-cli 1.2.6 → 1.2.8

package/examples/gsd/README.md

@@ -0,0 +1,119 @@
+# spec-gen commands for get-shit-done (GSD)
+
+Two Claude Code slash commands that add structural risk analysis and spec drift
+verification to the [get-shit-done](https://github.com/gsd-build/get-shit-done) workflow.
+
+Part of the [spec-gen agentic workflow pattern](../../docs/agentic-workflows/README.md).
+
+## Commands
+
+| Command | When | What it does |
+|---|---|---|
+| `/gsd:spec-gen-orient` | Before `/gsd:execute-phase` | orient + risk gate → writes `.planning/codebase/RISK-CONTEXT.md` |
+| `/gsd:spec-gen-drift` | After `/gsd:verify-work` passes | drift check → appends spec status to `RISK-CONTEXT.md` |
+
+## Installation
+
+Copy the `commands/` directory into your project's `.claude/` folder:
+
+```bash
+cp -r examples/gsd/commands/.claude/commands/gsd/ .claude/commands/gsd/
+```
+
+Or copy into your global Claude Code commands:
+
+```bash
+cp -r examples/gsd/commands/gsd/ ~/.claude/commands/gsd/
+```
+
+## Prerequisites
+
+1. spec-gen MCP server configured in `.claude/settings.json`
+2. `spec-gen analyze $PROJECT_ROOT` run at least once
+
+## Workflow
+
+```mermaid
+flowchart TD
+    MAP["/gsd:map-codebase\nnarrative docs\n(STACK, ARCHITECTURE…)"] --> ORIENT
+
+    subgraph SG_PRE ["spec-gen — pre-phase (brownfield)"]
+        ORIENT["/gsd:spec-gen-orient\norient + analyze_impact"]
+        ORIENT --> GATE{risk ≥ 70?}
+        GATE -- yes --> INSERT["🔴 /gsd:insert-phase\nadd refactor phase"]
+        GATE -- no --> RISK_CTX[".planning/codebase/\nRISK-CONTEXT.md"]
+    end
+
+    INSERT --> ORIENT
+    RISK_CTX --> PLAN["/gsd:plan-phase N"]
+    PLAN --> EXEC["/gsd:execute-phase N"]
+    EXEC --> VERIFY["/gsd:verify-work N"]
+    VERIFY --> TESTS{tests pass?}
+    TESTS -- no --> GAP["/gsd:execute-phase --gaps-only"]
+    GAP --> VERIFY
+    TESTS -- yes --> DRIFT
+
+    subgraph SG_POST ["spec-gen — post-phase"]
+        DRIFT["/gsd:spec-gen-drift N\ncheck_spec_drift"]
+        DRIFT --> RESULT{drift?}
+        RESULT -- stale --> FIX["fix ref now"]
+        RESULT -- gap --> NOTE["note → post-milestone\nspec-gen generate"]
+        RESULT -- none --> CLEAN["✅ clean"]
+    end
+
+    CLEAN --> COMPLETE["/gsd:complete-milestone"]
+    NOTE --> COMPLETE
+    FIX --> COMPLETE
+
+    style INSERT fill:#fdd,stroke:#c00
+    style TESTS fill:#fff3cd,stroke:#ffc107
+    style CLEAN fill:#d4edda,stroke:#28a745
+```
+
+```
+/gsd:new-project or /gsd:map-codebase   ← existing GSD commands
+
+# spec-gen pre-flight (brownfield)
+/gsd:spec-gen-orient [phase]            ← risk gate, writes RISK-CONTEXT.md
+
+/gsd:plan-phase [N]                     ← existing GSD command
+/gsd:execute-phase [N]                  ← existing GSD command
+/gsd:verify-work [N]                    ← existing GSD command
+
+# spec-gen post-flight (once verify-work passes)
+/gsd:spec-gen-drift [N]                 ← drift check, appends to RISK-CONTEXT.md
+
+/gsd:complete-milestone                 ← existing GSD command
+```
+
+## Risk gate
+
+| Score | Level | Action |
+|---|---|---|
+| < 40 | 🟢 low | Proceed to execute-phase |
+| 40–69 | 🟡 medium | Proceed — protect callers listed in RISK-CONTEXT.md |
+| ≥ 70 | 🔴 high / critical | Stop — use `/gsd:insert-phase` to add a refactor phase first |
+
+## OpenSpec spec baseline
+
+`/gsd:spec-gen-orient` uses `search_specs` to surface relevant requirements, and
+`/gsd:spec-gen-drift` uses `check_spec_drift` to verify alignment. Both require
+OpenSpec specs to exist — without them, results are empty or everything shows as uncovered.
+
+| State | What to do |
+|---|---|
+| No specs yet | Run `spec-gen generate $PROJECT_ROOT` before the first phase — or let `/gsd:spec-gen-drift` offer to do it |
+| Specs exist | Both commands work as expected |
+| New code not yet spec'd | `drift` flags it as `uncovered` — run `spec-gen generate` post-milestone |
+
+Both commands detect missing specs automatically and prompt you to generate them.
+
+## Relation to `/gsd:map-codebase`
+
+`/gsd:map-codebase` uses parallel mapper agents to produce narrative documents
+(STACK.md, ARCHITECTURE.md, etc.) — great for onboarding and big-picture understanding.
+
+`/gsd:spec-gen-orient` is complementary: it produces **quantitative risk data** (fan-in,
+fan-out, risk scores, call paths) from a pre-built static index. Both can coexist —
+run `map-codebase` once for narrative context, `spec-gen-orient` before each phase for
+risk-aware execution.

package/examples/gsd/commands/gsd/spec-gen-drift.md

@@ -0,0 +1,111 @@
+---
+name: gsd:spec-gen-drift
+description: Post-phase spec drift check via spec-gen MCP — verify implementation matches OpenSpec specifications. Run after verify-work and green tests.
+argument-hint: "[phase number]"
+allowed-tools:
+  - mcp__spec-gen__check_spec_drift
+  - mcp__spec-gen__get_spec
+  - Read
+  - Write
+---
+
+<objective>
+Verify that the completed phase implementation is consistent with existing OpenSpec specifications.
+Report gaps, stale references, and uncovered files.
+
+Run this after `/gsd:verify-work` confirms the phase is working, not before.
+</objective>
+
+<when_to_use>
+Run this command:
+- After `/gsd:verify-work` passes (or gaps are resolved)
+- Before `/gsd:complete-milestone` as a final quality check
+- Any time you want to confirm implementation stays aligned with specs
+
+Skip this command:
+- Before verify-work passes (drift check on broken code is not useful)
+
+**If no specs exist yet**: do not skip — use this command to trigger `spec-gen generate`
+and create the baseline. See Step 1.
+</when_to_use>
+
+<prerequisites>
+1. spec-gen MCP server configured in Claude Code settings
+2. Tests passing — confirm with user before proceeding
+3. `spec-gen analyze` cache exists
+</prerequisites>
+
+<process>
+
+<step name="check_spec_baseline">
+Check whether OpenSpec specs exist:
+
+```bash
+ls $PROJECT_ROOT/openspec/specs/ 2>/dev/null | wc -l
+```
+
+**If 0 specs found:**
+> "No OpenSpec specs exist yet. Running drift check now will flag all files as uncovered,
+> which is not actionable.
+>
+> Run `spec-gen generate $PROJECT_ROOT` to create a baseline from the current codebase.
+> This takes a few minutes and only needs to be done once."
+
+Ask: "Run `spec-gen generate` now? (yes/no)"
+- Yes → run `spec-gen generate $PROJECT_ROOT`, then proceed
+- No → stop, remind user to run before next drift check
+
+**If specs exist**: proceed.
+</step>
+
+<step name="confirm_tests">
+Ask the user: "Are tests passing for this phase?"
+
+If no: "Fix test failures first. Drift check on a red test suite is not actionable."
+Stop here.
+</step>
+
+<step name="run_drift">
+```
+spec-gen check_spec_drift
+  directory: $PROJECT_ROOT
+```
+</step>
+
+<step name="interpret">
+Classify each finding:
+
+| Type | Meaning | Recommended action |
+|---|---|---|
+| `uncovered` on new files | New code not yet in any spec | Batch for post-milestone spec update |
+| `gap` on existing domain | Spec missing new behaviour | Run `spec-gen generate --domains $DOMAIN` now or post-milestone |
+| `stale` | Spec references deleted/renamed function | Fix reference in spec file |
+| No drift | ✅ Clean | Done |
+</step>
+
+<step name="output">
+If drift found:
+
+> Spec drift detected in {N} domain(s). These do not block shipping but should be addressed.
+>
+> **Now (blocking):** Fix any `stale` references — they indicate broken spec links.
+> **Post-milestone (recommended):** Run `spec-gen generate` to refresh specs for domains with gaps or uncovered files.
+
+Append a `## Spec Drift` section to `.planning/codebase/RISK-CONTEXT.md` (or create it if absent):
+
+```markdown
+## Spec Drift — Phase {N}
+
+> Checked on {date} after verify-work passed.
+
+| Domain | Type | Action |
+|--------|------|--------|
+{rows}
+```
+
+If no drift:
+
+> ✅ No spec drift. Phase implementation is consistent with existing OpenSpec specifications.
+</step>
+
+</process>

package/examples/gsd/commands/gsd/spec-gen-orient.md

@@ -0,0 +1,191 @@
+---
+name: gsd:spec-gen-orient
+description: Pre-phase structural risk check via spec-gen MCP — orient + analyze_impact before execute-phase. Writes .planning/codebase/RISK-CONTEXT.md.
+argument-hint: "[phase number or task description]"
+allowed-tools:
+  - mcp__spec-gen__orient
+  - mcp__spec-gen__analyze_impact
+  - mcp__spec-gen__search_specs
+  - mcp__spec-gen__analyze_codebase
+  - Read
+  - Write
+  - Glob
+---
+
+<objective>
+Run spec-gen structural analysis before executing a phase. Identify high-risk functions,
+surface relevant spec requirements, and gate on riskScore ≥ 70 before any code is written.
+
+Output: `.planning/codebase/RISK-CONTEXT.md` with structural risk summary for the phase.
+</objective>
+
+<when_to_use>
+Run this command:
+- Before `/gsd:execute-phase` on a brownfield codebase
+- After `/gsd:plan-phase` when the plan touches existing code
+- Any time you suspect a planned change touches a high-fan-in function
+
+Skip this command:
+- Greenfield projects with no existing codebase (nothing to analyse)
+- Trivial changes (config edits, documentation only)
+</when_to_use>
+
+<prerequisites>
+1. spec-gen MCP server configured in Claude Code settings
+2. `spec-gen analyze` run at least once on this project
+   If not: this command will detect the missing cache and offer to run it.
+</prerequisites>
+
+<process>
+
+<step name="load_context">
+Load current project state:
+
+```bash
+cat .planning/STATE.md 2>/dev/null || echo "No STATE.md found"
+```
+
+Determine the active phase and extract the implementation intent from:
+- `.planning/phases/PHASE-{N}-PLAN.md` if a phase number was provided or is active
+- `$ARGUMENTS` if a task description was provided directly
+
+If neither exists, ask the user: "What are you about to implement?"
+Use the answer as `$TASK_DESCRIPTION`.
+</step>
+
+<step name="check_cache">
+Run orient to verify cache exists:
+
+```
+spec-gen orient
+  directory: $PROJECT_ROOT
+  task: $TASK_DESCRIPTION
+  limit: 7
+```
+
+If orient returns `"error": "no cache"`:
+> spec-gen has no analysis cache for this project.
+> Run `spec-gen analyze $PROJECT_ROOT` first (takes ~1 min for most projects).
+> Then re-run `/gsd:spec-gen-orient`.
+
+Offer to run analysis now:
+```
+spec-gen analyze_codebase
+  directory: $PROJECT_ROOT
+```
+Wait for completion, then proceed.
+</step>
+
+<step name="check_spec_baseline">
+Check whether OpenSpec specifications exist:
+
+```bash
+ls $PROJECT_ROOT/openspec/specs/ 2>/dev/null | head -5
+```
+
+**If no specs exist** (`openspec/specs/` absent or empty):
+> "No OpenSpec specs found for this project. `search_specs` will return empty results
+> and `check_spec_drift` will flag all files as uncovered.
+>
+> Recommended: run `spec-gen generate $PROJECT_ROOT` after this phase to create a spec
+> baseline. You only need to do this once — future phases will benefit from spec alignment.
+>
+> Continuing with structural analysis only (orient + impact)."
+
+Skip the search_specs step below and go straight to impact_analysis.
+
+**If specs exist**: proceed to search_specs.
+</step>
+
+<step name="search_specs">
+Surface existing requirements that apply to this change:
+
+```
+spec-gen search_specs
+  directory: $PROJECT_ROOT
+  query: $TASK_DESCRIPTION
+  limit: 5
+```
+
+List any relevant requirements found. Note constraints that apply to the planned implementation.
+If search returns no results despite specs existing, note it in RISK-CONTEXT.md under
+"Relevant Spec Requirements: none matched — area may not be spec'd yet".
+</step>
+
+<step name="impact_analysis">
+For the top 2 functions returned by orient, run impact analysis:
+
+```
+spec-gen analyze_impact
+  directory: $PROJECT_ROOT
+  symbol: $FUNCTION_NAME
+  depth: 2
+```
+
+Build a risk table:
+
+| Function | File | Risk Score | Level | Callers |
+|----------|------|-----------|-------|---------|
+</step>
+
+<step name="gate">
+Apply the risk gate:
+
+| Max risk score | Decision |
+|---|---|
+| < 40 | 🟢 Proceed — show insertion points, write RISK-CONTEXT.md |
+| 40–69 | 🟡 Proceed with caution — list callers to protect in RISK-CONTEXT.md |
+| ≥ 70 | 🔴 **Stop.** Do not execute phase until the blocking function is refactored. |
+
+**If riskScore ≥ 70 on any function:**
+
+> ⚠️ High structural risk on `$FUNCTION_NAME` (score: $SCORE, $CALLER_COUNT callers).
+>
+> Recommended: add a refactor plan to the current phase or insert a new phase before this one.
+> Use `/gsd:insert-phase` to add a refactor phase, then re-run `/gsd:spec-gen-orient`.
+
+Stop and wait for user decision. Do not proceed to execute-phase.
+</step>
+
+<step name="write_output">
+Write `.planning/codebase/RISK-CONTEXT.md`:
+
+```markdown
+# Risk Context — Phase {N}
+
+> Generated by spec-gen on {date}. Re-run `/gsd:spec-gen-orient` after structural changes.
+
+## Summary
+
+- **Phase intent**: {task_description}
+- **Domains**: {domains}
+- **Max risk score**: {score} {badge}
+- **Decision**: {🟢 proceed | 🟡 proceed with caution | 🔴 blocked}
+
+## Functions in Scope
+
+| Function | File | Risk | Hub |
+|----------|------|------|-----|
+{rows}
+
+## Callers to Protect
+
+{list of callers from impact analysis, or "none"}
+
+## Blocking Refactors
+
+{list of functions with risk ≥ 70, or "none"}
+
+## Relevant Spec Requirements
+
+{list from search_specs, or "none found — run spec-gen generate to create specs"}
+
+## Insertion Points
+
+{top insertion point from orient}
+```
+
+Confirm: "Risk context written to `.planning/codebase/RISK-CONTEXT.md`. Safe to run `/gsd:execute-phase`."
+</step>
+
+</process>

package/examples/mistral-vibe/README.md

@@ -0,0 +1,101 @@
+# Mistral Vibe assets for spec-gen
+
+Mistral Vibe implementation of the [spec-gen agentic workflow pattern](../../docs/agentic-workflows/README.md).
+
+## Contents
+
+| Path | Purpose |
+|---|---|
+| `skills/spec-gen-analyze-codebase/` | Full static analysis — architecture, call graph, refactor issues, duplicates |
+| `skills/spec-gen-generate/` | Generate OpenSpec specs from analysis results |
+| `skills/spec-gen-brainstorm/` | Design a feature: greenfield (Domain Sketch) or brownfield (Constrained Option Tree) → annotated story |
+| `skills/spec-gen-plan-refactor/` | Identify highest-priority refactor target and write a plan |
+| `skills/spec-gen-execute-refactor/` | Apply a refactor plan produced by spec-gen-plan-refactor |
+| `skills/spec-gen-implement-story/` | Implement a story with structural pre-flight check, test gate, and drift verification |
+| `skills/spec-gen-debug/` | Debug a bug: hypothesis-first, RED/GREEN test verification, spec invariant feedback loop |
+| `antipatterns-template.md` | Starter template for `.claude/antipatterns.md` — copy to your project root |
+
+## Workflow
+
+```mermaid
+flowchart TD
+    subgraph ANALYSIS ["📊 Analysis (one-time)"]
+        A["/spec-gen-analyze-codebase"] --> B["/spec-gen-generate"]
+    end
+
+    subgraph REFACTOR ["🔧 Refactor cycle (optional)"]
+        C["/spec-gen-plan-refactor\n→ .spec-gen/refactor-plan.md"] --> D["/spec-gen-execute-refactor\nchange by change, test gate"]
+    end
+
+    subgraph DESIGN ["💡 Design"]
+        K["/spec-gen-brainstorm\ngreenfield or brownfield"] --> L["Won't Do + testable ACs\nadversarial challenge"]
+        L --> M["annotate_story\n→ story.md with risk_context"]
+    end
+
+    subgraph FEATURE ["⚙️ Feature / Story"]
+        E["/spec-gen-implement-story"] --> F["orient + analyze_impact\nrisk gate ≥ 70 → blocks"]
+        F --> F2["adversarial self-check\n+ antipatterns"]
+        F2 --> G["search_specs\nread requirements"]
+        G --> H["implement"]
+        H --> I["tests green ✅"]
+        I --> J["check_spec_drift"]
+    end
+
+    subgraph DEBUG ["🐛 Debug"]
+        N["/spec-gen-debug\nhypothesis-first"] --> O["RED/GREEN\ntest verification"]
+        O --> P["spec invariant\nfeedback loop"]
+    end
+
+    B --> C
+    B --> K
+    M --> E
+    D --> E
+
+    style F fill:#fff3cd,stroke:#ffc107
+    style I fill:#d4edda,stroke:#28a745
+```
+
+## Usage
+
+Copy the skills into your Mistral Vibe project skills directory and invoke them with their slash commands:
+
+```
+/spec-gen-analyze-codebase
+/spec-gen-generate
+/spec-gen-brainstorm
+/spec-gen-plan-refactor
+/spec-gen-execute-refactor
+/spec-gen-implement-story
+/spec-gen-debug
+```
+
+Each skill follows the generic pre-flight pattern:
+- `orient` + `analyze_impact` before any code change
+- adversarial self-check + antipatterns read before first edit
+- test gate before `check_spec_drift`
+- `check_spec_drift` after tests are green
+
+## Antipatterns
+
+Copy `antipatterns-template.md` to `.claude/antipatterns.md` in your project:
+
+```bash
+cp examples/mistral-vibe/antipatterns-template.md .claude/antipatterns.md
+```
+
+The antipatterns list is read by `spec-gen-brainstorm` (Step 1) and `spec-gen-implement-story` (Step 4b),
+and written by `spec-gen-debug` (Step 9d) when a bug reveals a cross-cutting failure pattern.
+
+## OpenSpec spec baseline
+
+`search_specs` and `check_spec_drift` require specs to exist. Run `/spec-gen-generate`
+once before using `/spec-gen-implement-story` for the first time — this creates the
+baseline that makes spec alignment meaningful.
+
+| State | What to do |
+|---|---|
+| No specs yet | `/spec-gen-analyze-codebase` then `/spec-gen-generate` |
+| Specs exist | All skills work as expected |
+| Post-sprint spec refresh | `/spec-gen-generate` again to update specs after new code |
+
+`/spec-gen-implement-story` detects missing specs automatically and tells you what to do.

package/examples/mistral-vibe/antipatterns-template.md

@@ -0,0 +1,18 @@
+# Project Antipatterns
+
+Failure patterns discovered post-merge. Automatically checked by agents during
+brainstorm and implementation via `spec-gen-brainstorm` and `spec-gen-implement-story`.
+
+To add an entry: run `/spec-gen-debug` — Step 9 evaluates whether the bug
+qualifies as a cross-cutting antipattern and appends here if so.
+
+---
+
+<!-- Add entries below. Use AP-NNN numbering. -->
+
+## AP-001 — {pattern name}
+
+- **Class**: {state | concurrency | boundary | assumption | resource | ordering}
+- **Symptom**: {what broke in production — one sentence}
+- **Rule**: {detection rule agents should check — "When X, always verify Y"}
+- **Discovered**: {YYYY-MM-DD} via {one-line bug summary}

package/examples/mistral-vibe/skills/spec-gen-analyze-codebase/SKILL.md

@@ -0,0 +1,123 @@
+---
+name: spec-gen-analyze-codebase
+description: Run a full static analysis of a project using spec-gen and summarise the results — architecture, call graph, top refactoring issues, and duplicate code. No LLM required.
+license: MIT
+compatibility: spec-gen MCP server
+user-invocable: true
+allowed-tools:
+  - ask_followup_question
+  - use_mcp_tool
+  - spec-gen-plan-refactor
+---
+
+# spec-gen: Analyze Codebase
+
+## When to use this skill
+
+Trigger this skill whenever the user asks to **analyze a codebase** with spec-gen, with phrasings like:
+- "analyze my project / my code"
+- "give me a code quality report"
+- "what are the structural issues in my codebase"
+- "find duplicates in my code"
+- explicit command `/spec-gen-analyze-codebase`
+
+This skill is **read-only** — it modifies no files. It produces a report and suggests next steps.
+
+---
+
+## Step 1 — Confirm the project directory
+
+Ask the user which project to analyze, or confirm the current workspace root.
+
+```
+Which project directory should I analyze?
+Options: current workspace root | enter a different path
+```
+
+---
+
+## Step 2 — Run static analysis
+
+```xml
+<use_mcp_tool>
+  <server_name>spec-gen</server_name>
+  <tool_name>analyze_codebase</tool_name>
+  <arguments>{"directory": "$DIRECTORY"}</arguments>
+</use_mcp_tool>
+```
+
+---
+
+## Step 3 — Summarize the results
+
+Present a concise summary:
+- Project type and detected frameworks
+- File count, function count, internal call count
+- Top 5 refactoring issues (function name, file, issue type, priority score)
+- Detected domains
+
+Also report stack inventory (read directly from `.spec-gen/analysis/` — no extra MCP call needed):
+- **HTTP routes**: N routes across M files — if `route-inventory.json` exists
+- **ORM tables**: N tables — if `schema-inventory.json` exists
+- **Env vars**: N total, X required without default — if `env-inventory.json` exists
+- **UI components**: N components — if `ui-inventory.json` exists
+
+If none of these files exist, skip this section and suggest running `spec-gen analyze --force`.
+
+---
+
+## Step 4 — Show the call graph
+
+```xml
+<use_mcp_tool>
+  <server_name>spec-gen</server_name>
+  <tool_name>get_call_graph</tool_name>
+  <arguments>{"directory": "$DIRECTORY"}</arguments>
+</use_mcp_tool>
+```
+
+Highlight:
+- **Hub functions** (fanIn ≥ 8) — over-solicited functions, high coupling risk
+- **Layer violations** detected (e.g. a UI layer calling the database directly)
+
+---
+
+## Step 5 — Show duplicate code report
+
+```xml
+<use_mcp_tool>
+  <server_name>spec-gen</server_name>
+  <tool_name>get_duplicate_report</tool_name>
+  <arguments>{"directory": "$DIRECTORY"}</arguments>
+</use_mcp_tool>
+```
+
+Present a concise summary:
+- Overall duplication ratio (e.g. "12% of functions are duplicated")
+- Top 3 clone groups sorted by impact (instances × line count):
+  - Clone type (exact / structural / near) and similarity score
+  - List of instances (file + function name + line range)
+- If no duplicates found, note this as a positive signal
+
+---
+
+## Step 6 — Suggest next steps
+
+Based on the analysis, guide the user through the natural next actions in order:
+
+1. Call `get_signatures` on the modules containing the top issues to understand their public API
+2. Call `get_subgraph` on the highest-priority function to map its callers and callees
+3. If significant duplication was found, suggest consolidating clone groups **before** refactoring
+4. Suggest running `/spec-gen-plan-refactor` once the user has enough context to act, then `/spec-gen-execute-refactor` to apply the plan
+5. If the project has OpenSpec specs, call `list_spec_domains` then `search_specs` to enable
+   spec-first reasoning (question → requirements → linked source files). To activate `search_specs`,
+   run `spec-gen analyze --embed` or `spec-gen analyze --reindex-specs`.
+
+---
+
+## Absolute constraints
+
+- **No code modifications** in this workflow
+- Never skip the duplication step — it determines the order of subsequent actions
+- Always present call graph and duplicate report results even if numbers are low
+- Next steps (Step 6) are suggestions, not automatic actions