@duckmind/dm-darwin-x64 0.43.8 → 0.49.0

package/extensions/dm-cua/README.md

@@ -1,24 +0,0 @@
-# dm-cua
-
-Browser-first Computer Use extension for DM.
-
-What it does:
-
-- launches or reuses a dedicated browser profile via the bundled `greedysearch-dm` CDP helpers
-- bootstraps a blank tab on fresh empty profiles so browser automation does not fail on the first run
-- exposes one tool, `browser_cua`, for list / navigate / snapshot / screenshot / click / type / evaluate / stop
-- stores browser screenshots under `~/.dm/agent/cua/screenshots/` by default
-
-Browser selection:
-
-- default: Chrome/Chromium auto-detected by `greedysearch-dm`
-- opt-in CloakBrowser trial: set `DM_CUA_BROWSER=cloak` and one of `DM_CUA_BROWSER_PATH`, `DM_CUA_CLOAK_PATH`, `CLOAKBROWSER_BINARY_PATH`, or `CHROME_PATH` to the CloakBrowser Chromium executable
-- DM does not bundle or auto-download the compiled CloakBrowser binary; install/pre-download it outside DM first because upstream permits use but not redistribution
-- Current `browser_cua` actions still use CDP commands through `greedysearch-dm`; full CloakBrowser stealth parity would require a future Playwright-backed CUA lane.
-
-What it does **not** do yet:
-
-- it does not replace the macOS `computer-use` Codex plugin lane
-- it does not replace Android `adbridge`
-
-Those broader lanes are still tracked separately. This extension closes the most actionable CUA gap from the current DM snapshot: a first-class browser lane that works from a fresh dedicated browser profile instead of overloading `coding_task`.

package/extensions/dm-fff/README.md

@@ -1,36 +0,0 @@
-# dm-fff
-
-Bundled DM extension that adds FFF-powered fuzzy file and content search.
-
-Technical provenance: this package is synced from `dmtrKovalenko/fff` at commit `18f546a4fe8939d884b495a7d761f4905ad205a3`; the exact upstream package path is recorded in `extensions/.dm-extensions.json`. DM ships the adapted source as `dm-fff`.
-
-## What it does
-
-| Built-in tool | dm-fff replacement | Improvement |
-|---|---|---|
-| `find` | `fffind` | Fuzzy matching, frecency ranking, git-aware, pre-indexed |
-| `grep` | `ffgrep` | SIMD-accelerated, frecency-ordered, mmap-cached, no subprocess |
-| *(none)* | `fff-multi-grep` | OR-logic multi-pattern search via Aho-Corasick |
-| `@` file autocomplete | FFF-backed autocomplete | Fuzzy ranking from FFF index/frecency |
-
-## Tools
-
-- `ffgrep` — search file contents with smart case, optional regex/literal mode, context, limit, and cursor pagination.
-- `fffind` — fuzzy file name search with frecency ranking.
-- `fff-multi-grep` — OR-logic multi-pattern content search when `DM_FFF_MULTIGREP=1`.
-
-## Commands
-
-- `/fff-mode` — show or set FFF mode: `tools-and-ui`, `tools-only`, or `override`.
-- `/fff-health` — show FFF status.
-- `/fff-rescan` — trigger a file rescan.
-
-## Configuration
-
-- `--fff-mode` / `DM_FFF_MODE`
-- `--fff-frecency-db` / `FFF_FRECENCY_DB`
-- `--fff-history-db` / `FFF_HISTORY_DB`
-- `--fff-enable-root-scan` / `FFF_ENABLE_ROOT_SCAN`
-- `DM_FFF_MULTIGREP=1` to enable `fff-multi-grep`.
-
-No separate install step is required. Install `dm`; this extension is bundled.

package/extensions/dm-fff/tsconfig.json

@@ -1,13 +0,0 @@
-{
-  "compilerOptions": {
-    "target": "ES2022",
-    "module": "ES2022",
-    "moduleResolution": "bundler",
-    "strict": true,
-    "esModuleInterop": true,
-    "skipLibCheck": true,
-    "noEmit": true,
-    "types": ["node"]
-  },
-  "include": ["src"]
-}

package/extensions/dm-goal/CHANGELOG.md

@@ -1,12 +0,0 @@
-# dm-goal changelog
-
-This managed bundled copy is generated by the DM rebrand pipeline from the pinned source recorded in `extensions/.dm-extensions.json`.
-
-## DM integration
-
-- Rebrands the package and user-facing copy to `dm-goal`.
-- Tracks the pinned single-extension source path recorded in `extensions/.dm-extensions.json`.
-- Keeps `/goal` plus the `goal_complete` completion tool.
-- Stores goal state under the `goal-state` entry type and DM state file path.
-- Rewrites hidden continuation markers to `dm-goal-continuation`.
-- Uses installable DM runtime package aliases for local typecheck and test runs.

package/extensions/dm-goal/README.md

@@ -1,29 +0,0 @@
-# dm-goal
-
-Bundled DM extension that keeps a long-running objective active until the assistant proves it is complete.
-
-## Included command surface
-
-- `/goal`
-- `/goal <objective>`
-- `/goal status`
-- `/goal pause`
-- `/goal resume`
-- `/goal clear`
-- `/goal budget <tokens>`
-
-## Included tools
-
-- `goal_complete`
-
-## Runtime notes
-
-- Active goals add a hidden continuation prompt before each agent turn.
-- The assistant must call `goal_complete` with concrete evidence before DM clears the goal.
-- Goal state is stored in the DM coding-agent state directory, defaulting to `~/.dm/agent/dm-goal-state.json`.
-- Set `DM_CODING_AGENT_DIR` to move that state file with the rest of the coding-agent runtime data.
-- Hidden continuation prompts XML-escape the objective before embedding it in untrusted blocks.
-
-## Bundled with dm
-
-No separate install step is required. Install `dm`, then run `/goal` inside the TUI.

package/extensions/dm-goal/tsconfig.json

@@ -1,15 +0,0 @@
-{
-	"compilerOptions": {
-		"target": "ES2022",
-		"module": "NodeNext",
-		"moduleResolution": "NodeNext",
-		"strict": false,
-		"skipLibCheck": true,
-		"esModuleInterop": true,
-		"allowSyntheticDefaultImports": true,
-		"resolveJsonModule": true,
-		"types": ["node"],
-		"noEmit": true
-	},
-	"include": ["src/**/*.ts", "test/**/*.ts"]
-}

package/extensions/dm-grill-me/DESIGN.md

@@ -1,301 +0,0 @@
-# Grill Me DM Extension Design
-
-## Purpose
-
-Create a DM extension inspired by Claude's `grill-me` skill. The extension applies a Socratic, one-question-at-a-time planning process to reach shared understanding of a project, plan, idea, learning goal, or design.
-
-The extension should be useful both for:
-
-- beginners who do not yet know which dimensions should be explored, and
-- expert users who want a planning/stress-test mode as an alternative to plan mode.
-
-## Core Principles
-
-1. **Shared understanding first**: the goal is not to immediately implement, but to converge on a clear, useful understanding of the user's intent.
-2. **Thorough by default**: Grill Me uses one thorough, collaborative Socratic style that asks enough follow-up questions to resolve or intentionally defer major branches before readiness.
-3. **Adaptive interview, hardcoded ending**: avoid fixed product/UX/architecture interview phases. Use adaptive dimensions such as objective, constraints, outcome mode, risks, tradeoffs, unknowns, and next steps. The final output-selection phase is the one mandatory hardcoded phase before stopping or producing outputs.
-4. **Mostly one question at a time**: default pacing asks one focused question per assistant turn, with small grouped questions allowed only when inseparable.
-5. **Alternatives included by default**: each grill question should include 2-5 concrete answer alternatives, including the assistant's recommended answer, and expose them through Tab reply selection.
-6. **Stateful memory**: maintain a single evolving Markdown checkpoint representing current shared understanding, including coverage and decision-branch status when useful.
-7. **Automatic checkpointing**: whenever shared understanding changes meaningfully, the assistant must update the checkpoint before asking the next question.
-8. **Read-only during grilling**: while interviewing/planning, the extension blocks implementation mutations. Output selection is a mandatory workflow step before the session can end or output production can begin. Output production is a deliberate approved phase and can temporarily use the tools required for that output.
-
-## User Experience
-
-### Starting
-
-- `/grill <topic>` starts immediately when the topic is clear.
-- `/grill` with no topic uses recent conversation as an inferred topic and asks for confirmation/editing.
-- The default intent is `auto`.
-
-### Interaction
-
-The user interacts through normal chat, not a rigid wizard. The extension adds:
-
-- a persistent active state,
-- a status widget/footer indicator,
-- checkpoint review commands,
-- prompt injection while active,
-- read-only enforcement during the interview, and
-- checkpoint update/output-selection/output-phase tools available to the assistant, and
-- Tab-cyclable suggested replies for each grill question or output-selection choice.
-
-### Commands for v1
-
-- `/grill <topic>`: start or resume a grill session.
-- `/grill stop`: stop grill mode and clear active status.
-- `/grill checkpoint`: review the current Markdown checkpoint; supports quick display and editable review.
-- `/grill status`: show operational state.
-- `/grill intent <auto|plan|learn|research|content|decide>`: set intent preset. Default: `auto`.
-- `/grill output <outputs>`: set one or more output preferences, e.g. `github-issues`, `design-doc`, `readme`, `adr`, `prd`, `summary`, or comma-separated combinations. This preference is never production approval; the assistant still explicitly asks/confirm outputs later.
-- `/grill research <off|ask|auto>`: set research behavior. Default: `auto`.
-
-### Checkpoint
-
-The checkpoint is a single adaptive Markdown document. It should start generic, but sections may be added/removed based on the topic. For thorough grilling, the assistant should maintain a lightweight coverage checklist and decision-branch ledger when useful, marking branches resolved, open, contradicted, or intentionally deferred.
-
-Example sections:
-
-```md
-# Shared Understanding
-
-## Topic
-
-## Current Understanding
-
-## Decisions
-
-## Assumptions
-
-## Constraints
-
-## Risks / Unknowns
-
-## Coverage Checklist
-
-## Decision Branches
-
-## Open Questions
-
-## Likely Output Strategy
-```
-
-The checkpoint should not force every topic into a product-design template. For example, `I want to make a game engine` might become a learning roadmap, an implementation plan, a tutorial series, or a research project depending on the grilled outcome mode.
-
-## Output Model
-
-Output generation is part of the normal `/grill` workflow, not only a separate export command.
-
-When the assistant believes shared understanding is sufficient, it must enter a hardcoded output-selection phase. This phase is mandatory before stopping, stopping without outputs, or producing outputs. The phase shows a readiness gate containing:
-
-1. why it thinks the session is ready,
-2. recommended output destination(s),
-3. recommended output strategy,
-4. an explicit question asking which output(s) to produce, and
-5. choices: continue grilling, review checkpoint, or produce one or more outputs.
-
-There is no default output mode for a grilling session. A missing output preference means no output has been chosen yet. Even when `/grill output` was used, the assistant must explicitly ask/confirm the final output set before output production. The user may choose 1..n outputs, such as both a design doc and uploaded GitHub issues.
-
-Output generation should choose both:
-
-- **destination/format**: explicit options include GitHub issues, design doc, README.md, ADR doc(s), PRD, implementation plan, research brief, summary/decision memo, tutorial/content outline, test plan/QA checklist, and changelog/release notes; one or more destinations may be chosen or customized.
-- **strategy**: implementation vertical slices, tutorial chapters, research investigations, content outline, ADR candidates, milestone experiments, etc.
-
-The output-selection phase should show the explicit destination catalog before asking the user to decide:
-
-- GitHub issues
-- Design doc
-- README.md
-- ADR doc
-- PRD
-- Implementation plan
-- Research brief
-- Summary / decision memo
-- Tutorial / content outline
-- Test plan / QA checklist
-- Changelog / release notes
-
-For example, GitHub issues might mean:
-
-- implementation vertical-slice tickets,
-- tutorial chapter issues,
-- research investigation issues,
-- blog/content installment issues, or
-- prototype experiment milestones.
-
-### Approval Before Mutations
-
-Before writing files or creating issues:
-
-- For file outputs: draft first, then write after approval.
-- For GitHub issues: preview issue titles/bodies/labels first, then create after approval.
-
-During output selection, the user may choose to continue grilling, review the checkpoint, stop without output, or approve one or more concrete outputs. During approved output production, the assistant can enter an output phase that permits the required tools for the job. Approved mutating actions, such as creating GitHub issues, should not be refused merely because they mutate state; if DM, a CLI, a platform, or the OS blocks the mutation for permission/authentication reasons, the assistant must ask the user for the needed permission, confirmation, credentials, or a revised plan instead of bypassing the gate.
-
-For approved GitHub issue output with no git repo or remote, the assistant asks to initialize, create, or select a repo/remote before creating the previewed issues; it uses drafts only if the user chooses.
-
-## Technical Design
-
-### Extension State
-
-Persist state using `dm.appendEntry("grill-me-state", state)`.
-
-State fields:
-
-- `active`: whether grill mode is active.
-- `topic`: current topic.
-- `intent`: `auto | plan | learn | research | content | decide`.
-- `outputPreference`: user-provided output preference(s), if any. Empty means unset; it must not imply a default.
-- `researchMode`: `off | ask | auto`.
-- `checkpoint`: evolving Markdown shared-understanding document.
-- `phase`: `interview | output-selection | output`.
-- `outputPhase`: legacy/compatibility boolean for whether the user has approved output production and mutating tools may be used.
-- `outputSelection`: readiness rationale, recommended outputs, recommended strategy, and output-selection question while the mandatory output-selection phase is active.
-- `approvedOutputPlan`: approved concrete output plan while output phase is active.
-- `currentQuestion`: the latest grill question or output-selection question that has Tab alternatives.
-- `alternatives`: suggested replies exposed in the widget and Tab reply-selection UX.
-- `updatedAt`: last state update timestamp.
-- `lastChangeSummary`: latest checkpoint change summary.
-
-On session start/resume, restore the latest state entry from the current branch.
-
-### Prompt Injection
-
-When active, `before_agent_start` appends grill instructions to the system prompt:
-
-- apply Socratic method,
-- use one thorough default style,
-- ask mostly one question at a time,
-- ask enough follow-up questions to resolve the decision tree instead of rushing to output selection,
-- include 2-5 concrete answer alternatives and a recommended answer by default,
-- call `grill_set_alternatives` before each question so Tab can fill/cycle those alternatives and Enter can send the selected or edited reply,
-- adapt dimensions to topic and intent,
-- maintain coverage checklist and decision-branch status in the checkpoint when useful,
-- inspect code/files instead of asking when research mode allows and the answer is discoverable,
-- do not implement during interview,
-- update checkpoint with `grill_update_checkpoint` before the next question whenever shared understanding changes,
-- when major coverage branches are resolved or intentionally deferred, call `grill_enter_output_selection_phase` to enter the mandatory hardcoded output-selection phase, explicitly list concrete output options (GitHub issues, design doc, README.md, ADR doc, PRD, etc.), ask for one or more outputs/continue/review/stop, and wait for the user's selection,
-- after output approval from that phase, call `grill_enter_output_phase` before using mutating tools,
-- during output phase, perform only approved mutations; if a permission/authentication/tool gate blocks an approved mutation, ask the user for the needed permission, confirmation, credentials, or plan change instead of refusing the approved output or bypassing the gate,
-- for approved GitHub issue output with no git repo or remote, ask to initialize/create/select a repo/remote before creating the previewed issues,
-- if the user continues grilling or stops without output, call `grill_finish_output_selection_phase`.
-
-### Tools
-
-#### `grill_set_alternatives`
-
-Parameters:
-
-- `question`: the question these alternatives answer.
-- `alternatives`: 2-5 objects containing:
-  - `value`: exact reply inserted into the user's editor via Tab reply selection.
-  - `label`: short visible label.
-  - `description`: optional explanation/recommendation note.
-
-Behavior:
-
-- stores the current question and alternatives in state,
-- shows them in the status widget below the editor,
-- exposes them through the active reply-selection editor so pressing Tab fills/cycles them, and
-- does not prevent the user from typing a custom answer.
-
-#### `grill_update_checkpoint`
-
-Parameters:
-
-- `markdown`: full replacement checkpoint Markdown.
-- `changeSummary`: brief visible summary of what changed.
-
-Behavior:
-
-- replaces the stored checkpoint,
-- persists state,
-- displays a visible confirmation,
-- does not terminate the conversation.
-
-#### `grill_enter_output_selection_phase`
-
-Parameters:
-
-- `readinessRationale`: why shared understanding is sufficient to leave interview mode.
-- `recommendedOutputs`: recommended output destination(s)/format(s) from the explicit catalog, or none.
-- `recommendedStrategy`: recommended output strategy, distinct from destination.
-- `question`: the explicit output-selection question.
-- `alternatives`: 2-5 choices for Tab reply selection.
-
-Behavior:
-
-- marks `phase = "output-selection"`,
-- stores the output-selection summary,
-- updates the current question/alternatives,
-- persists state, and
-- makes output selection visible in status/widget.
-
-#### `grill_finish_output_selection_phase`
-
-Parameters:
-
-- `outcome`: `continue-grilling` or `stop-without-output`.
-- `summary`: optional summary of the user's choice.
-
-Behavior:
-
-- resolves the mandatory output-selection phase without entering output production,
-- either returns to `interview` or stops Grill Me after a no-output choice,
-- persists state, and
-- clears the output-selection alternatives.
-
-#### `grill_enter_output_phase`
-
-Parameters:
-
-- `outputPlan`: description of approved outputs and planned mutations.
-
-Behavior:
-
-- requires the mandatory `output-selection` phase first,
-- marks `phase = "output"` and `outputPhase = true` for the approved 1..n output plan,
-- persists state,
-- displays that output tools are enabled, and
-- instructs the assistant to ask the user for permission/authentication if an approved mutation is blocked by DM, a CLI, a platform, or the OS.
-
-#### `grill_finish_output_phase`
-
-Behavior:
-
-- marks `outputPhase = false`,
-- returns to read-only grill enforcement.
-
-### Read-only Enforcement
-
-While `active && !outputPhase`:
-
-- block `edit` and `write`,
-- block bash commands that appear mutating,
-- allow read/search/inspection commands,
-- allow checkpoint/output-selection/output-phase tools.
-
-When `outputPhase` is true, the assistant may use tools required for the approved output step. If an approved mutation is blocked by permissions, auth, or missing repo setup, it asks the user for permission, credentials, repo selection, or a revised plan instead of bypassing the gate, claiming success, or defaulting to drafts.
-
-## MVP Scope
-
-The first working version implements:
-
-- stateful `/grill` command,
-- config commands for intent, research behavior, and output preference,
-- prompt injection,
-- persistent Markdown checkpoint,
-- `grill_update_checkpoint`,
-- checkpoint review/editing,
-- Tab reply-selection alternatives for each question,
-- read-only enforcement during interview,
-- mandatory output-selection tools,
-- output-phase tool for approved output production,
-- status widget.
-
-## Known Limitations / Future Work
-
-- Automatic checkpoint quality depends on the model following tool-use instructions.
-- Output-selection is now a typed phase, but output strategies are still free-text rather than separate structured strategy objects.
-- GitHub issue creation is not wrapped by a dedicated tool yet; the assistant uses `gh` during approved output phase.
-- Later versions could add richer structured state, custom strategy templates, issue-preview tools, and automatic diffing of checkpoint changes.

package/extensions/dm-grill-me/README.md

@@ -1,82 +0,0 @@
-# DM Grill Me
-
-A DM extension for thorough Socratic planning sessions and DM Deep Interview intake. It keeps a shared-understanding checkpoint, asks one focused question at a time, tracks coverage and decision branches, offers Tab-cyclable answer alternatives, forces a mandatory output-selection phase at the end of the interview, and blocks implementation mutations until output production is explicitly approved.
-
-## Install
-
-DM bundles `dm-grill-me` with the published CLI. Install or upgrade `dm`, then use `/deep-interview`, `/grill`, or `/checkpoint` in the TUI. For local source development, run `dm -e /path/to/dm-grill-me`.
-
-## Commands
-
-- `/deep-interview <topic>` — start the DM Deep Interview workflow. This is an alias for the same protected Grill Me interview engine.
-- `/grill <topic>` — start a grill session.
-- `/grill` — infer the topic from the current conversation and ask for confirmation/editing.
-- `/grill stop` — stop grill mode.
-- `/checkpoint [edit|chat]` — show the current checkpoint in an overlay by default; use `edit` to edit or `chat` to print it.
-- `/grill checkpoint [edit|chat]` — same checkpoint controls from the `/grill` command.
-- `/grill status` — show current grill state.
-- `/grill intent auto|plan|learn|research|content|decide` — set the intent preset.
-- `/grill output <outputs>` — set one or more preferred output formats, such as `github-issues`, `design-doc`, `readme`, `adr`, `prd`, `summary`, or `design-doc,github-issues`. This is a preference only; Grill Me still explicitly asks/gets approval before producing outputs.
-- `/grill research off|ask|auto` — configure whether the assistant should inspect/research while grilling.
-
-## Behavior
-
-While active, the extension injects Grill Me instructions into the agent context and exposes these assistant tools:
-
-- `grill_set_alternatives`
-- `grill_update_checkpoint`
-- `grill_enter_output_selection_phase`
-- `grill_finish_output_selection_phase`
-- `grill_enter_output_phase`
-- `grill_finish_output_phase`
-
-During interview mode it blocks `edit`, `write`, and bash commands that appear mutating. Grill Me uses one thorough default grilling style. The assistant is instructed to maintain a coverage checklist, clarity ledger, and decision-branch ledger in the checkpoint, ask enough follow-up questions to resolve or intentionally defer major branches, route repo/docs facts to read-only inspection while asking the user for judgments, and avoid premature readiness. Before ending the interview it must run a pressure pass over assumptions, risks, and unresolved branches. Grill Me does not assume a default output mode; when the interview is ready to end, the assistant must enter the hardcoded output-selection phase, ask which output(s) to produce, and support one or many outputs, such as a design doc and uploaded GitHub issues. Output production can only start after the user approves a concrete plan from that selection phase; choosing to continue grilling or stop without output is recorded separately.
-
-## Tab reply selection
-
-When Grill Me alternatives are active, `Tab` fills the editor with a suggested reply and repeated `Tab` cycles through the available replies. `Shift+Tab` cycles backward. Press `Enter` to send the selected reply, or edit the inserted text before pressing `Enter` to send a custom answer. If you type a short filter first, `Tab` selects the first matching alternative; free-form text is left alone.
-
-## Output selection options
-
-The mandatory output-selection phase explicitly names concrete artifact options, including:
-
-- GitHub issues
-- Design doc
-- README.md
-- ADR doc
-- PRD
-- Implementation plan
-- Research brief
-- Summary / decision memo
-- Tutorial / content outline
-- Test plan / QA checklist
-- Changelog / release notes
-
-The user can choose one, choose multiple, customize the set, continue grilling, review the checkpoint, or stop without producing output.
-
-## Permissions and mutating outputs
-
-Grill Me remains read-only until the user approves a concrete output plan and the assistant enters output phase. During output phase, approved mutating actions such as writing files or creating GitHub issues are allowed, but only within the approved plan. If DM, GitHub CLI, the OS, or another tool blocks an approved mutation because it needs permission, confirmation, authentication, or credentials, the assistant should stop and ask the user for that permission or a revised plan instead of bypassing the gate or pretending the action succeeded.
-
-For approved GitHub issue output with no git repo or remote, the assistant asks to initialize, create, or select a repo/remote before creating the previewed issues; it falls back to drafts only if the user chooses.
-
-## Acknowledgements
-
-Kudos to [Matt Pocock](https://github.com/mattpocock) for the idea that inspired this extension.
-
-## Testing
-
-This package currently has no npm scripts. Useful checks:
-
-```bash
-npm pack --dry-run
-tsc --noEmit --target ES2022 --module NodeNext --moduleResolution NodeNext --skipLibCheck index.ts
-```
-
-The TypeScript check requires DM peer dependencies to be resolvable in the local environment.
-
-See [DESIGN.md](./DESIGN.md) for the design notes.
-
-## License
-
-This source is available under the [MIT License](./LICENSE).

package/extensions/dm-grill-me/tsconfig.json

@@ -1,17 +0,0 @@
-{
-  "compilerOptions": {
-    "target": "ES2022",
-    "module": "NodeNext",
-    "moduleResolution": "NodeNext",
-    "strict": false,
-    "noEmit": true,
-    "allowImportingTsExtensions": true,
-    "skipLibCheck": true,
-    "types": [
-      "node"
-    ]
-  },
-  "include": [
-    "index.ts"
-  ]
-}

package/extensions/dm-image2/README.md

@@ -1,33 +0,0 @@
-# dm-image2
-
-Local bundled DM extension that exposes a dedicated `image_generation` tool.
-
-What it does:
-
-- vendors the `imagen.py` lane from M inside the DM package
-- uses the active DM Ultradex / Codex account via a generated auth shim
-- runs the bundled `imagen.py` orchestrator as the primary image lane
-- bundles a pattern-only image prompt cookbook in `skills/image-generation/SKILL.md`, distilled from public prompt/reference case patterns, without calling third-party image APIs or external skill archives
-- fails closed by default if `imagen.py` cannot run with a healthy credential source, so DM does not silently mask the required tool path
-- keeps the image-generation workflow saved-to-disk instead of dumping raw image data inline
-- returns the saved path plus an inline PNG preview in the TUI
-- cooperates with DM abort signals so `Esc` / `Ctrl+C` can stop long image runs cleanly
-
-Default save behavior:
-
-- `save=project` → `<cwd>/.dm/generated-images/`
-- `save=global` → `~/.dm/agent/generated-images/`
-- `save=custom` → `saveDir`
-
-This is a practical DM wrapper lane for image artifacts. It now uses the bundled `imagen.py` orchestrator from M as the required default PNG path so DM calls the same image-first tool family the operator requested.
-
-Pattern skill note:
-
-- `dm-image2` does not depend on external image-generation skill archives
-- prompt patterns live directly in `skills/image-generation/SKILL.md`
-- the skill teaches reusable visual workflows only; generation still happens through DM's `image_generation` tool and active DM credentials
-
-Legacy fallback note:
-
-- emergency-only debugging can opt into the older fallback lane with `DM_IMAGE_ALLOW_LEGACY_FALLBACK=1`
-- the default behavior is intentionally strict so REQUESTS evidence is about the real `imagen.py` lane, not a masked fallback