@n8n-as-code/n8nac 2.0.1-next.7 → 2.1.0-next.45

package/README.md

@@ -1,14 +1,14 @@
 # @n8n-as-code/n8nac
 
-**OpenClaw access to the standard `n8n-as-code` skills and workflow stack.**
+OpenClaw access to the standard `n8n-as-code` skills and workflow stack.
 
-Use OpenClaw to build, update, validate, and manage n8n workflows with the same `n8nac` CLI and AI context model used across the wider `n8n-as-code` project.
+The plugin uses the same model as VS Code, Claude, and the CLI:
 
-## v2 migration note
-
-Version 2 removes the facade-specific OpenClaw runtime tool path. The plugin now delegates instance, auth, project, tunnel, credential, and presentation operations to `n8n-manager`, while workspace sync context is stored through `n8nac workspace` in `~/.openclaw/n8nac/`.
-
-Documentation: [OpenClaw guide](https://n8nascode.dev/docs/usage/openclaw/) · [n8n-manager guide](https://n8nascode.dev/docs/usage/n8n-manager/) · [CLI workspace commands](https://n8nascode.dev/docs/usage/cli/#workspace)
+| Group | Command | Purpose |
+|---|---|---|
+| Usage Principal | `n8nac env` | Workspace environments |
+| Maintenance Workspace | `n8nac workspace` | Readiness, unified migration, upgrade |
+| Instances Managées | `n8n-manager` | Local managed instances and tunnels |
 
 ## Install
 
@@ -16,168 +16,88 @@ Documentation: [OpenClaw guide](https://n8nascode.dev/docs/usage/openclaw/) · [
 openclaw plugins install @n8n-as-code/n8nac
 ```
 
-For prerelease testing, install the `next` dist-tag and use matching prerelease CLI commands in any manual shell steps:
+For prerelease testing:
 
 ```bash
 openclaw plugins install @n8n-as-code/n8nac@next
-npx --yes n8nac@next workspace status --json
-npx --yes @n8n-as-code/n8n-manager@next instances list
+npx --yes n8nac@next env list
+npx --yes @n8n-as-code/n8n-manager@next instance list
 ```
 
-Do not mix an OpenClaw plugin installed from `@next` with `n8nac@latest`; bundled prerelease skills may reference CLI commands that are not in the stable release yet.
-
-If you previously installed `@n8n-as-code/openclaw-plugin`, remove the old install first so OpenClaw re-registers the plugin cleanly under `n8nac`:
+If you previously installed `@n8n-as-code/openclaw-plugin`, remove the old install first:
 
 ```bash
 openclaw plugins uninstall n8nac
 openclaw plugins install @n8n-as-code/n8nac
 ```
 
-Restart the gateway. Runtime access, project selection, workspace sync, and
-workflow guidance are handled by the bundled `n8n-manager` and `n8n-architect`
-skills through their documented shell commands.
-
 ## Usage
 
-Once the runtime and workspace are configured through the skills, talk to OpenClaw:
-
-> "Create an n8n workflow that sends a Slack message when a GitHub issue is opened"
-
-> "Pull workflow 42 and add an error handler to it"
-
-> "What operations does the Google Sheets node support?"
-
-The plugin keeps its prompt hook lightweight. OpenClaw uses the bundled
-`n8n-manager` and `n8n-architect` skills for explicit n8n sessions. Those
-skills use the same shell commands as Claude, Codex, Cursor, VS Code, and other
-agents: `n8n-manager ...` and `n8nac ...`.
-
-## CLI commands
-
-| Command | Description |
-|---|---|
-| `openclaw n8nac:status` | Show workspace status |
-
-## Workspace
-
-All files live in `~/.openclaw/n8nac/`:
-
-```
-~/.openclaw/n8nac/
-  n8nac-config.json     ← workspace project/sync overrides only
-  AGENTS.md             ← lightweight agent bootstrap (written by n8nac update-ai)
-  .agents/skills/       ← portable n8n-manager + n8n-architect skills
-  workflows/            ← .workflow.ts files (your n8n workflows)
-```
-
-Instances and API keys are not stored in this workspace. They live in the global
-`n8n-manager` configuration under `~/.n8n-manager`.
-
-To pin this workspace to one global instance, run `n8n-manager instances list`, then `n8nac workspace pin-instance --instance-id <instanceId>` from `~/.openclaw/n8nac/` or through the agent skill shell.
-
-## Agent skills
-
-The plugin does not register a facade-specific agent tool. Agents should use
-the portable skills and shell commands directly:
+Run setup, then restart the gateway:
 
 ```bash
-n8n-manager instances list
-n8nac workspace status --json
-n8nac list
-n8nac pull <workflowId>
-n8nac push <path-to-workflow.workflow.ts> --verify
-n8nac skills node-info <nodeName>
+openclaw n8nac:setup
+openclaw gateway restart
 ```
 
-`AGENTS.md` is not a configuration source of truth. It points agents to the
-local skills and to `n8nac workspace status --json`, which resolves the
-effective context through the backend.
+Then ask OpenClaw for workflow work:
 
-## Local development
-
-This section covers how to load the plugin from source during development so
-that changes take effect immediately without an npm publish cycle.
-
-### 1. Link the plugin directory
-
-OpenClaw's `--link` flag registers a local path instead of installing a copy.
-jiti is used to run TypeScript directly, so no build step is needed.
-
-```bash
-openclaw plugins install --link \
-  /home/etienne/repos/n8n-as-code/plugins/openclaw/n8n-as-code
+```text
+Create an n8n workflow that sends a Slack message when a GitHub issue is opened.
 ```
 
-What this does:
-- Adds the path to `plugins.load.paths` in `~/.openclaw/openclaw.json`
-- Registers a `source: "path"` install record bound to the plugin ID `n8nac`
-- No file copy — OpenClaw loads `index.ts` directly from the source tree
+## Workspace
 
-### 2. Verify the plugin is registered
+OpenClaw files live in `~/.openclaw/n8nac/`:
 
-```bash
-openclaw plugins info n8nac
+```text
+~/.openclaw/n8nac/
+  n8nac-config.json
+  AGENTS.md
+  .agents/skills/
+  workflows/
 ```
 
-You should see status `loaded`, the bundled skills, and the `n8nac:status` CLI
-command. The plugin intentionally does not register a
-facade-specific agent tool.
+`n8nac-config.json` stores workspace environments. API keys and managed local instance state stay local.
 
-### 3. Configure runtime access through skills
+Manual equivalent:
 
 ```bash
-n8n-manager auth set --url <url> --api-key-stdin
-n8n-manager projects list
-n8n-manager projects select <project-id-or-name>
-n8nac workspace set-sync-folder workflows
+n8nac env add Dev --base-url <url> --sync-folder workflows/dev
+n8nac env auth set Dev --api-key-stdin
+n8nac env use Dev
 n8nac update-ai
 ```
 
-The OpenClaw plugin does not own setup orchestration. It exposes lightweight
-context and lets the portable skills manage global instances, secrets, projects,
-workspace overrides, `AGENTS.md`, and `.agents/skills`.
-
-### 4. Iterate on the code
-
-- Edit any `.ts` file in `plugins/openclaw/n8n-as-code/`
-- **Restart the gateway** to reload: `openclaw stop && openclaw start` (or the
-  equivalent service restart on your setup)
-- The `before_prompt_build` hook and CLI commands reload on
-  gateway start
-
-### 5. Check gateway logs
+For a managed local instance:
 
 ```bash
-tail -f ~/.openclaw/logs/openclaw-$(date +%Y-%m-%d).log | grep n8nac
+n8n-manager instance list
+n8nac env add Local --managed-instance <id> --sync-folder workflows/local
 ```
 
-The plugin prefixes all `api.logger` calls with `[n8nac]`.
+## Agent Commands
 
-### 6. Inspect the n8nac workspace
-
-```
-~/.openclaw/n8nac/
-  n8nac-config.json   ← workspace project/sync overrides only
-  AGENTS.md           ← lightweight bootstrap written by update-ai
-  .agents/skills/     ← portable skills written by update-ai
-  workflows/          ← .workflow.ts files
-```
-
-To reset and redo setup from scratch:
+Agents use the normal shell commands:
 
 ```bash
-rm -rf ~/.openclaw/n8nac
-n8nac workspace set-sync-folder workflows
-n8nac update-ai
+n8nac env status
+n8nac list
+n8nac pull <workflow-id>
+n8nac push <path-to-workflow.workflow.ts> --verify
+n8nac skills node-info <node-name>
 ```
 
-### 7. Unlink when done
+## Local Development
+
+Register this directory with OpenClaw:
 
 ```bash
-openclaw plugins uninstall n8nac
+openclaw plugins install --link /home/etienne/repos/n8n-as-code/plugins/openclaw/n8n-as-code
+openclaw plugins info n8nac
 ```
 
----
+Restart the gateway after changes.
 
 ## Source
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@n8n-as-code/n8nac",
-  "version": "2.0.1-next.7",
+  "version": "2.1.0-next.45",
   "description": "OpenClaw plugin for n8n-as-code — create and manage n8n workflows from OpenClaw",
   "keywords": [
     "n8n",

package/skills/n8n-architect/SKILL.md

@@ -5,7 +5,9 @@ description: Use when the user explicitly wants to create, edit, validate, sync,
 
 # n8n Architect
 
-Use this skill for workflow engineering. Use the `n8n-manager` skill for instance, auth, runtime, tunnel, project-default, credential infrastructure, or workflow presentation work.
+Use this skill for all n8n-as-code work: workspace readiness, migration, environments, managed local instances, tunnels, workflow authoring, validation, sync, push, and pull.
+
+Use `npx --yes n8nac` as the primary interface. Use `npx --yes @n8n-as-code/n8n-manager` only for local managed runtime lifecycle, tunnels, and workflow presentation commands that are explicitly exposed by n8n-manager.
 
 ## Context Root Protocol
 
@@ -13,42 +15,171 @@ Use this skill for workflow engineering. Use the `n8n-manager` skill for instanc
 - Generated context root hint: not embedded. Use the shell launch directory or the workspace path explicitly given by the user.
 - Before any n8n work, first run `npx --yes n8nac update-ai` from the context root, then read `AGENTS.md`. `update-ai` is designed to create or refresh the n8n-as-code block without destroying existing user or agent instructions.
 - Use the exact `n8nac command` and `n8n-manager command` listed in `AGENTS.md`. Those context-root commands override the portable examples in this skill.
-- Run every `npx --yes n8nac workspace ...`, `npx --yes n8nac list`, `pull`, `push`, `validate`, `test`, and `update-ai` command from the context root unless the user explicitly gives another context root.
+- Run every `npx --yes n8nac env ...`, `npx --yes n8nac workspace ...`, `npx --yes n8nac list`, `pull`, `push`, `validate`, `test`, and `update-ai` command from the context root unless the user explicitly gives another context root.
 - `AGENTS.md` is bootstrap context only, not a source of configuration truth.
-- Do not infer instance, project, sync folder, or workflow directory from `AGENTS.md`.
+- Do not infer environment, project, sync folder, or workflow directory from `AGENTS.md`.
 - Before n8n work, resolve the effective context from the backend:
 
 ```bash
-npx --yes n8nac workspace status --json
+npx --yes n8nac env status --json
 ```
 
 - Use the returned `workflowDir` for workflow files. Do not reconstruct it from `syncFolder`, `instanceIdentifier`, or `projectName`.
-- Never write `n8nac-config.json` by hand. Use `npx --yes n8nac workspace ...` commands.
+- Never write `n8nac-config.json`, `~/.n8n-manager`, or n8n-manager secret files by hand.
+
+## Workspace Readiness
+
+Use the unified migration preflight before resolving the effective environment. The dry-run is safe and reports whether any workspace migration is required:
+
+```bash
+npx --yes n8nac workspace migrate --json
+npx --yes n8nac env status --json
+```
+
+- Treat `workspace migrate --json` as the source of migration need.
+- Treat `env status --json` as the source of effective workspace readiness only after migration is not required or has been applied.
+- Do not infer readiness from raw files, generated agent docs, or directory names.
+- If migration is required, do not edit config files by hand or continue with environment/workflow work until it has been applied or explicitly deferred by the user.
+
+## Migration
+
+Migration is one user-facing command. Do not reason about internal migration phases directly; summarize the report `operations` array when explaining what will change.
+
+1. Run the dry-run first:
+
+```bash
+npx --yes n8nac workspace migrate --json
+```
+
+2. If the dry-run reports `status: "dry-run"`, `required: true`, or otherwise indicates pending changes, stop and ask once before applying it. Do not run `workspace migrate --write` unless the user already directly requested applying migration.
+3. After confirmation, apply migration and re-check readiness:
+
+```bash
+npx --yes n8nac workspace migrate --write
+npx --yes n8nac workspace migrate --json
+npx --yes n8nac env status --json
+```
+
+- Do not run `workspace migrate --write` without explicit confirmation unless the user already directly requested applying migration.
+- When reporting a dry-run, summarize the unified `operations` list and ask for exactly one confirmation for `npx --yes n8nac workspace migrate --write`.
+- Do not ask separately for different operation types. `npx --yes n8nac workspace migrate --write` applies the required migration as one operation.
+- Do not run environment, workflow, or setup commands while `workspace migrate --json` still reports migration required.
+- Managed local instances remain machine-global runtime resources.
+- Workspace environments remain workspace-scoped and are managed through `npx --yes n8nac env ...`.
 
 ## Bootstrap Order
 
 1. `cd` to the context root.
 2. Run `npx --yes n8nac update-ai`, then read `AGENTS.md`.
-3. Run `npx --yes n8nac workspace status --json`.
-4. If the context root is not ready, inspect instances with `npx --yes @n8n-as-code/n8n-manager instances list`.
-5. Reuse an existing instance when suitable.
-6. If no suitable instance exists, stop and ask the user whether they want to reuse/configure an existing instance, create a managed local n8n instance, or connect an existing/remote n8n instance. Do not create infrastructure by default. If the user chooses a managed local instance, ask separately whether they want a public tunnel.
-7. Ask for host/API key only for an explicitly remote or existing n8n instance.
-8. Configure context-root overrides with:
+3. Run `npx --yes n8nac workspace migrate --json`.
+4. If migration is required, stop and ask for confirmation before `npx --yes n8nac workspace migrate --write` unless the user already requested applying migration.
+5. Run `npx --yes n8nac env status --json` after migration is not required or has been applied.
+6. If the context root is not ready, inspect managed local instances with `npx --yes @n8n-as-code/n8n-manager instance list`.
+7. Reuse an existing environment or managed local instance when suitable.
+8. If no suitable environment exists, stop and ask the user whether they want to connect a remote n8n URL or create/reuse a managed local n8n instance. Do not create infrastructure by default. If the user chooses a managed local instance, ask separately whether they want a public tunnel.
+9. Ask for host/API key only for an explicitly remote n8n environment.
+10. Configure the environment with:
+
+```bash
+npx --yes n8nac env add <name> --base-url <url> --sync-folder workflows/<name>
+npx --yes n8nac env auth set <name> --api-key-stdin
+npx --yes n8nac env use <name>
+```
+
+For a managed local instance:
+
+```bash
+npx --yes n8nac env add Local --managed-instance <id> --sync-folder workflows/local
+npx --yes n8nac env use Local
+```
+
+11. Run `npx --yes n8nac update-ai` after changing environments when the facade does not do it automatically.
+
+## Environments
+
+Use `npx --yes n8nac env ...` for workspace environments, remote URLs, active environment, API-key binding, projects, and sync folders.
+
+```bash
+npx --yes n8nac env status --json
+npx --yes n8nac env list
+npx --yes n8nac env add <name> --base-url <url> --sync-folder workflows/<name>
+npx --yes n8nac env auth set <name> --api-key-stdin
+npx --yes n8nac env use <name>
+```
+
+- Prefer `--api-key-stdin` for API keys.
+- Do not pass secrets inline in shell arguments.
+- Do not ask for host/API key when the user wants a managed local Docker instance.
+- Do not print API keys or credential secret values back to the user.
+- If a command or flag is unfamiliar, run `npx --yes n8nac env --help` or `npx --yes n8nac env <subcommand> --help`.
+
+Attach a managed local instance to the workspace with `npx --yes n8nac env ...`:
+
+```bash
+npx --yes n8nac env add Local --managed-instance <id> --sync-folder workflows/local
+npx --yes n8nac env use Local
+```
+
+## Managed Local Runtime
+
+Use `npx --yes @n8n-as-code/n8n-manager` only for local managed instance lifecycle, tunnels, and workflow presentation commands that are part of the local runtime layer.
+
+Inspect existing managed instances before changing local machine state:
+
+```bash
+npx --yes @n8n-as-code/n8n-manager instance list
+npx --yes @n8n-as-code/n8n-manager instance --help
+npx --yes @n8n-as-code/n8n-manager config get
+```
+
+Do not invent n8n-manager subcommands. Use `npx --yes @n8n-as-code/n8n-manager <subcommand> --help` when unsure.
+
+When the context root is not configured and no suitable existing instance is available, stop and ask the user to choose. Do not create infrastructure by default.
+
+Present these choices clearly:
+
+- use an existing managed local instance if one is available;
+- create a new managed local n8n instance;
+- configure a remote n8n URL as a workspace environment through `npx --yes n8nac env`.
+
+If the user chooses a managed local Docker instance, ask the tunnel question separately:
+
+- without public tunnel: local n8n only, suitable for normal UI/API workflow work;
+- with public tunnel: exposes the instance through a public URL, useful for webhooks/forms/chat triggers and remote callbacks.
+
+Do not enable, refresh, or start a public tunnel unless the user explicitly requested public access, webhook testing, or approved the tunnel option. If public access is not needed, create/start the managed instance without `--tunnel`.
+
+Only run these commands after the user has explicitly chosen the corresponding option.
+
+Managed local instance without public tunnel:
+
+```bash
+npx --yes @n8n-as-code/n8n-manager instance create
+npx --yes @n8n-as-code/n8n-manager instance start <id>
+npx --yes @n8n-as-code/n8n-manager instance list
+```
+
+Managed local instance with public tunnel:
 
 ```bash
-npx --yes n8nac workspace pin-instance --instance-id <id>
-npx --yes n8nac workspace set-sync-folder workflows
-npx --yes n8nac workspace set-project --project-id <id> --project-name <name>
+npx --yes @n8n-as-code/n8n-manager instance create
+npx --yes @n8n-as-code/n8n-manager instance start <id>
+npx --yes @n8n-as-code/n8n-manager tunnel start <id>
 ```
 
-For self-hosted n8n instances where the projects API is unavailable or returns 401/403, do not keep retrying project discovery. Use the standard personal project override unless the user gave another project:
+Instance and tunnel operations are per managed local instance:
 
 ```bash
-npx --yes n8nac workspace set-project --project-id personal --project-name Personal
+npx --yes @n8n-as-code/n8n-manager instance start <id>
+npx --yes @n8n-as-code/n8n-manager instance stop <id>
+npx --yes @n8n-as-code/n8n-manager instance remove <id>
+npx --yes @n8n-as-code/n8n-manager tunnel start <id>
+npx --yes @n8n-as-code/n8n-manager tunnel stop <id>
 ```
 
-9. Run `npx --yes n8nac update-ai` after changing context-root overrides when the facade does not do it automatically.
+- Do not delete local instance data unless the user explicitly asks for destructive deletion.
+- If Docker is unavailable or the daemon is stopped, report the backend diagnostic and stop. Do not loop.
+- If a command fails repeatedly, stop after two attempts and explain the backend diagnostic.
 
 ## Sync Discipline
 
@@ -63,7 +194,7 @@ npx --yes n8nac push <path-to-workflow.workflow.ts> --verify
 ```
 
 - `push` requires the full workflow file path, either absolute or context-root-relative. Do not pass a bare filename.
-- For a new workflow, create the file inside the `workflowDir` returned by `workspace status --json`, then confirm it with `npx --yes n8nac list --local`.
+- For a new workflow, create the file inside the `workflowDir` returned by `env status --json`, then confirm it with `npx --yes n8nac list --local`.
 - If push/pull reports a conflict, use explicit resolution commands. Do not overwrite remote changes blindly.
 - `pull` and conflict resolution operate on a single workflow ID.
 - `list` is the lightweight command that covers all workflows at once.
@@ -275,7 +406,7 @@ npx --yes n8nac test <workflowId> --prod
 
 ## Workflow Presentation Contract
 
-`presentWorkflowResult` is the standard way to show a workflow to the user. It is part of the workflow authoring loop, even though the command lives in n8n-manager.
+`npx --yes n8nac workflow present` is the standard way to show a workflow to the user. It is v4-environment aware and part of the workflow authoring loop.
 
 Run it whenever one of these is true:
 
@@ -285,16 +416,17 @@ Run it whenever one of these is true:
 - the user asks to show, open, present, display, or give the URL/link for a workflow.
 
 ```bash
-npx --yes @n8n-as-code/n8n-manager presentWorkflowResult --workflow-id <workflowId> --workspace-root <contextRoot>
+npx --yes n8nac workflow present <workflowId> --json
 ```
 
 Rules:
 
 - Do not manually construct n8n workflow URLs.
 - Do not return an internal local n8n URL when a presentation URL is available.
-- Use the `url` returned by `presentWorkflowResult` as the user-facing URL.
+- Use the `url` returned by `workflow present --json` as the user-facing URL.
 - If you do not know the workflow ID, run `npx --yes n8nac list` first and select the matching workflow.
-- If `presentWorkflowResult` fails, report the backend diagnostic and then provide the best direct n8n URL only as a fallback.
+- Do not call `npx --yes @n8n-as-code/n8n-manager presentWorkflowResult`; it is a legacy runtime command and is not workspace-environment aware.
+- If `workflow present` fails, report the backend diagnostic and then provide the best direct n8n URL only as a fallback.
 - Do this before the final response when the task created, changed, pushed, ran, or explicitly asks to show a workflow.
 
 ### Testability Protocol
@@ -357,7 +489,7 @@ npx --yes n8nac workflow activate <workflowId>
 
 For most workflow tasks:
 
-1. Resolve context with `workspace status --json`.
+1. Resolve context with `env status --json`.
 2. Read `workflowDir` from the backend response.
 3. Inspect existing workflows with `list`.
 4. Pull before editing an existing workflow.
@@ -367,13 +499,13 @@ For most workflow tasks:
 8. Push with `--verify`.
 9. Test if the workflow is HTTP-triggered.
 10. Inspect executions when behavior is unclear.
-11. Present the final workflow link with `presentWorkflowResult`.
+11. Present the final workflow link with `npx --yes n8nac workflow present <workflowId> --json`.
 
 ## Response Discipline
 
 - Explain concrete actions and command results, not generic capability.
-- When the user asks for an URL or visual inspection of a workflow, run `presentWorkflowResult` instead of composing a URL manually.
-- If setup is missing, use `n8n-manager` for instance/auth/runtime and `n8nac workspace ...` for context-root overrides.
-- Do not ask for host/API key until existing n8n-manager instances have been inspected.
+- When the user asks for an URL or visual inspection of a workflow, run `npx --yes n8nac workflow present <workflowId> --json` instead of composing a URL manually.
+- If setup is missing, use `n8nac env ...` for workspace environments and `n8n-manager` only for managed local instances.
+- Do not ask for host/API key unless the user chooses a remote n8n environment.
 - Do not tell the user to run setup commands when you can run non-interactive commands yourself.
 - Stop after two repeated failures with the same diagnostic and report the backend error clearly.

package/skills/n8n-manager/SKILL.md

@@ -1,116 +0,0 @@
----
-name: n8n-manager
-description: Use when the user needs n8n instance, runtime, tunnel, auth, project, credential, or workflow presentation management through n8n-manager.
----
-
-# n8n Manager
-
-Use this skill for global n8n instance management. `n8n-manager` is the source of truth for instances, runtime state, tunnels, API keys, managed owner credentials, default projects, and workflow presentation links.
-
-## Responsibility Boundary
-
-- Generated context root hint: not embedded. Use the shell launch directory or the workspace path explicitly given by the user.
-- If `n8nac` is available, first run `npx --yes n8nac update-ai` from the context root, then read `AGENTS.md`. `update-ai` is designed to create or refresh the n8n-as-code block without destroying existing user or agent instructions.
-- Use the exact `n8n-manager command` and `n8nac command` listed in `AGENTS.md` when present. Those context-root commands override the portable examples in this skill.
-- Use `npx --yes @n8n-as-code/n8n-manager` for global instance, auth, runtime, tunnel, project-default, credential, and workflow-presentation operations.
-- Use `npx --yes n8nac workspace ...` only for context-root overrides such as pinned instance, sync folder, and project override.
-- Use `npx --yes n8nac` workflow commands only after the effective context is ready.
-- Never edit `n8nac-config.json`, `~/.n8n-manager`, or n8n-manager secret files by hand.
-
-## Core Commands
-
-Inspect existing instances before changing state:
-
-```bash
-npx --yes @n8n-as-code/n8n-manager instances list
-npx --yes @n8n-as-code/n8n-manager instances --help
-npx --yes @n8n-as-code/n8n-manager config get
-```
-
-Do not invent n8n-manager subcommands. In particular, `instances create` and `--type local` are not valid. Use `instances add --mode ...` exactly as documented by `instances --help`.
-
-## Unconfigured Context Root
-
-When the context root is not configured and no suitable existing instance is available, stop and ask the user to choose. Do not create infrastructure by default.
-
-Present these choices clearly:
-
-- use an existing n8n-manager instance if one is available;
-- create a new managed local Docker n8n instance;
-- connect an existing or remote n8n instance with user-provided credentials.
-
-If the user chooses a managed local Docker instance, ask the tunnel question separately:
-
-- without public tunnel: local n8n only, suitable for normal UI/API workflow work;
-- with public tunnel: exposes the instance through a public URL, useful for webhooks/forms/chat triggers and remote callbacks.
-
-Do not enable, refresh, or start a public tunnel unless the user explicitly requested public access, webhook testing, or approved the tunnel option. If public access is not needed, create/start the managed instance without `--tunnel`.
-
-## Confirmed Setup Commands
-
-Only run these commands after the user has explicitly chosen the corresponding option.
-
-Managed local Docker without public tunnel:
-
-```bash
-npx --yes @n8n-as-code/n8n-manager instances add --name <name> --mode managed-local-docker
-npx --yes @n8n-as-code/n8n-manager instances setup <id-or-name>
-npx --yes @n8n-as-code/n8n-manager instances start <id-or-name>
-npx --yes @n8n-as-code/n8n-manager instances status <id-or-name>
-```
-
-Managed local Docker with public tunnel:
-
-```bash
-npx --yes @n8n-as-code/n8n-manager instances add --name <name> --mode managed-local-docker --tunnel
-npx --yes @n8n-as-code/n8n-manager instances setup <id-or-name> --tunnel
-npx --yes @n8n-as-code/n8n-manager instances start <id-or-name>
-npx --yes @n8n-as-code/n8n-manager instances tunnel status <id-or-name>
-```
-
-Remote or existing instances require user-provided credentials. Prefer stdin for API keys:
-
-```bash
-npx --yes @n8n-as-code/n8n-manager auth set --url <url> --api-key-stdin --name <name>
-npx --yes @n8n-as-code/n8n-manager auth test --instance <id-or-name>
-```
-
-Project selection is instance-level unless the context root explicitly needs a workspace override:
-
-```bash
-npx --yes @n8n-as-code/n8n-manager projects list --instance <id-or-name>
-npx --yes @n8n-as-code/n8n-manager projects select <project-id-or-name> --instance <id-or-name>
-```
-
-Self-hosted n8n may not expose the projects API or may return 401/403. In that case, do not retry project discovery. Use the n8n-architect workspace override path with the standard personal project unless the user gave another project:
-
-```bash
-npx --yes n8nac workspace set-project --project-id personal --project-name Personal
-```
-
-Runtime and tunnel operations are per instance:
-
-```bash
-npx --yes @n8n-as-code/n8n-manager instances start <id-or-name>
-npx --yes @n8n-as-code/n8n-manager instances stop <id-or-name>
-npx --yes @n8n-as-code/n8n-manager instances restart <id-or-name>
-npx --yes @n8n-as-code/n8n-manager instances tunnel status <id-or-name>
-npx --yes @n8n-as-code/n8n-manager instances tunnel start <id-or-name>
-npx --yes @n8n-as-code/n8n-manager instances tunnel refresh <id-or-name>
-```
-
-Present workflow results after creating, modifying, pushing, or running a workflow:
-
-```bash
-npx --yes @n8n-as-code/n8n-manager presentWorkflowResult --workflow-id <workflowId> --workspace-root <contextRoot>
-```
-
-## Guardrails
-
-- Do not ask for host/API key before checking `instances list`.
-- Do not ask for host/API key when the user wants a managed local Docker instance.
-- Do not print API keys back to the user.
-- Do not delete runtime data unless the user explicitly asks for destructive deletion.
-- If Docker is unavailable or the daemon is stopped, report the backend diagnostic and stop. Do not loop.
-- If a command fails repeatedly, stop after two attempts and explain the backend diagnostic.
-- For workflow credentials, inspect the required credential type before asking for secret values.