@aksp/opencrew 1.4.0 → 1.4.2

package/src/commands/update.js

@@ -2,10 +2,12 @@ import path from 'node:path';
 import { promises as fs } from 'node:fs';
 import { templatesDir, packageJsonPath } from '../lib/paths.js';
 import { copyDir, exists, writeFileSafe, readJson, writeBridgeFile, readFile } from '../lib/fsx.js';
+import { AGENTS_BRIDGE, LEAKED_STATUS_SECTION, ideById } from '../lib/ides.js';
 import { c, log, info, ok, warn, step } from '../lib/ui.js';
 
 // Update refreshes ONLY the framework. It never touches:
-//   crews/, _opencrew/_memory/, _opencrew/_browser_profile/, .env, IDE bridges.
+//   crews/, _opencrew/_memory/, _opencrew/_browser_profile/, .env, IDE bridges
+//   (one exception: the CLAUDE.md block leaked by 1.4.0/1.4.1 — see removeLeakedStatusSection).
 // Note: catalog skills (skills/<name>/ that ship with the package) ARE fully
 // overwritten below — user edits to a catalog skill's own files are not preserved.
 // Only skill directories that don't exist in the package's templates/skills/ at all
@@ -72,24 +74,49 @@ export async function update(opts = {}) {
   await writeFileSafe(path.join(target, '_opencrew', 'core', 'system.md'), systemContent);
   ok('_opencrew/core/system.md refreshed');
 
-  const agentsBridge = '# opencrew\n\n'
-    + 'The opencrew system definition lives at `_opencrew/core/system.md`.\n'
-    + 'Read that file and adopt the opencrew system role — follow all initialization,\n'
-    + 'command routing, and workflow instructions defined there.\n\n'
-    + 'Type `/opencrew` to open the main menu.\n';
-
-  // If AGENTS.md is a legacy full-system doc (pre-v1.3), replace it entirely with the thin bridge.
-  const agentsPath = path.join(target, 'AGENTS.md');
-  const existingAgents = await readFile(agentsPath);
-  if (existingAgents.includes('# opencrew Instructions') && !existingAgents.includes('<!-- opencrew:start -->')) {
-    await writeFileSafe(agentsPath, agentsBridge);
-    ok('AGENTS.md (migrated from legacy full-system to thin bridge)');
-  } else {
-    await writeBridgeFile(agentsPath, agentsBridge);
-    ok('AGENTS.md refreshed');
-  }
+  await refreshAgentsBridge(target);
+  await removeLeakedStatusSection(target);
 
+  // Stamp last: a crash above leaves the old version, so the next update retries.
   await fs.writeFile(versionFile, version + '\n');
   log(`\n${c.green(c.bold('Updated to v' + version))}.`);
   log(c.dim('Your crews, memory, IDE bridges and .env were left untouched.\n'));
 }
+
+// Root AGENTS.md: create it if missing; a legacy full-system doc (pre-v1.3) is backed up
+// byte for byte and replaced by the thin bridge; otherwise only the marked block changes.
+async function refreshAgentsBridge(target) {
+  const agentsPath = path.join(target, 'AGENTS.md');
+  if (!(await exists(agentsPath))) {
+    await writeBridgeFile(agentsPath, AGENTS_BRIDGE);
+    ok('AGENTS.md (bridge created)');
+    return;
+  }
+  const existing = await readFile(agentsPath);
+  if (existing.includes('# opencrew Instructions') && !existing.includes('<!-- opencrew:start -->')) {
+    const backup = await freeBackupPath(agentsPath);
+    await fs.copyFile(agentsPath, backup);
+    await writeFileSafe(agentsPath, AGENTS_BRIDGE);
+    ok(`AGENTS.md (migrated from legacy full-system to thin bridge — backed up to ${path.basename(backup)})`);
+    return;
+  }
+  await writeBridgeFile(agentsPath, AGENTS_BRIDGE);
+  ok('AGENTS.md refreshed');
+}
+
+async function freeBackupPath(file) {
+  const bak = `${file}.bak`;
+  if (!(await exists(bak))) return bak;
+  return `${file}.bak-${new Date().toISOString().replace(/[:.]/g, '-')}`;
+}
+
+// 1.4.0/1.4.1 shipped the maintainer's STATUS.md workflow inside CLAUDE.md's opencrew
+// block. Rewrite that block (only that block, only if the leak is there).
+async function removeLeakedStatusSection(target) {
+  const claudePath = path.join(target, 'CLAUDE.md');
+  if (!(await exists(claudePath))) return;
+  if (!(await readFile(claudePath)).includes(LEAKED_STATUS_SECTION)) return;
+  const bridge = ideById('claude-code').files.find((f) => f.path === 'CLAUDE.md');
+  await writeBridgeFile(claudePath, bridge.content);
+  ok('CLAUDE.md (removed the STATUS.md section shipped by mistake in 1.4.0/1.4.1)');
+}

package/src/lib/errors.js

@@ -0,0 +1,12 @@
+// Error types the CLI turns into exit codes (see src/cli.js → exitCodeFor).
+
+/** Wrong flags/arguments — reported in one line, exit 1, nothing written. */
+export class UsageError extends Error {
+  constructor(message) {
+    super(message);
+    this.name = 'UsageError';
+  }
+}
+
+/** @inquirer throws this when the user presses Ctrl+C on a prompt. */
+export const isPromptCancel = (e) => e?.name === 'ExitPromptError';

package/src/lib/fsx.js

@@ -54,17 +54,21 @@ export async function writeFileSafe(p, content, { overwrite = true } = {}) {
  * Write a bridge file using marked-block strategy.
  * - File doesn't exist → creates with content wrapped in HTML markers
  * - File exists with markers → replaces only the block between markers
- * - File exists without markers → prepends marked block, preserves existing content
+ * - File exists without markers → adds the marked block (prepend or append), preserving
+ *   existing content byte for byte
  *
  * @param {string}   p       File path
  * @param {string}   block   Content to place between markers
  * @param {object}   opts
- * @param {string}   opts.marker  Marker name (default: 'opencrew')
+ * @param {string}   opts.marker    Marker name (default: 'opencrew')
+ * @param {'html'|'hash'} opts.comment  `<!-- x:start -->` (markdown) or `# x:start` (.gitignore, .env)
+ * @param {'prepend'|'append'} opts.position  Where a new block goes in an unmarked file
  * @returns {Promise<{written: boolean, merged: boolean}>}
  */
-export async function writeBridgeFile(p, block, { marker = 'opencrew' } = {}) {
-  const start = `<!-- ${marker}:start -->`;
-  const end = `<!-- ${marker}:end -->`;
+export async function writeBridgeFile(p, block, { marker = 'opencrew', comment = 'html', position = 'prepend' } = {}) {
+  const [start, end] = comment === 'hash'
+    ? [`# ${marker}:start`, `# ${marker}:end`]
+    : [`<!-- ${marker}:start -->`, `<!-- ${marker}:end -->`];
   const marked = `${start}\n${block.trimEnd()}\n${end}`;
 
   if (!(await exists(p))) {
@@ -77,9 +81,11 @@ export async function writeBridgeFile(p, block, { marker = 'opencrew' } = {}) {
 
   // Already has markers → replace just the block, keep everything else
   if (existing.includes(start) && existing.includes(end)) {
+    // Innermost block only: an orphan start marker (end deleted by hand) must never make
+    // the match swallow the user lines between it and the real block.
     const updated = existing.replace(
-      new RegExp(escapeRx(start) + '[\\s\\S]*?' + escapeRx(end), 'g'),
-      marked,
+      new RegExp(`${escapeRx(start)}(?:(?!${escapeRx(start)})[\\s\\S])*?${escapeRx(end)}`, 'g'),
+      () => marked,
     );
     if (updated !== existing) {
       await fs.writeFile(p, updated);
@@ -88,8 +94,11 @@ export async function writeBridgeFile(p, block, { marker = 'opencrew' } = {}) {
     return { written: false, merged: false };
   }
 
-  // User content exists → prepend block, preserve everything
-  await fs.writeFile(p, marked + '\n\n' + existing.trimStart());
+  // User content exists → add the block, preserve everything
+  const merged = position === 'append'
+    ? `${existing.trimEnd()}\n\n${marked}\n`
+    : `${marked}\n\n${existing.trimStart()}`;
+  await fs.writeFile(p, merged);
   return { written: true, merged: true };
 }
 

package/src/lib/ides.js

@@ -41,42 +41,17 @@ Type \`/opencrew\` to open the main menu.
 - All checkpoint questions use \`AskUserQuestion\`.
 - opencrew ships its own Playwright MCP (\`.mcp.json\`); disable the native Playwright plugin.
 - Do not manually edit files under \`_opencrew/core/\` unless you know what you're doing.
+`;
 
-## STATUS.md (gestão de sessão)
-
-This project uses \`STATUS.md\` for session continuity. The file is local (gitignored).
-
-**At the start of every session:**
-- Read \`STATUS.md\`. If it doesn't exist, create it with the template below.
-- Report a 3-line summary: what was in progress, what's next, any blockers.
-
-**During the session:**
-- Move items from ⬜ Pendente to 🔄 Em andamento when you start working on them.
-- Move items to ✅ Concluído when finished.
-- Add new items that emerge during work.
-
-**Before ending the session:**
-- Ensure \`STATUS.md\` reflects the real state.
-- Update \`Última sessão\` timestamp.
-
-**Template:**
-\`\`\`markdown
-# STATUS — OpenCrew
-
-> Última sessão: {today}
-> Skill: /status
-
-## 🔄 Em andamento
-
-## ⬜ Pendente
-
-## ✅ Concluído (esta sessão)
-
-## 📋 Backlog
+// Root AGENTS.md: thin bridge to the full system definition (written by init and update).
+export const AGENTS_BRIDGE = '# opencrew\n\n'
+  + 'The opencrew system definition lives at `_opencrew/core/system.md`.\n'
+  + 'Read that file and adopt the opencrew system role — follow all initialization,\n'
+  + 'command routing, and workflow instructions defined there.\n\n'
+  + 'Type `/opencrew` to open the main menu.\n';
 
-## 💡 Decisões
-\`\`\`
-`;
+// Marker that identifies the maintainer STATUS.md section leaked into CLAUDE.md by 1.4.0/1.4.1.
+export const LEAKED_STATUS_SECTION = '## STATUS.md (gestão de sessão)';
 
 const render = (title, extra = '') =>
   `# ${title}\n\n${BRIDGE}${extra ? `\n\n${extra}` : ''}\n`;

package/templates/AGENTS.md

@@ -1,6 +1,7 @@
 # opencrew Instructions
 
-You are now operating as the opencrew system. Your primary role is to help users create, manage, and run AI agent crews.
+You are operating as the opencrew system. Your primary role is to help users
+create, manage, and run AI agent crews.
 
 ## Initialization
 
@@ -8,55 +9,48 @@ On activation, perform these steps IN ORDER:
 
 1. Read the company context file: `{project-root}/_opencrew/_memory/company.md`
 2. Read the preferences file: `{project-root}/_opencrew/_memory/preferences.md`
-3. Check if company.md is empty or contains only the template — if so, trigger ONBOARDING flow
+3. Check if company.md is empty or contains only the template — if so, trigger ONBOARDING
 4. Otherwise, display the MAIN MENU
 
 ## Onboarding Flow (first time only)
 
 If `company.md` is empty or contains `<!-- NOT CONFIGURED -->`:
 
-1. Welcome the user warmly to opencrew
-2. Ask their name (save to preferences.md)
-3. Ask their preferred language for outputs (save to preferences.md)
-4. Ask for their company name/description and website URL
-5. Use WebFetch on their URL + WebSearch with their company name to research:
-   - Company description and sector
-   - Target audience
-   - Products/services offered
-   - Tone of voice (inferred from website copy)
-   - Social media profiles found
-6. Present the findings in a clean summary and ask the user to confirm or correct
-7. Save the confirmed profile to `_opencrew/_memory/company.md`
-8. Show the main menu
+1. Welcome the user warmly; ask their name and preferred output language (save to
+   preferences.md)
+2. Ask for company name/description and website URL
+3. Use WebFetch on the URL + WebSearch on the company name to research:
+   description/sector, target audience, products/services, tone of voice,
+   social media profiles
+4. Present findings in a clean summary, ask the user to confirm or correct,
+   save the profile to `_opencrew/_memory/company.md`
+5. Show the main menu
 
 ## Main Menu
 
-When the user types `/opencrew` or asks for the menu, present an interactive selector with these options (max 4 per question). Use your IDE's native interactive-choice mechanism if it has one (e.g. Claude Code's `AskUserQuestion`); otherwise present the options as a numbered list and ask the user to reply with a number:
+When the user types `/opencrew` or asks for the menu, present an interactive
+selector with these options (max 4 per question). Use your IDE's native
+interactive-choice mechanism if it has one; otherwise present the options as a
+numbered list and ask the user to reply with a number.
 
-**Primary menu (first question):**
-- **Create a new crew** — Describe what you need and I'll build a crew for you
-- **Run an existing crew** — Execute a crew's pipeline
-- **My crews** — View, edit, repair, or delete your crews
-- **More options** — Skills, company profile, settings, and help
+**Primary menu:** Create a new crew · Run an existing crew · My crews ·
+More options
 
-If the user selects "More options", present a second selector the same way:
-- **Skills** — Browse, install, create, and manage skills for your crews
-- **Company profile** — View or update your company information
-- **Settings & Help** — Language, preferences, configuration, and help
+**More options:** Skills · Company profile · Settings & Help
 
 ## Command Routing
 
-Parse user input and route to the appropriate action:
+Route input to the matching action:
 
 | Input Pattern | Action |
 |---------------|--------|
 | `/opencrew` or `/opencrew menu` | Show main menu |
 | `/opencrew help` | Show help text |
 | `/opencrew create <description>` | Load Architect → Create Crew flow |
-| `/opencrew list` | List all crews in `crews/` directory |
+| `/opencrew list` | List all crews in `crews/` |
 | `/opencrew run <name>` | Load Pipeline Runner → Execute crew |
 | `/opencrew edit <name> <changes>` | Load Architect → Edit Crew flow |
-| `/opencrew repair <name>` | Load `_opencrew/core/prompts/repair.prompt.md` → fix agent names / rebuild crew-party.csv manifest |
+| `/opencrew repair <name>` | Load `_opencrew/core/prompts/repair.prompt.md` → fix agent names / rebuild crew-party.csv |
 | `/opencrew skills` | Load Skills Engine → Show skills menu |
 | `/opencrew install <name>` | Install a skill from the catalog |
 | `/opencrew uninstall <name>` | Remove an installed skill |
@@ -74,7 +68,7 @@ When a specific agent needs to be activated:
 1. Read the agent's `.agent.md` file completely
 2. Adopt the agent's persona (role, identity, communication_style, principles)
 3. Follow the agent's menu/workflow instructions
-4. When the agent's task is complete, return to opencrew main context
+4. When the agent's task is complete, return to the opencrew main context
 
 ## Loading the Pipeline Runner
 
@@ -82,37 +76,26 @@ When running a crew:
 
 1. Read `crews/{name}/crew.yaml` to understand the pipeline
 2. Read `crews/{name}/crew-party.csv` to load all agent personas
-3. For each agent in the party CSV, also read their full `.agent.md` file from agents/ directory
-4. Load company context from `_opencrew/_memory/company.md`
+3. For each agent in the party CSV, also read their full `.agent.md` file
+4. Load company context from `_opencrew/_memory/company.md` and user preferences
+   from `_opencrew/_memory/preferences.md` (used to check the Dashboard toggle)
 5. Load crew memory from `crews/{name}/_memory/memories.md`
-6. Load user preferences from `_opencrew/_memory/preferences.md` (used to check the Dashboard toggle — see below)
-7. Read the pipeline runner instructions from `_opencrew/core/runner.pipeline.md`
-7b. **Pre-Execution Agent Selection** — only when `crew.yaml` declares
-    `agent_dependencies:`. The runner analyzes the user's request against the decision
-    matrix, presents the agents as a numbered multi-select (IDE-neutral), lets the user
-    confirm/adjust, warns about broken dependencies, and builds the filtered step list
-    (see `_opencrew/core/runner.pipeline.md` step 4b). Crews without the field skip this
-    and run all agents.
-8. Execute the pipeline step by step following runner instructions
+6. Read the pipeline runner instructions from `_opencrew/core/runner.pipeline.md`
+7. **Pre-Execution Agent Selection** — only when `crew.yaml` declares
+   `agent_dependencies:`. Analyze the user's request against the decision matrix,
+   present the agents as a numbered multi-select (IDE-neutral), let the user
+   confirm/adjust, warn about broken dependencies, and build the filtered step
+   list. Crews without the field skip this and run all agents.
+8. Execute the pipeline step by step following the runner instructions
 
 ## Dashboard (Optional)
 
-opencrew ships an optional visual dashboard — a self-contained HTML file
-(`dashboard/index.html`) that shows a crew run in progress as an animated
-virtual office. It is **disabled by default** and most installs never use it,
-so the Pipeline Runner does not write `state.json` unless the user has turned
-it on.
-
-- To use: open `dashboard/index.html` in a browser and point it at the
-  `crews/{name}/state.json` written during a run.
-- Toggle: `Dashboard: enabled` (or `disabled`) in `_opencrew/_memory/preferences.md`,
-  editable via `/opencrew settings`.
-- When disabled (default): the runner never creates, writes, or deletes `state.json`.
-- When enabled: the runner writes `crews/{name}/state.json` before each step and at
-  every handoff, exactly as described in `_opencrew/core/runner.pipeline.md`.
-- The dashboard auto-polls `state.json` every 1.5 seconds when in live mode;
-  it also includes a built-in demo mode so you can see what it looks like
-  without running a real crew.
+The dashboard is an optional animated view of a crew run (`dashboard/index.html`).
+It is **disabled by default**; most installs never use it. Toggle it via
+`Dashboard: enabled|disabled` in `_opencrew/_memory/preferences.md` (editable via
+`/opencrew settings`). When disabled, the runner never writes `state.json`; when
+enabled, it writes `crews/{name}/state.json` before each step and at every handoff
+(see `_opencrew/core/runner.pipeline.md`).
 
 ## Language Handling
 
@@ -120,13 +103,9 @@ it on.
 - All user-facing output should be in the user's preferred language
 - Internal file names and code remain in English
 - Agent personas communicate in the user's language
-- **Exception — crew memory scaffolding stays in PT-BR regardless of Output Language.**
-  The section headers in `crews/{name}/_memory/memories.md` (e.g. `## Estilo de Escrita`)
-  and the table columns in `crews/{name}/_memory/runs.md` (e.g. `Data | Run ID | Tema`) are
-  fixed structural labels, not generated prose — see `_opencrew/core/runner.pipeline.md`.
-  opencrew's primary supported audience is PT-BR (see README), so these are intentionally
-  not localized per-user. Only the *content* written into those sections follows the
-  user's Output Language.
+- Exception: crew memory scaffolding (`memories.md` headers, `runs.md` columns)
+  keeps fixed PT-BR structural labels regardless of the user's language —
+  see `_opencrew/core/runner.pipeline.md`
 
 ## Critical Rules
 

package/templates/_opencrew/.opencrew-version

@@ -1 +1 @@
-1.4.0
+1.4.2

package/templates/_opencrew/core/prompts/build.prompt.md

@@ -390,9 +390,16 @@ model_tier: fast      # ONLY for execution: subagent. fast = lightweight model;
                       # Set fast for: investigator agents (data extraction, Sherlock subagents), researcher agents (web search, data gathering)
                       # Set powerful for: writer, creator, reviewer, strategy agents
                       # Omit model_tier for execution: inline steps
+side_effects: irreversible  # REQUIRED for any step that publishes, posts, sends email or otherwise
+                            # distributes outside the project (it cannot be undone). The Pipeline
+                            # Runner never retries these automatically, and Gate 2c places them last.
+                            # Omit for every other step.
 ---
 ```
 
+**Irreversible steps must run inline** (`execution: inline`), so the user sees the dry run and
+gives the explicit go-ahead in the main conversation.
+
 For **checkpoints**, use this frontmatter instead:
 ```yaml
 ---
@@ -572,6 +579,20 @@ If ANY check fails:
 4. Generate a step file for the new checkpoint that asks the user to review and approve the preceding agent's output before the visual/publish step runs
 5. Re-validate Gate 2b. Max 2 fix attempts — after that, present to user for manual decision.
 
+### Gate 2c: Irreversible Steps Last (BLOCKING)
+
+For EACH step that publishes, posts, sends email or distributes outside the project:
+- [ ] Its frontmatter declares `side_effects: irreversible` and `execution: inline`
+- [ ] It comes AFTER the Review step (the reviewer has already approved the final content)
+- [ ] The IMMEDIATELY preceding step is a `type: checkpoint` (Final Approval) that itself comes after the Review
+- [ ] Only other irreversible steps follow it (nothing is created, rendered or reviewed after publishing)
+
+If ANY check fails:
+1. Add the missing `side_effects: irreversible` / `execution: inline` fields
+2. Move the irreversible step(s) to the end of the pipeline, after Review → Final Approval checkpoint
+   (create the Final Approval checkpoint if it does not exist), and renumber the steps
+3. Re-validate Gate 2c. Max 2 fix attempts — after that, present to user for manual decision.
+
 ### Gate 3: Pipeline Coherence (ADVISORY)
 
 Verify:

package/templates/_opencrew/core/prompts/design.prompt.md

@@ -525,10 +525,14 @@ ERRADO: 5 noticias diferentes = NAO sao angulos, sao pautas distintas
 
 #### Pipeline Patterns
 
-- **Standard (fixed source):** Research → Angle Selection checkpoint → Creation → Content Approval checkpoint → [Execution Steps] → Review → Final Approval checkpoint
-- **News-based (multiple stories):** Research → News Selection checkpoint → Creator[generate-angles] → Angle Selection checkpoint → Creator[create+optimize] → Content Approval checkpoint → [Execution Steps] → Review → Final Approval checkpoint
+- **Standard (fixed source):** Research → Angle Selection checkpoint → Creation → Content Approval checkpoint → [Render Steps] → Review → Final Approval checkpoint → [Publish/Send Steps]
+- **News-based (multiple stories):** Research → News Selection checkpoint → Creator[generate-angles] → Angle Selection checkpoint → Creator[create+optimize] → Content Approval checkpoint → [Render Steps] → Review → Final Approval checkpoint → [Publish/Send Steps]
 
-**Content Approval checkpoint is MANDATORY** whenever the pipeline includes any execution step after content creation (image generation, visual rendering, publishing, distribution, etc.). Never place an execution step immediately after a creation step without a checkpoint in between.
+**Render Steps** (image generation, visual rendering, slides) are reversible and run BEFORE the Review, so the reviewer sees the final visuals.
+
+**Publish/Send Steps** (social media posting, email sending, any distribution outside the project) are IRREVERSIBLE: they ALWAYS come last — after the Review and immediately after the Final Approval checkpoint — and their step files declare `side_effects: irreversible` (see build.prompt.md, Pipeline Step Format and Gate 2c). Never place a publish/send step before the Review. Omit either bracket when the crew has no such step.
+
+**Content Approval checkpoint is MANDATORY** whenever the pipeline includes any render step after content creation. Never place a render step immediately after a creation step without a checkpoint in between.
 
 On reject: loop back to creation step (re-execute full creator, not individual tasks).
 
@@ -555,8 +559,8 @@ I'll create a crew with N agents:
    Format: [format name, if applicable]
 ...
 
-Pipeline (fixed source): [Research] → checkpoint Select Angle → [Creator] → checkpoint Approve Content → [Execution] → [Review] → checkpoint Approve
-Pipeline (news-based): [Research] → checkpoint Select News → [Creator: generate angles] → checkpoint Select Angle → [Creator: create content] → checkpoint Approve Content → [Execution] → [Review] → checkpoint Approve
+Pipeline (fixed source): [Research] → checkpoint Select Angle → [Creator] → checkpoint Approve Content → [Render] → [Review] → checkpoint Final Approval → [Publish/Send]
+Pipeline (news-based): [Research] → checkpoint Select News → [Creator: generate angles] → checkpoint Select Angle → [Creator: create content] → checkpoint Approve Content → [Render] → [Review] → checkpoint Final Approval → [Publish/Send]
 Formats: [list of selected formats, e.g., instagram-feed, twitter-thread]
 
 Reference materials: [list of data files]

package/templates/_opencrew/core/runner.pipeline.md

@@ -20,7 +20,8 @@ Before starting execution:
     optional, opt-in feature that most installs never use (it requires running the
     separate dashboard app from source — see README). Scan the already-loaded
     `preferences.md` for a `Dashboard:` field:
-    - If it reads `Dashboard: enabled` → set `dashboard_enabled = true` for this run.
+    - If its value is `enabled` (as written by onboarding: `- **Dashboard:** enabled`, or the
+      plain form `Dashboard: enabled`) → set `dashboard_enabled = true` for this run.
     - Otherwise (`disabled`, missing, or preferences.md not configured yet) →
       set `dashboard_enabled = false`. This is the default.
     Store `dashboard_enabled` in working memory for the rest of this run. Every
@@ -546,7 +547,12 @@ Use the **stored transformed path** (after Output Path Transformation Steps 1 an
 
 **Rules:**
 - If ALL output files return `VALIDATION:PASS` → proceed to Veto Condition Enforcement.
-- If ANY output file returns `VALIDATION:FAIL`:
+- **Irreversible step** (`side_effects: irreversible` — publish, post, send) with ANY
+  `VALIDATION:FAIL` → NEVER re-execute it. Tell the user: "⚠️ {Agent Name} did not save its
+  output, but the action may already have happened (post published / email sent). Check
+  before retrying." Then offer: 1. Retry step (only after the user checked) · 2. Mark as done
+  and continue · 3. Abort pipeline.
+- If ANY output file returns `VALIDATION:FAIL` (any other step):
   1. **Retry once**: re-execute the entire step with the same input and context.
   2. After re-execution, run the validation again for all output files.
   3. If second attempt returns `VALIDATION:PASS` for all files → proceed normally.
@@ -612,6 +618,9 @@ After an agent completes a step (before moving to the next step):
    - Ask the agent to fix the specific issue (re-execute with targeted correction)
    - Maximum 2 veto fix attempts per step
    - After 2 failed attempts, present to user for manual decision
+   - **Never auto-fix an irreversible step** (`side_effects: irreversible`): re-executing it
+     would publish/send again. Report the veto, warn the user that
+     the action may already have happened, and let the user decide.
 4. If no veto conditions triggered: proceed to next step
 
 This creates an internal quality loop BEFORE the reviewer sees the content,
@@ -809,6 +818,9 @@ This archives the run state for the `runs` command while keeping crew history av
 ## Error Handling
 
 - If a subagent fails, retry once. If it fails again, inform the user and offer to skip the step or abort.
+- If an irreversible step (`side_effects: irreversible`) fails, NEVER retry it automatically:
+  the post/email may already have happened. Tell the user so, ask them to check, and let them
+  choose: retry, mark as done, or abort.
 - If a step file is missing, inform the user and suggest running `/opencrew edit {crew}` to fix.
 - If company.md is empty, stop and redirect to onboarding.
 - Never continue past a checkpoint without user input.

package/templates/gitignore

@@ -2,8 +2,10 @@ node_modules/
 .env
 *.log
 crews/*/output/
+crews/*/state.json
+crews/*/_investigations/
 _opencrew/_memory/company.md
 _opencrew/_memory/preferences.md
 _opencrew/_browser_profile/
 _opencrew/logs/
-STATUS.md
+.claude/settings.local.json

package/templates/skills/image-ai-generator/SKILL.md

@@ -14,7 +14,7 @@ type: script
 version: "1.0.0"
 script:
   path: scripts/generate.py
-  runtime: python3
+  runtime: python
   invoke: "python3 {skill_path}/scripts/generate.py --prompt \"{prompt}\" --output \"{output}\" --mode \"{mode}\""
 env:
   - OPENROUTER_API_KEY
@@ -52,10 +52,14 @@ Use the Image Generator when you need to create visual assets from text prompts.
 
 ## Instructions
 
+`{skill_path}` is this skill's folder (normally `skills/image-ai-generator`). The commands below use
+`python3` (macOS/Linux). **On Windows** use `py -3` instead (or `python` if the `py` launcher is
+not installed).
+
 ### Single image generation
 
 ```bash
-python3 skills/image-generator/scripts/generate.py \
+python3 {skill_path}/scripts/generate.py \
   --prompt "A detailed description of the image to generate" \
   --output "crews/{crew}/output/{run_id}/assets/image-name.jpg" \
   --mode test
@@ -66,7 +70,7 @@ python3 skills/image-generator/scripts/generate.py \
 Use `--reference` to send a local image to the model as visual context. The model will incorporate the referenced image (e.g., a logo or mascot) into the generated output.
 
 ```bash
-python3 skills/image-generator/scripts/generate.py \
+python3 {skill_path}/scripts/generate.py \
   --prompt "A social media banner featuring the company logo prominently in the center" \
   --output "crews/{crew}/output/{run_id}/assets/banner.jpg" \
   --reference "crews/{crew}/assets/logo.png" \
@@ -78,7 +82,7 @@ Supported reference formats: PNG, JPEG, WEBP, GIF.
 ### Batch generation
 
 ```bash
-python3 skills/image-generator/scripts/generate.py \
+python3 {skill_path}/scripts/generate.py \
   --batch "crews/{crew}/output/{run_id}/assets/batch.json" \
   --mode production
 ```

package/templates/skills/image-creator/SKILL.md

@@ -46,7 +46,8 @@ Use the Visual Renderer when you need to generate production-ready images from H
 4. **Render** -- Use Playwright to:
    - `browser_navigate` to `http://localhost:8765/slide-01.html` (filename only, not full path)
    - `browser_resize` to target viewport dimensions
-   - `browser_take_screenshot` to save as PNG
+   - `browser_take_screenshot` to save as PNG — **except when the images will be published to
+     Instagram**: Instagram accepts JPEG only, so save with `type: "jpeg"` (`slide-01.jpg`)
 
 5. **Verify** -- Read the screenshot to confirm quality. Re-render if needed.
 
@@ -103,6 +104,7 @@ For multi-image outputs like carousels:
 3. Render each slide sequentially (step 4 repeated per slide)
 4. Stop the HTTP server **once** after all slides are done (step 6 of Core Workflow)
 5. Name output files with zero-padded numbers: slide-01.png, slide-02.png, slide-03.png
+   (`.jpg` when the destination is Instagram — see step 4)
 6. Keep all slides at the same viewport dimensions
 
 ### Best Practices