mustflow 1.15.99 → 1.16.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/package.json
CHANGED
|
@@ -76,7 +76,7 @@ translations.hi = { path = "locales/hi/.mustflow/skills/adapter-boundary/SKILL.m
|
|
|
76
76
|
[documents."skill.artifact-integrity-check"]
|
|
77
77
|
source = "locales/en/.mustflow/skills/artifact-integrity-check/SKILL.md"
|
|
78
78
|
source_locale = "en"
|
|
79
|
-
revision =
|
|
79
|
+
revision = 5
|
|
80
80
|
translations.ko = { path = "locales/ko/.mustflow/skills/artifact-integrity-check/SKILL.md", source_revision = 1, status = "needs_review" }
|
|
81
81
|
translations.zh = { path = "locales/zh/.mustflow/skills/artifact-integrity-check/SKILL.md", source_revision = 1, status = "needs_review" }
|
|
82
82
|
translations.es = { path = "locales/es/.mustflow/skills/artifact-integrity-check/SKILL.md", source_revision = 1, status = "needs_review" }
|
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
mustflow_doc: skill.artifact-integrity-check
|
|
3
3
|
locale: en
|
|
4
4
|
canonical: true
|
|
5
|
-
revision:
|
|
5
|
+
revision: 5
|
|
6
6
|
lifecycle: mustflow-owned
|
|
7
7
|
authority: procedure
|
|
8
8
|
name: artifact-integrity-check
|
|
@@ -50,6 +50,7 @@ Ensure generated artifacts, packaged files, media assets, reports, and downloada
|
|
|
50
50
|
- Artifact paths or expected output locations.
|
|
51
51
|
- Source files, generation steps, or package rules that should produce the artifact.
|
|
52
52
|
- Any size, format, hash, manifest, package, or documentation expectation.
|
|
53
|
+
- Declared version source, current published version, intended release tag, and SemVer decision when the artifact is versioned.
|
|
53
54
|
- Relevant command-intent contract entries for build, packaging, validation, or asset optimization.
|
|
54
55
|
- Workflow steps, action references, publish credentials, OIDC permissions, package registry identity, and pre-publish lifecycle scripts when artifacts are released.
|
|
55
56
|
- Code-scanning artifact paths, upload steps, credential scope, and whether the uploaded artifact can contain checkout credentials, generated secrets, or tampered package contents.
|
|
@@ -76,12 +77,17 @@ Ensure generated artifacts, packaged files, media assets, reports, and downloada
|
|
|
76
77
|
3. Check that source references, manifests, package includes, docs links, and tests point to the same path and format.
|
|
77
78
|
4. For publish workflows, inspect code that runs before artifact publication. Treat mutable third-party actions, lifecycle scripts, package manifests, and generated files as artifact mutation points.
|
|
78
79
|
5. Prefer explicit release gates for publish automation. Do not publish packages on every branch push; use a version tag or a manually published release, then verify the tag matches the package metadata before publication.
|
|
79
|
-
6.
|
|
80
|
-
|
|
81
|
-
|
|
82
|
-
|
|
83
|
-
|
|
84
|
-
|
|
80
|
+
6. When changing a versioned artifact, choose the version bump from the declared repository versioning policy first. If no narrower policy is declared, use SemVer as follows:
|
|
81
|
+
- Increment `X` in `X.Y.Z` only for breaking changes to public commands, schemas, package entrypoints, installed template contracts, or documented behavior that existing users may rely on.
|
|
82
|
+
- Increment `Y` for backward-compatible new capabilities, newly installed skills or workflow guidance, new public commands, new schema fields that old consumers can ignore, or meaningful template behavior that users receive after installation or update.
|
|
83
|
+
- Increment `Z` for backward-compatible fixes, packaging corrections, documentation or prose repairs, test-only changes, internal refactors, or release automation fixes that do not add a user-facing capability.
|
|
84
|
+
7. Do not bump a version just because files changed. Record the artifact surface that justifies the bump and keep every declared version source synchronized with the chosen version.
|
|
85
|
+
8. If a workflow creates a release and publishes an artifact, keep release creation and publication in the same trusted workflow unless it uses a token that is intended to trigger follow-up workflows. Repository `GITHUB_TOKEN` events generally should not be used as the only trigger for a second publish workflow.
|
|
86
|
+
9. For workflow artifact alerts, check whether checkout credentials persist into the workspace, whether artifacts are uploaded after untrusted code runs, and whether the job permission is broader than the artifact operation needs.
|
|
87
|
+
10. Verify existence, format, and expected inclusion using the narrowest configured command intent available.
|
|
88
|
+
11. If a generated artifact is stale or missing, regenerate it only through a configured command intent or report the missing command.
|
|
89
|
+
12. If an artifact should not be versioned, ensure the final report does not imply that it was committed or distributed.
|
|
90
|
+
13. Report artifact evidence precisely: path checked, command intent run, version bump reason when applicable, and any remaining unverified attribute.
|
|
85
91
|
|
|
86
92
|
<!-- mustflow-section: postconditions -->
|
|
87
93
|
## Postconditions
|
|
@@ -89,6 +95,7 @@ Ensure generated artifacts, packaged files, media assets, reports, and downloada
|
|
|
89
95
|
- Every artifact claim in code, docs, manifests, tests, and the final report is backed by observed evidence or explicitly marked unverified.
|
|
90
96
|
- Generated and ignored outputs are not treated as project truth unless the repository declares them versioned.
|
|
91
97
|
- Package or distribution claims are verified with the relevant configured intent when available.
|
|
98
|
+
- Versioned artifact releases have a documented bump reason and synchronized version sources.
|
|
92
99
|
|
|
93
100
|
<!-- mustflow-section: verification -->
|
|
94
101
|
## Verification
|
|
@@ -108,6 +115,7 @@ Use a narrower configured asset or documentation validation intent when it bette
|
|
|
108
115
|
|
|
109
116
|
- If the artifact cannot be generated or inspected, report the missing tool, command intent, or source file.
|
|
110
117
|
- If package inclusion and source references disagree, fix the manifest or docs before reporting the artifact as shipped.
|
|
118
|
+
- If the intended version bump does not match the changed public surface, stop and correct the version or report why a project-specific policy overrides the default SemVer decision.
|
|
111
119
|
- If a privileged release workflow runs mutable actions or repository-controlled code before publishing, report the artifact integrity risk or isolate and pin the publish path before claiming the package is trustworthy.
|
|
112
120
|
- If an artifact is too large, stale, or in the wrong format, report the issue and avoid claiming it is production-ready.
|
|
113
121
|
- If verification would require external services or unavailable tools, stop at that boundary and name the unchecked artifact property.
|
|
@@ -118,6 +126,7 @@ Use a narrower configured asset or documentation validation intent when it bette
|
|
|
118
126
|
- Artifact paths checked
|
|
119
127
|
- Artifact source or generation path
|
|
120
128
|
- Inclusion, format, or size evidence
|
|
129
|
+
- Version bump decision and synchronized version sources, when applicable
|
|
121
130
|
- Command intents run
|
|
122
131
|
- Skipped artifact checks and reasons
|
|
123
132
|
- Remaining artifact integrity risk
|