deepmodel-dmx 0.3.2__tar.gz → 0.3.4__tar.gz

{deepmodel_dmx-0.3.2 → deepmodel_dmx-0.3.4}/CHANGELOG.md

@@ -7,6 +7,25 @@ Versioning follows [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
 ---
 
+## [Unreleased]
+
+## [0.3.4] — 2026-09-08
+
+### Fixed
+
+- Loop run state (`.dmx/jobs/{job_id}/*.json`) and the session-note breadcrumb `_finish_loop` writes to `activeContext.md` are now committed once a loop run genuinely finishes (not `paused`/`iterating`), instead of being left as an uncommitted, local-only change — matching the README's documented "committed with the PR" contract for `jobs/`. This mattered most for the bundled `release` loop, which has no `on_complete` chain target: nothing downstream ran to commit its final state, and `close-ticket` explicitly makes no `.dmx/` changes before force-deleting the branch, so the loop's own "complete" outcome was silently and permanently lost every time. Silent no-op outside a git repo or when there's nothing to commit; if a commit is attempted but fails (e.g. rejected by a pre-commit hook), the loop's own response now surfaces a warning instead of only logging it server-side, and every git call is timeout-bounded so a hung `git commit` (e.g. waiting on a GPG passphrase) can't hang the whole MCP tool call. (GH-23)
+- `close-ticket` no longer transitions the ticket to Done/Complete (or adds the "PR merged" comment) unless Step 4 actually found a merged PR for the branch — previously the transition step ran unconditionally, so running `/dmx/close-ticket` while a PR was still open could mark the ticket Done before the code had actually merged. Also hardened the transition itself to treat an already-terminal ticket/issue as a no-op success rather than an error (idempotent for `github-issues`' auto-close-via-`Closes #N`, and for Jira setups where a GitHub↔Jira integration already auto-transitioned the ticket). (GH-21)
+- `draft-release-note` now commits and pushes `.dmx/releases/{version}.md` after writing it, instead of leaving it as an uncommitted local file. `release-merge` opens its PR straight from `{branch_base}`'s pushed state, so the release notes file was previously silently absent from that PR's diff whenever it hadn't been committed by hand first. Re-running it against unchanged content (nothing new merged) is a no-op rather than failing on "nothing to commit". (GH-22)
+- Starting the `spec` loop, or running `/dmx/create-ticket` manually, on a repository with zero commits now surfaces a clear, actionable error instead of a confusing one. Previously, `current_branch()` (which shells out to `git rev-parse --abbrev-ref HEAD`) silently returned `None` on a freshly `git init`'d repo's unborn `HEAD`, causing the `spec` loop's branch guard to fail with a generic "could not determine the current git branch" message — even though the branch name itself was perfectly resolvable. `_branch_guard_error` now distinguishes this specific case and tells the user to commit and push before retrying. `dmx-create-ticket.md` gained the same check as its new Step 2, so manual/foreground usage fails fast before creating a ticket or attempting to branch, rather than failing later when GitHub's `create_branch` API rejects branching from a ref-less remote. (GH-19)
+
+## [0.3.3] — 2026-09-02
+
+### Fixed
+
+- The bundled `release` loop no longer runs `update-memory` after `create-pr` has already opened the PR — `create-pr` already performs its own memory-bank sync and commit (Steps 4-5), so chaining `update-memory` immediately after left its edits (further inbox promotions, `activeContext.md` rewrites) as dangling uncommitted changes never included in the PR, and silently discarded later by `close-ticket`'s branch deletion. `release.yaml` now runs `create-pr` only.
+- `update-memory` now commits its own changes at the end of its instructions, so it can never leave dangling uncommitted `.dmx/` state regardless of when or how it's invoked in the future.
+- `check_pr_ready`'s `memory_updated` check now fails if `.dmx/` has any uncommitted changes (staged or not), instead of only checking the latest commit or the mere existence of `activeContext.md` — a loop-config ordering mistake now surfaces loudly instead of silently passing. (GH-15)
+
 ## [0.3.2] — 2026-08-31
 
 ### Fixed

{deepmodel_dmx-0.3.2 → deepmodel_dmx-0.3.4}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: deepmodel-dmx
-Version: 0.3.2
+Version: 0.3.4
 Summary: AI SDLC MCP server — skills and rules for any AI IDE.
 License: AGPL-3.0
 License-File: LICENSE
@@ -90,7 +90,7 @@ Bundled loops for the SDLC pipeline:
 | `plan` | plan | `dev` |
 | `dev` | implement-next-phase, commit | `validate` |
 | `validate` | validate | `release` |
-| `release` | create-pr, update-memory | — |
+| `release` | create-pr | — |
 
 Each loop config defines a goal state, optional `repeat_until` condition, validators, human gate policy, and `on_complete` chaining. Run state is written to `.dmx/jobs/{job_id}/{loop_name}-{task_id}.json` — there's no separate active-run pointer; the active run is derived by scanning a job's state files for the one non-terminal (`pending`/`running`/`paused`/`iterating`) entry, keyed off the current branch/ticket. This keeps loop state isolated per branch: pausing work on one branch and running a loop on another can't corrupt or lose either one's state.
 
@@ -121,12 +121,111 @@ Loop-level memory hooks: before the first skill runs, the runtime surfaces `acti
 }
 ```
 
-Add to your IDE config ([Claude Code, Copilot, Antigravity ↓](#step-1--add-the-mcp-server)). Run `/dmx/init` once per project. Then:
+Add to your IDE config ([Claude Code, Copilot, Antigravity ↓](#step-1--add-the-mcp-server)). Then follow [Your first project](#your-first-project) to initialize and run the full loop on a new repo.
+
+## Your first project
+
+A brand-new repo, from `/dmx/init` through the first merged PR. You review at every gate; `/dmx/loop-continue` is how you move forward.
+
+### Before you start
+
+- A GitHub repo cloned locally with an `origin` remote. The spec loop creates the feature branch on GitHub from `origin/{branch_base}` (usually `main` or `master`), even if you track work in Jira or use no ticketing system.
+- The dmx MCP server added to your IDE ([install guide](#step-1--add-the-mcp-server)).
+- The GitHub MCP server (`user-github`) authenticated. `/dmx/init` probes it before writing any files.
+- The Atlassian MCP server only if you will choose Jira at init.
+
+### 1. Initialize
+
+On the integration branch (`main` or `master`):
 
 ```
-/dmx/create-ticket
+/dmx/init
 ```
 
+Choose a workflow — **sdlc** (this walkthrough) or **freestyle** (no process enforced) — and a ticketing system: `none`, `github-issues`, or `jira`. Re-run `/dmx/init` at any time to switch workflow or ticketing; existing memory bank files with content are left intact.
+
+Init writes `.dmx/config.md` and the memory bank (`projectbrief.md`, `productContext.md`, `systemPatterns.md`, `techContext.md`, `activeContext.md`). Open a **new chat** so the IDE rules take effect.
+
+If you already have a `docs/` folder, init reads it when populating the memory bank. Writing the requirement first is slightly better; either order works.
+
+### 2. Write the product requirement
+
+Create `docs/requirements.md` at the repo root and put the product or feature description there. You can paste the requirement into chat later instead, but a file is easier to review and reuse.
+
+`docs/requirements.md` is a convention, not a dmx artifact. The spec loop uses whatever you point it at.
+
+### 3. Commit and push
+
+The spec loop must start from the configured integration branch, and it creates the remote feature branch from whatever is already on origin. Commit `.dmx/`, `docs/`, and any files init wrote, then push:
+
+```
+git add .
+git commit -m "chore: initialize dmx and capture product requirements"
+git push -u origin HEAD
+```
+
+Stay on `main` or `master`.
+
+### 4. Start the spec loop
+
+In the same message as the command, point at the requirement file or paste it:
+
+```
+/dmx/run-loop spec
+
+See docs/requirements.md
+```
+
+This creates a GitHub issue or Jira ticket (if you configured one), cuts a feature branch from `origin/{branch_base}`, checks it out, and writes `.dmx/spec.md`. Then it pauses.
+
+### 5. Answer the spec
+
+Open `.dmx/spec.md`. Fill in Technical Approach if it is incomplete, and answer every question. Empty answers or placeholders (`TBD`, `TODO`) fail the spec validator.
+
+```
+/dmx/loop-continue
+```
+
+On success the runtime auto-chains to the `plan` loop.
+
+### 6. Review the plan
+
+`plan` writes `.dmx/tasks.md` with phases and tasks, then pauses. Edit freely — this is the implementation contract.
+
+```
+/dmx/loop-continue
+```
+
+That starts the `dev` loop.
+
+### 7. Build phase by phase
+
+Each `dev` cycle:
+
+1. Implements the next unchecked phase in `tasks.md`, then pauses.
+2. Review the diff.
+3. `/dmx/loop-continue` runs **commit only**. It does not push.
+4. Review the commit.
+5. `/dmx/loop-continue` again — validators run, then either the next phase starts or the loop chains to `validate`.
+
+Repeat until every phase is checked off.
+
+### 8. Validate and open the PR
+
+After the last phase, `validate` runs the quality gate and pauses. Review the report, then `/dmx/loop-continue`. On success the `release` loop runs `create-pr`: it pushes the feature branch and opens the pull request.
+
+### 9. Merge and close
+
+Review the PR and merge it. Then:
+
+```
+/dmx/close-ticket
+```
+
+That closes the ticket, comments the PR link, and deletes the feature branch locally and on origin. `/dmx/loop-continue` after merge is not a close path — the release loop ends when the PR exists.
+
+You can run the same steps by hand (`/dmx/create-ticket`, `/dmx/plan`, `/dmx/implement-next-phase`, …) instead of loops. See the skill catalog below.
+
 ## Learn more
 
 - [When Is a Loop Ready to Run Without You?](https://himakara.hashnode.dev/when-is-a-loop-ready-to-run-without-you) — the thinking behind dmx
@@ -208,6 +307,10 @@ Safe to re-run. Updates config without overwriting memory bank files that alread
 
 ### Step 3 — Start your first ticket
 
+On a new repo, follow [Your first project](#your-first-project) (`/dmx/run-loop spec` through `/dmx/close-ticket`).
+
+To start a ticket by hand instead:
+
 ```
 /dmx/create-ticket
 ```

{deepmodel_dmx-0.3.2 → deepmodel_dmx-0.3.4}/README.md

@@ -55,7 +55,7 @@ Bundled loops for the SDLC pipeline:
 | `plan` | plan | `dev` |
 | `dev` | implement-next-phase, commit | `validate` |
 | `validate` | validate | `release` |
-| `release` | create-pr, update-memory | — |
+| `release` | create-pr | — |
 
 Each loop config defines a goal state, optional `repeat_until` condition, validators, human gate policy, and `on_complete` chaining. Run state is written to `.dmx/jobs/{job_id}/{loop_name}-{task_id}.json` — there's no separate active-run pointer; the active run is derived by scanning a job's state files for the one non-terminal (`pending`/`running`/`paused`/`iterating`) entry, keyed off the current branch/ticket. This keeps loop state isolated per branch: pausing work on one branch and running a loop on another can't corrupt or lose either one's state.
 
@@ -86,12 +86,111 @@ Loop-level memory hooks: before the first skill runs, the runtime surfaces `acti
 }
 ```
 
-Add to your IDE config ([Claude Code, Copilot, Antigravity ↓](#step-1--add-the-mcp-server)). Run `/dmx/init` once per project. Then:
+Add to your IDE config ([Claude Code, Copilot, Antigravity ↓](#step-1--add-the-mcp-server)). Then follow [Your first project](#your-first-project) to initialize and run the full loop on a new repo.
+
+## Your first project
+
+A brand-new repo, from `/dmx/init` through the first merged PR. You review at every gate; `/dmx/loop-continue` is how you move forward.
+
+### Before you start
+
+- A GitHub repo cloned locally with an `origin` remote. The spec loop creates the feature branch on GitHub from `origin/{branch_base}` (usually `main` or `master`), even if you track work in Jira or use no ticketing system.
+- The dmx MCP server added to your IDE ([install guide](#step-1--add-the-mcp-server)).
+- The GitHub MCP server (`user-github`) authenticated. `/dmx/init` probes it before writing any files.
+- The Atlassian MCP server only if you will choose Jira at init.
+
+### 1. Initialize
+
+On the integration branch (`main` or `master`):
 
 ```
-/dmx/create-ticket
+/dmx/init
 ```
 
+Choose a workflow — **sdlc** (this walkthrough) or **freestyle** (no process enforced) — and a ticketing system: `none`, `github-issues`, or `jira`. Re-run `/dmx/init` at any time to switch workflow or ticketing; existing memory bank files with content are left intact.
+
+Init writes `.dmx/config.md` and the memory bank (`projectbrief.md`, `productContext.md`, `systemPatterns.md`, `techContext.md`, `activeContext.md`). Open a **new chat** so the IDE rules take effect.
+
+If you already have a `docs/` folder, init reads it when populating the memory bank. Writing the requirement first is slightly better; either order works.
+
+### 2. Write the product requirement
+
+Create `docs/requirements.md` at the repo root and put the product or feature description there. You can paste the requirement into chat later instead, but a file is easier to review and reuse.
+
+`docs/requirements.md` is a convention, not a dmx artifact. The spec loop uses whatever you point it at.
+
+### 3. Commit and push
+
+The spec loop must start from the configured integration branch, and it creates the remote feature branch from whatever is already on origin. Commit `.dmx/`, `docs/`, and any files init wrote, then push:
+
+```
+git add .
+git commit -m "chore: initialize dmx and capture product requirements"
+git push -u origin HEAD
+```
+
+Stay on `main` or `master`.
+
+### 4. Start the spec loop
+
+In the same message as the command, point at the requirement file or paste it:
+
+```
+/dmx/run-loop spec
+
+See docs/requirements.md
+```
+
+This creates a GitHub issue or Jira ticket (if you configured one), cuts a feature branch from `origin/{branch_base}`, checks it out, and writes `.dmx/spec.md`. Then it pauses.
+
+### 5. Answer the spec
+
+Open `.dmx/spec.md`. Fill in Technical Approach if it is incomplete, and answer every question. Empty answers or placeholders (`TBD`, `TODO`) fail the spec validator.
+
+```
+/dmx/loop-continue
+```
+
+On success the runtime auto-chains to the `plan` loop.
+
+### 6. Review the plan
+
+`plan` writes `.dmx/tasks.md` with phases and tasks, then pauses. Edit freely — this is the implementation contract.
+
+```
+/dmx/loop-continue
+```
+
+That starts the `dev` loop.
+
+### 7. Build phase by phase
+
+Each `dev` cycle:
+
+1. Implements the next unchecked phase in `tasks.md`, then pauses.
+2. Review the diff.
+3. `/dmx/loop-continue` runs **commit only**. It does not push.
+4. Review the commit.
+5. `/dmx/loop-continue` again — validators run, then either the next phase starts or the loop chains to `validate`.
+
+Repeat until every phase is checked off.
+
+### 8. Validate and open the PR
+
+After the last phase, `validate` runs the quality gate and pauses. Review the report, then `/dmx/loop-continue`. On success the `release` loop runs `create-pr`: it pushes the feature branch and opens the pull request.
+
+### 9. Merge and close
+
+Review the PR and merge it. Then:
+
+```
+/dmx/close-ticket
+```
+
+That closes the ticket, comments the PR link, and deletes the feature branch locally and on origin. `/dmx/loop-continue` after merge is not a close path — the release loop ends when the PR exists.
+
+You can run the same steps by hand (`/dmx/create-ticket`, `/dmx/plan`, `/dmx/implement-next-phase`, …) instead of loops. See the skill catalog below.
+
 ## Learn more
 
 - [When Is a Loop Ready to Run Without You?](https://himakara.hashnode.dev/when-is-a-loop-ready-to-run-without-you) — the thinking behind dmx
@@ -173,6 +272,10 @@ Safe to re-run. Updates config without overwriting memory bank files that alread
 
 ### Step 3 — Start your first ticket
 
+On a new repo, follow [Your first project](#your-first-project) (`/dmx/run-loop spec` through `/dmx/close-ticket`).
+
+To start a ticket by hand instead:
+
 ```
 /dmx/create-ticket
 ```

{deepmodel_dmx-0.3.2 → deepmodel_dmx-0.3.4}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "hatchling.build"
 
 [project]
 name = "deepmodel-dmx"
-version = "0.3.2"
+version = "0.3.4"
 description = "AI SDLC MCP server — skills and rules for any AI IDE."
 readme = "README.md"
 requires-python = ">=3.11"

{deepmodel_dmx-0.3.2 → deepmodel_dmx-0.3.4}/src/dmx/loop_tools.py

@@ -40,6 +40,7 @@ from __future__ import annotations
 import importlib.resources as pkg
 import logging
 import re
+import subprocess
 from pathlib import Path
 
 from fastmcp import (
@@ -150,6 +151,41 @@ def _read_branch_base(workspace_root: Path) -> str | None:
     return value if value and value != "{REQUIRED}" else None
 
 
+def _repo_has_no_commits(root: Path) -> bool:
+    """True if *root* is a git repo with an unborn HEAD (zero commits).
+
+    ``git rev-parse --abbrev-ref HEAD`` — what :func:`current_branch` uses —
+    fails on a freshly ``git init``'d repo before its first commit, even
+    though the branch name (e.g. ``main``/``master``) is perfectly
+    resolvable via ``git symbolic-ref``. This distinguishes that specific,
+    fixable case (make a commit) from other reasons ``current_branch``
+    might return ``None`` (not a git repo at all, detached HEAD, etc.),
+    which don't have an actionable one-line fix.
+    """
+    try:
+        result = subprocess.run(
+            ["git", "rev-parse", "--is-inside-work-tree"],
+            capture_output=True,
+            text=True,
+            cwd=root,
+        )
+    except Exception:  # noqa: BLE001
+        return False
+    if result.returncode != 0 or result.stdout.strip() != "true":
+        return False  # not a git repo at all — a different problem
+
+    try:
+        verify = subprocess.run(
+            ["git", "rev-parse", "--verify", "--quiet", "HEAD"],
+            capture_output=True,
+            text=True,
+            cwd=root,
+        )
+    except Exception:  # noqa: BLE001
+        return False
+    return verify.returncode != 0
+
+
 def _branch_guard_error(root: Path, config: LoopConfig) -> str | None:
     """Return an error message if *config* declares ``require_branch`` and
     the current branch doesn't satisfy it, else None."""
@@ -166,6 +202,13 @@ def _branch_guard_error(root: Path, config: LoopConfig) -> str | None:
 
     branch = current_branch(root)
     if branch is None:
+        if _repo_has_no_commits(root):
+            return (
+                f"Cannot start the `{config.name}` loop: this repository has no commits yet. "
+                f"`{config.name}` creates a new branch from `{branch_base}` on GitHub, which "
+                "requires at least one commit to exist first. Commit something (e.g. the "
+                "`.dmx/` files `/dmx/init` just wrote) and push to origin, then try again."
+            )
         return (
             f"Cannot start the `{config.name}` loop: could not determine the current git "
             f"branch. Make sure you're in a git repository checked out to `{branch_base}`."
@@ -451,6 +494,79 @@ def _start_loop(root: Path, name: str, description: str | None = None) -> str:
 # ---------------------------------------------------------------------------
 
 
+_COMMIT_DMX_STATE_TIMEOUT_SECONDS = 15
+
+
+def _commit_dmx_state(root: Path, message: str) -> str | None:
+    """Best-effort commit of any uncommitted ``.dmx/`` changes.
+
+    Called once a loop run has genuinely finished (a terminal outcome —
+    not ``paused``/``iterating``, which will write state again on the next
+    call) so its final state — the job's state JSON and the session-note
+    breadcrumb ``_finish_loop`` just wrote to ``activeContext.md`` — isn't
+    left as an uncommitted, local-only change. This matters most for a
+    loop with no ``on_complete`` chain target (e.g. the bundled ``release``
+    loop): nothing downstream runs to commit on its behalf, and
+    ``close-ticket`` explicitly makes no ``.dmx/`` changes before
+    force-deleting the branch, so an uncommitted final state here would be
+    silently and permanently lost — see GH-23.
+
+    Silently does nothing if *root* isn't a git repo or there's nothing to
+    commit — this is a best-effort durability improvement (matching the
+    README's "committed with the PR" claim for ``.dmx/jobs/``), not
+    something that should ever break a loop response.
+
+    Every subprocess call is timeout-bounded so a hung ``git`` invocation
+    (e.g. a pre-commit hook prompting for input, or GPG signing waiting on
+    a passphrase) can't hang the whole MCP tool call indefinitely.
+
+    Returns:
+        ``None`` if there was nothing to commit or the commit succeeded.
+        A short, user-facing warning string if a commit was *attempted*
+        but failed (e.g. a pre-commit hook rejected it) — silently
+        swallowing that would defeat the entire point of this call, so
+        callers should surface it in the loop's response rather than only
+        logging it server-side.
+    """
+    try:
+        status = subprocess.run(
+            ["git", "status", "--short", "--", ".dmx/"],
+            capture_output=True,
+            text=True,
+            cwd=root,
+            timeout=_COMMIT_DMX_STATE_TIMEOUT_SECONDS,
+        )
+    except Exception:  # noqa: BLE001
+        return None
+    if status.returncode != 0 or not status.stdout.strip():
+        return None  # not a git repo, or nothing under .dmx/ to commit
+
+    try:
+        subprocess.run(
+            ["git", "add", ".dmx/"],
+            capture_output=True,
+            text=True,
+            cwd=root,
+            check=True,
+            timeout=_COMMIT_DMX_STATE_TIMEOUT_SECONDS,
+        )
+        subprocess.run(
+            ["git", "commit", "-m", message],
+            capture_output=True,
+            text=True,
+            cwd=root,
+            check=True,
+            timeout=_COMMIT_DMX_STATE_TIMEOUT_SECONDS,
+        )
+    except Exception as exc:  # noqa: BLE001
+        logger.warning("could not auto-commit .dmx/ state (%s): %s", message, exc)
+        return (
+            "⚠️ Could not auto-commit the loop's final `.dmx/` state (see server logs for "
+            "details) — run `git status .dmx/` and commit manually if needed."
+        )
+    return None
+
+
 def _finish_loop(
     root: Path,
     job_id: str,
@@ -571,25 +687,42 @@ def _finish_loop(
                 f"{loop_name} loop completed (outcome: {outcome}) — chaining to "
                 f"{next_loop} was configured but blocked: {chain_guard_error}",
             )
-            return (
+            commit_warning = _commit_dmx_state(
+                root, f"chore: sync loop state for {loop_name} (job {job_id})"
+            )
+            message = (
                 f"{_complete_message(loop_name, job_id, outcome)}\n\n"
                 f"Configured to chain to **{next_loop}**, but it couldn't start: "
                 f"{chain_guard_error}"
             )
+            if commit_warning:
+                message += f"\n\n{commit_warning}"
+            return message
 
         append_session_note(
             root,
             f"{loop_name} loop completed (outcome: {outcome}) — "
             f"chained to {next_loop} (job `{job_id}`).",
         )
+        commit_warning = _commit_dmx_state(
+            root, f"chore: sync loop state for {loop_name} (job {job_id})"
+        )
         chain_header = (
             f"**{loop_name} loop — complete** (outcome: `{outcome}`)\n\n"
             f"Chaining automatically to **{next_loop}** loop.\n\n"
         )
+        if commit_warning:
+            chain_header += f"{commit_warning}\n\n"
         return chain_header + _start_loop(root, next_loop)
 
     append_session_note(root, f"{loop_name} loop completed (outcome: {outcome}) (job `{job_id}`).")
-    return _complete_message(loop_name, job_id, outcome)
+    commit_warning = _commit_dmx_state(
+        root, f"chore: sync loop state for {loop_name} (job {job_id})"
+    )
+    message = _complete_message(loop_name, job_id, outcome)
+    if commit_warning:
+        message += f"\n\n{commit_warning}"
+    return message
 
 
 # ---------------------------------------------------------------------------

{deepmodel_dmx-0.3.2 → deepmodel_dmx-0.3.4}/src/dmx/loops/release.yaml

@@ -1,7 +1,6 @@
 name: release
 skills:
   - create-pr
-  - update-memory
 trigger:
   type: on_complete
 goal_state: "PR created, ticket transitioned to review, memory bank updated"

{deepmodel_dmx-0.3.2 → deepmodel_dmx-0.3.4}/src/dmx/skills/utility/dmx-update-memory.md

@@ -85,7 +85,27 @@ After promoting inbox items, rewrite `activeContext.md` to the learning-inbox st
 
 Do not add an `## Active Ticket` section. Branch identity lives in `spec.md`, not here.
 
-## Step 6 — Return the result
+## Step 6 — Commit memory changes
+
+Run:
+```
+git status --short .dmx/
+```
+
+If any files under `.dmx/` were modified in Steps 4–5:
+```
+git add .dmx/
+git commit -m "chore: sync memory bank"
+```
+
+If nothing changed, continue without committing.
+
+This skill must never leave uncommitted `.dmx/` changes in the working tree —
+regardless of when or how it's invoked (standalone, chained after another
+skill, or as part of a loop), it is responsible for committing its own edits.
+Do not skip this step even if you expect the caller to commit afterward.
+
+## Step 7 — Return the result
 
 Output:
 ```
@@ -101,6 +121,8 @@ activeContext inbox:
   Promoted: {N} items
   Remaining: {M} items
 
+{if committed in Step 6} Committed: chore: sync memory bank
+
 Next:
   - Run /dmx/create-ticket to start the next piece of work.
   - Run /dmx/derive-ticket if you have uncommitted changes to formalise.
@@ -112,3 +134,4 @@ Next:
 - Never store ticket-specific implementation details (function names, line numbers, single-branch decisions) in core files. Those belong in `spec.md` or `tasks.md`.
 - If `tasks.md` shows unchecked tasks remaining, note in output: "Note: tasks.md has unchecked tasks — memory updated with progress so far, not a completed state."
 - After Step 5, `activeContext.md` must not contain an `## Active Ticket` section.
+- Never leave `.dmx/` changes uncommitted — Step 6 is mandatory whenever files were modified.

{deepmodel_dmx-0.3.2 → deepmodel_dmx-0.3.4}/src/dmx/skills/workflow/1-triage/dmx-create-ticket.md

@@ -28,7 +28,29 @@ The project configuration is injected into your context as a rule. Extract:
 
 If configuration is not available in context, fall back to reading `.dmx/config.md`. If neither is found, stop: "Project configuration not found. Run /dmx/init to set up this project."
 
-## Step 2 — Read project context
+## Step 2 — Verify the repo has at least one commit
+
+Run:
+```
+git rev-parse --verify --quiet HEAD
+```
+
+If this fails (non-zero exit, no output — an unborn `HEAD`, meaning zero commits exist yet), stop before creating anything:
+```
+This repository has no commits yet. Creating a ticket branches from `{config.branch_base}`
+on GitHub, which requires at least one commit to exist first.
+
+Commit something first, e.g. the files /dmx/init just wrote:
+  git add .
+  git commit -m "chore: initialize project"
+  git push -u origin HEAD
+
+Then run /dmx/create-ticket again.
+```
+
+Do not proceed to Step 3 in this case, even if `{{task}}` was provided.
+
+## Step 3 — Read project context
 
 Read the following memory bank files:
 - `.dmx/projectbrief.md` — project goals and scope
@@ -39,7 +61,7 @@ If `.dmx/` does not exist, stop: "Memory bank not found. Run /dmx/init to set up
 
 Store this context. It will inform the ticket content, technical approach, and spec questions.
 
-## Step 3 — Infer type
+## Step 4 — Infer type
 
 If `{{type}}` was provided, use it. Accepted values: `feature`, `bug`, `chore`.
 
@@ -53,9 +75,9 @@ Store as `branch_type` (`feature` | `bug` | `chore`).
 For Jira `issueTypeName` mapping: `feature` → `Story`, `bug` → `Bug`, `chore` → `Task`.
 For GitHub Issues label: use `branch_type` as-is.
 
-## Step 4 — Draft ticket content
+## Step 5 — Draft ticket content
 
-Using `{{task}}` and the project context from Step 2, generate a `summary` and `description`.
+Using `{{task}}` and the project context from Step 3, generate a `summary` and `description`.
 
 ### Summary
 Single sentence, max 80 characters, imperative present tense, capital first letter, no trailing period. Specific enough that scope is clear without reading the description.
@@ -86,7 +108,7 @@ Examples:
 
 Rules: write for the implementer. For bugs, lead with observed vs expected behaviour. Acceptance criteria must be independently verifiable.
 
-## Step 5 — Create the ticket
+## Step 6 — Create the ticket
 
 **If `ticketing` is `jira`:**
 
@@ -96,7 +118,7 @@ Call `createJiraIssue` on `user-atlassian`:
 ```
 cloudId:              {config.cloud_id}
 projectKey:           {config.project_key}
-issueTypeName:        {Jira type from Step 3}
+issueTypeName:        {Jira type from Step 4}
 summary:              {summary}
 description:          {description}
 assignee_account_id:  {account_id}
@@ -129,7 +151,7 @@ Store `ticket_url` = `{html_url}`.
 
 No ticket is created. `ticket_ref` = `none`. `ticket_url` = none.
 
-## Step 6 — Construct the branch name
+## Step 7 — Construct the branch name
 
 Slugify the summary:
 - Lowercase, hyphens for spaces, remove special characters, collapse consecutive hyphens, truncate to 60 chars
@@ -140,7 +162,7 @@ Slugify the summary:
 | `github-issues` | `{branch_type}-gh-{number}-{slug}` | `feature-gh-123-add-rate-limiting` |
 | `none` | `{branch_type}-{slug}` | `feature-add-rate-limiting` |
 
-## Step 7 — Create the remote branch and check out locally
+## Step 8 — Create the remote branch and check out locally
 
 Call `create_branch` on `user-github`:
 ```
@@ -158,7 +180,7 @@ git fetch origin
 git checkout {branch_name}
 ```
 
-## Step 8 — Scaffold spec.md
+## Step 9 — Scaffold spec.md
 
 Write `.dmx/spec.md`:
 
@@ -179,7 +201,7 @@ ticketing: {ticketing}
 ---
 
 ## Context
-{From ticket description Step 4 — why this work is needed in this project}
+{From ticket description Step 5 — why this work is needed in this project}
 
 ## Scope
 {Bullet list of what is included. Use project patterns to name specific layers, services, or files.}
@@ -221,7 +243,7 @@ ticketing: {ticketing}
 
 When `ticketing` is `none`, omit `ticket` from frontmatter.
 
-## Step 9 — Transition to In Progress
+## Step 10 — Transition to In Progress
 
 **If `ticketing` is `jira`:**
 Call `getTransitionsForJiraIssue` on `user-atlassian`. Find `In Progress`. Call `transitionJiraIssue`.
@@ -237,7 +259,7 @@ labels:       ["in-progress"]
 
 **If `ticketing` is `none`:** Skip.
 
-## Step 10 — Return the result
+## Step 11 — Return the result
 
 ```
 {if ticketing ≠ none} Ticket: {ticket_ref} — {summary}