mustflow 2.112.1 → 2.112.3

package/dist/core/command-effects.js

@@ -1,3 +1,4 @@
+import { realpathSync } from 'node:fs';
 import path from 'node:path';
 import { isRecord, readString, readStringArray, } from './config-loading.js';
 import { resolveSafeProjectCwd } from './command-cwd.js';
@@ -17,9 +18,9 @@ function pathLockKey(relativePath) {
 function validateEffectPath(projectRoot, commandContract, intent, rawPath) {
     const cwd = resolveSafeProjectCwd(projectRoot, readEffectiveCommandCwd(commandContract, intent));
     const resolved = path.resolve(cwd, rawPath);
-    const root = path.resolve(projectRoot);
-    const relative = path.relative(root, resolved);
-    if (relative.startsWith('..') || path.isAbsolute(relative)) {
+    const rootRealPath = realpathSync.native(projectRoot);
+    const relative = path.relative(rootRealPath, resolved);
+    if (relative === '..' || relative.startsWith(`..${path.sep}`) || path.isAbsolute(relative)) {
         throw new Error(`Command effect path must stay inside the current root: ${rawPath}`);
     }
     return normalizeRelativePath(relative);

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "mustflow",
-  "version": "2.112.1",
+  "version": "2.112.3",
   "description": "Agent workflow documents and CLI for mustflow repository roots.",
   "type": "module",
   "license": "MIT-0",

package/templates/default/i18n.toml

@@ -901,7 +901,7 @@ translations = {}
 [documents."skill.completion-evidence-gate"]
 source = "locales/en/.mustflow/skills/completion-evidence-gate/SKILL.md"
 source_locale = "en"
-revision = 6
+revision = 7
 translations = {}
 
 [documents."skill.next-action-menu"]
@@ -997,7 +997,7 @@ translations = {}
 [documents."skill.failure-triage"]
 source = "locales/en/.mustflow/skills/failure-triage/SKILL.md"
 source_locale = "en"
-revision = 5
+revision = 6
 translations = {}
 
 [documents."skill.external-prompt-injection-defense"]
@@ -1146,7 +1146,7 @@ translations = {}
 [documents."skill.release-publish-change"]
 source = "locales/en/.mustflow/skills/release-publish-change/SKILL.md"
 source_locale = "en"
-revision = 1
+revision = 2
 translations = {}
 
 [documents."skill.security-privacy-review"]

package/templates/default/locales/en/.mustflow/skills/completion-evidence-gate/SKILL.md

@@ -2,11 +2,11 @@
 mustflow_doc: skill.completion-evidence-gate
 locale: en
 canonical: true
-revision: 6
+revision: 7
 lifecycle: mustflow-owned
 authority: procedure
 name: completion-evidence-gate
-description: Apply this skill before a final report or completion claim after non-trivial changed-file work, verification, commit, release readiness, paused implementation, or any report where changed files, skipped checks, concrete next actions, or remaining risks must be tied to repository evidence.
+description: Apply this skill before a final report or completion claim after non-trivial changed-file work, verification, commit, push, release readiness, paused implementation, or any report where changed files, skipped checks, concrete next actions, remote check-suite state, or remaining risks must be tied to repository evidence.
 metadata:
   mustflow_schema: "1"
   mustflow_kind: procedure
@@ -68,6 +68,9 @@ missing, blocked, failed, stale, or only partially relevant.
 - The skills used, main route chosen, and any supporting or event skills activated.
 - Requirement, bug, issue, or external-advice sources that influenced the work.
 - Command intents run, exit status, and whether the evidence came from `mf run` receipts or lower-confidence direct shell output.
+- Remote check-suite evidence when the task includes commit, push, tag, release, deploy, or a
+  GitHub/GitLab/CI status claim: ref, commit SHA, workflow names, required checks, failed checks,
+  pending checks, skipped checks, and the timestamp or run id of the evidence.
 - Command intents skipped, missing, unknown, manual-only, failed, timed out, or judged not applicable.
 - Optional script-pack discovery evidence when the command contract exposes `script_pack_list`.
 - Synchronized surfaces expected by the changed contract: source, tests, fixtures, schemas, templates, manifests, docs, release metadata, generated output, and localized copies.
@@ -108,6 +111,9 @@ missing, blocked, failed, stale, or only partially relevant.
 4. Check verification quality.
    - Prefer configured `mf run` receipts over direct shell output.
    - Confirm that each command intent was relevant to the changed surface and current diff.
+   - For commit, push, tag, release, or deploy claims, classify remote checks separately from
+     artifact publication. A successful package registry lookup, GitHub Release, uploaded asset,
+     or deployment artifact does not prove branch CI or same-commit checks passed.
    - Treat stale receipts, missing latest receipts, failed intents, timed-out intents, repeated failure fingerprints, write-drift risks, validation-ratchet risks, scope-drift risks, and external-evidence risks as completion limitations.
    - Treat repeated identical observations, duplicate-call guards, failed reads, truncated output,
      and directory listings used as file-content proof as evidence limitations; use
@@ -148,6 +154,8 @@ missing, blocked, failed, stale, or only partially relevant.
 - The final report's completion language matches the evidence actually available.
 - Every user requirement is mapped to proof, a limitation, or an explicit out-of-scope decision.
 - Skipped, missing, failed, stale, or manual-only verification is visible.
+- Push, tag, release, and deploy completion claims name the relevant remote check-suite state, or
+  explicitly say that it was not checked.
 - Contract, template, schema, docs, test, and release drift is either resolved or named as remaining risk.
 - For non-trivial final reports, useful follow-up tasks appear through `next-action-menu` whenever
   at least one concrete next action remains, including approval-gated next actions.
@@ -181,6 +189,8 @@ instead of replacing it with an inferred command.
 
 - If changed-file evidence is unavailable, stop the completion claim and run or request the configured status intent.
 - If a configured command fails, switch to `failure-triage` for that intent before claiming completion.
+- If a remote check is failing or still pending for the pushed ref, do not report the work as fully
+  green even when publication, artifact upload, or installation verification succeeded.
 - If a required surface is missing, either synchronize it under the matching skill or report the remaining drift.
 - If evidence is stale or comes from a different diff, treat the task as unverified until current evidence exists.
 - If evidence stalls behind repeated reads, searches, or duplicate-call warnings, use
@@ -196,6 +206,7 @@ instead of replacing it with an inferred command.
 - Changed surfaces
 - Synchronized surfaces and deferred surfaces
 - Command intents run
+- Remote check-suite state for pushed refs, tags, releases, or deploys
 - Skipped, missing, failed, stale, or manual-only checks
 - Lower-confidence evidence, if any
 - Stalled or repeated observations, if any

package/templates/default/locales/en/.mustflow/skills/failure-triage/SKILL.md

@@ -2,7 +2,7 @@
 mustflow_doc: skill.failure-triage
 locale: en
 canonical: true
-revision: 5
+revision: 6
 lifecycle: mustflow-owned
 authority: procedure
 name: failure-triage
@@ -28,6 +28,8 @@ Identify the most probable root cause of a failed command or verification step b
 
 - A configured command intent returns a non-zero exit code.
 - Validation, build, test, or documentation checks fail.
+- A local release or publish path succeeded, but a remote CI job, check suite, or platform-specific
+  runner still shows a failure for the pushed branch, tag, or commit.
 - The root cause of the failure is not yet apparent.
 - A test or build failure may have been caused by an overlapping run, orphaned process, stale lock, or deleted build output.
 - Several failures appear together and the first root cause needs to be separated from follow-on noise.
@@ -45,6 +47,8 @@ Identify the most probable root cause of a failed command or verification step b
 - Original command intent
 - Exit code
 - Truncated stdout and stderr output
+- Remote run context when applicable: branch, tag, commit SHA, job name, runner OS, matrix entry,
+  and whether the failure belongs to a push, pull request, tag, release, or scheduled run
 - Recently modified files
 - Relevant command contract entry
 - Active or recently active build/test/profile processes when the failure mentions missing compiled files, stale output, port/resource conflicts, or unexpected file deletion
@@ -74,17 +78,27 @@ Identify the most probable root cause of a failed command or verification step b
    - `documentation`: docs navigation, frontmatter, generated content, or localized metadata drifted.
    - `environment`: missing tool, platform difference, path, permission, lock, stale build output, or orphaned process.
    - `tool_runner`: the verification runner, scheduler, cache, or build wrapper failed independently from the code under test.
-4. If several failures appear, triage in this order: environment and overlapping processes, build or generated output, configuration/schema drift, fixture setup, then behavior logic.
-5. For failures involving `dist/`, generated output, temporary files, ports, databases, or abrupt test termination, check whether another build/test/profile process for the same repository is still running.
-6. If an orphaned or overlapping process is found, stop or wait for it before changing source files, then rerun the narrowest failing intent to confirm the failure is reproducible.
-7. Pick one rerun target:
+4. For remote CI failures, record the failing ref, commit, job name, runner OS, and matrix before
+   editing. Compare that runner to local verification instead of assuming local success covers the
+   remote job.
+5. Treat Windows-only, path-only, or runner-only failures as real until proven otherwise. If the
+   error mentions `inside the current root`, `.mustflow/cache/**`, `.mustflow/review/docs.toml`,
+   symlinks, junctions, realpaths, drive-letter casing, path separators, or root containment, inspect
+   path normalization and containment helpers first. Add or update a regression test that models the
+   platform/root-alias behavior instead of weakening containment checks.
+6. If several failures appear, triage in this order: environment and overlapping processes, build or generated output, configuration/schema drift, fixture setup, then behavior logic.
+7. For failures involving `dist/`, generated output, temporary files, ports, databases, or abrupt test termination, check whether another build/test/profile process for the same repository is still running.
+8. If an orphaned or overlapping process is found, stop or wait for it before changing source files, then rerun the narrowest failing intent to confirm the failure is reproducible.
+9. Pick one rerun target:
    - the original failing intent when it is narrow enough;
    - `test_related` when changed files map to a focused suite;
    - `docs_validate_fast` for docs navigation or content-only failures;
    - `test_release` for package, template, schema, or release metadata drift;
    - `mustflow_check` for workflow, skill, command-contract, or manifest-lock failures.
-8. Examine the most relevant files.
-9. Develop a single hypothesis and verify it using the most targeted configured intent.
+10. Examine the most relevant files.
+11. Develop a single hypothesis and verify it using the most targeted configured intent. When the
+    failure came from remote CI, also confirm the replacement run or check suite for the affected
+    ref before reporting that the remote failure is fixed.
 
 <!-- mustflow-section: postconditions -->
 ## Postconditions
@@ -105,6 +119,9 @@ intent that isolates the same failure area.
 - If the failure is due to missing tools, report the missing tool and the command that revealed the issue.
 - If the failure was caused by an orphaned or overlapping process, report that the original run was invalid and add or use a guard that prevents the same overlap before taking new measurements.
 - If rerunning the same intent produces a different failure without code changes, classify the issue as flaky or environmental and avoid weakening assertions until the unstable dependency is identified.
+- If publication, release creation, or artifact upload succeeded while another check on the same
+  pushed commit failed, report those as separate states and triage the failed check before using
+  all-clear language.
 - If sensitive data appears in the output, cease copying raw output and summarize the information safely.
 
 <!-- mustflow-section: output-format -->

package/templates/default/locales/en/.mustflow/skills/release-publish-change/SKILL.md

@@ -2,7 +2,7 @@
 mustflow_doc: skill.release-publish-change
 locale: en
 canonical: true
-revision: 1
+revision: 2
 lifecycle: mustflow-owned
 authority: procedure
 name: release-publish-change
@@ -31,7 +31,7 @@ metadata:
 
 Keep release work honest by treating a release as a remote state transition, not as a local code edit.
 
-The release is not done when tests pass locally, a version string changes, or a workflow succeeds. It is done only when the intended remote channel contains the expected artifact and a user-facing installation or update path has been smoke-tested through configured command intents or explicitly reported as unverified.
+The release is not done when tests pass locally, a version string changes, or a workflow succeeds. It is done only when the intended remote channel contains the expected artifact and a user-facing installation or update path has been smoke-tested through configured command intents or explicitly reported as unverified. Release publication success and branch or tag check-suite health are separate evidence surfaces.
 
 <!-- mustflow-section: use-when -->
 ## Use When
@@ -56,6 +56,9 @@ The release is not done when tests pass locally, a version string changes, or a
 - Public contract source for versioning: package metadata, manifest, lock or generated metadata, changelog, release workflow, tag policy, and SemVer or project-specific compatibility rules.
 - Artifact source and inspection method: package file list, archive contents, generated distributions, checksums, signatures, SBOM, provenance, installer contents, image digest, updater metadata, or release asset manifest.
 - Remote publication surface: registry, Git tag, GitHub Release, Docker registry, tap, updater feed, appcast, CDN, package index, or store.
+- Remote check surface: pushed branch, tag, commit SHA, workflow run, required checks, matrix jobs,
+  and whether each belongs to publication, branch CI, tag CI, release asset generation, or another
+  independent verification path.
 - Recovery model: unpublish, yank, deprecate, republish with new version, move channel pointer, revoke asset, restore from backup, or forward fix.
 - Configured command intents for build, package inspection, release verification, docs validation, and user installation or updater smoke test. If no such intent exists, report the missing intent instead of inventing a raw command.
 
@@ -112,12 +115,19 @@ The release is not done when tests pass locally, a version string changes, or a
    - Check the registry, tag, release page, asset download, digest, updater feed, tap, or package index that users actually consume.
    - Then run the configured user installation, pull, download, or updater smoke intent.
    - If remote publication was not authorized or not performed, report the release as prepared but not published.
-15. Report immutable or hard-to-recover mistakes honestly.
+15. Verify check-suite state separately from publication state.
+   - Identify which workflow runs belong to the pushed branch, release tag, and publication event.
+   - Do not treat npm registry visibility, package installability, or GitHub Release creation as
+     proof that push checks, branch protection, or platform matrix jobs are green.
+   - If a publication workflow succeeds while a branch, tag, or same-commit check fails or remains
+     in progress, report `published` and `checks failing` or `checks pending` as separate states.
+   - Route any failing check through `failure-triage` before reporting an all-clear.
+16. Report immutable or hard-to-recover mistakes honestly.
    - Bad package version: usually deprecate, yank, or release a new version.
    - Bad Go module tag: do not assume moving the tag fixes proxy/cache consumers.
    - Bad Docker tag: distinguish moved tag from old digest still being referenced.
    - Bad updater metadata: treat as a live channel incident if clients may already have seen it.
-16. Never call a release complete from local tests alone. The completion evidence must name the remote channel and the user installation or update path, or explicitly say that post-publish verification was skipped.
+17. Never call a release complete from local tests alone. The completion evidence must name the remote channel, the user installation or update path, and the current relevant check-suite state, or explicitly say which post-publish verification was skipped.
 
 <!-- mustflow-section: postconditions -->
 ## Postconditions
@@ -125,6 +135,8 @@ The release is not done when tests pass locally, a version string changes, or a
 - Version bump, release notes, package metadata, manifests, artifacts, workflows, tests, and docs agree.
 - The artifact contents have been inspected through configured evidence, not inferred from the source tree.
 - Remote publication status is classified as not started, prepared, published, verified, failed, yanked, deprecated, superseded, or unknown.
+- Branch, tag, and publication workflow checks are classified separately as green, failing, pending,
+  skipped, not applicable, or unknown.
 - User installation, pull, download, or updater smoke test status is known or explicitly reported as skipped.
 - Recovery plan matches the channel's actual permanence and rules.
 
@@ -153,6 +165,9 @@ Do not infer package manager, registry, Docker, Git, Homebrew, or updater comman
 - If the artifact contents differ from the intended release, stop release claims and fix the source, generated output, or packaging configuration before publication.
 - If the remote registry already contains the version, do not assume overwrite is possible. Report the channel-specific recovery path.
 - If publication succeeds but install smoke fails, treat the release as published but not verified and recommend channel-appropriate mitigation.
+- If publication succeeds but branch, tag, or same-commit checks fail, treat the release as
+  published but not all-clear. Do not hide the red check behind successful registry or GitHub
+  Release evidence.
 - If a tag, asset, digest, checksum, signature, updater feed, or release body is missing, do not collapse the issue into "workflow failed"; name the missing remote surface.
 - If release evidence comes only from CI logs, report that no independent user-path smoke test was completed unless the configured CI explicitly performs that path.
 - If unpublish, yank, tag movement, channel rollback, or asset deletion is proposed, check host and repository authorization first and report the permanence risk.
@@ -164,6 +179,7 @@ Do not infer package manager, registry, Docker, Git, Homebrew, or updater comman
 - Public API and version bump classification
 - Artifact contents inspected
 - Remote publication state
+- Branch, tag, and publication check-suite state
 - User installation, download, pull, or updater smoke path result
 - Synchronized version, docs, manifest, workflow, and test surfaces
 - Recovery or rollback classification

package/templates/default/manifest.toml

@@ -1,6 +1,6 @@
 id = "default"
 name = "default"
-version = "2.112.1"
+version = "2.112.3"
 description = "Minimal workflow for LLM agents to read, edit, and verify their work in a repository."
 common_root = "common"
 locales_root = "locales"