mustflow 2.84.0 → 2.99.0

package/templates/default/locales/en/.mustflow/skills/cache-integrity-review/SKILL.md

@@ -2,11 +2,11 @@
 mustflow_doc: skill.cache-integrity-review
 locale: en
 canonical: true
-revision: 1
+revision: 2
 lifecycle: mustflow-owned
 authority: procedure
 name: cache-integrity-review
-description: Apply this skill when code is created, changed, reviewed, or reported and cache behavior can spread stale, wrong, private, overbroad, tenant-crossing, permission-wrong, version-incompatible, or source-overloading values through cache keys, query normalization, key versions, TTL and jitter, soft and hard TTL, stale-while-revalidate, stampede protection, request coalescing, negative caching, invalidation order, list or page caches, tag invalidation, L1/L2 cache layers, Redis fallback, hit/miss observability, value size, eviction policy, TTL-less keys, KEYS/SCAN use, hot keys, Redis Cluster hash tags, HTTP Vary/no-cache/no-store semantics, permission caches, cache warming, or failure-path cache tests.
+description: Apply this skill when code is created, changed, reviewed, or reported and cache behavior can spread stale, wrong, private, overbroad, tenant-crossing, permission-wrong, version-incompatible, or source-overloading values through cache keys, query normalization, key versions, TTL and jitter, soft and hard TTL, stale-while-revalidate, stampede protection, request coalescing, negative caching, invalidation order, list or page caches, tag invalidation, L1/L2 cache layers, Redis fallback, cache-status ledgers such as hit, miss, bypass, stale, refresh, error, set-failed, evicted, or expired, origin-cost observability, value size, eviction policy, TTL-less keys, KEYS/SCAN use, hot keys, Redis Cluster hash tags, replica lag, Redis latency, HTTP Vary/no-cache/no-store semantics, permission caches, cache warming, or failure-path cache tests.
 metadata:
   mustflow_schema: "1"
   mustflow_kind: procedure
@@ -81,9 +81,11 @@ and what happens to the source system when the cache misses or fails?"
 - Failure and concurrency contract: miss behavior, concurrent miss behavior, source timeout, Redis
   failure, source failure, negative cache policy, update race behavior, invalidation ordering, and
   stale serve policy.
-- Observability evidence: hit and miss metrics, miss cost, value size, key count, eviction, expiry,
-  tenant or endpoint breakdown, status-code breakdown, source query time, source call count, and set
-  success.
+- Observability evidence: hit, miss, bypass, stale, refresh, negative-hit, set-failed, error,
+  eviction, expiry, and fallback metrics; miss cost; hit-rate cost by endpoint or tenant; value
+  size; key count; source query time; source call count; origin saturation; Redis client wait,
+  round-trip latency, command latency, serialization cost, Slow Log limits, replica lag, shard
+  imbalance, and set success.
 - Relevant command-intent contract entries for tests, builds, docs, release checks, and mustflow
   validation.
 
@@ -180,6 +182,8 @@ and what happens to the source system when the cache misses or fails?"
       shedding, stale serve, circuit breaker, bulkhead, or another source-protection mechanism.
     - Decide whether cache failure is disposable or correctness-sensitive. Sessions, permissions,
       rate limits, inventory, idempotency, and dedupe caches are not ordinary performance caches.
+    - Compare normal cached traffic with an allowed bypass path or known miss path when evidence is
+      available. If bypass is faster, fresher, or more correct, the cache policy itself is suspect.
 13. Check Redis keyspace and memory behavior.
     - Review value size, key size, key schema, bounded key cardinality, max memory, eviction policy,
       expired keys, evicted keys, and whether TTL-less keys are turning cache into state storage.
@@ -187,43 +191,54 @@ and what happens to the source system when the cache misses or fails?"
       so TTL-less keys can crowd out real cache behavior.
     - `KEYS *` in application code is a production bomb. Use `SCAN` only from bounded admin or
       maintenance paths with explicit limits.
-14. Check hot keys and Redis Cluster distribution.
+14. Check Redis latency, replication, and distribution.
+    - Redis Slow Log does not include client round-trip time, connection wait, serialization,
+      application loop overhead, DNS, TLS, or network path time. Do not use it as the only latency
+      proof.
+    - Review replica lag, failover behavior, cold replica warmup, persistence spikes, memory
+      fragmentation, client connection pools, shard imbalance, and command mix when a cache incident
+      is operational rather than semantic.
+15. Check hot keys and Redis Cluster distribution.
     - Sharding does not save one hot key. Use replicas, local L1, request coalescing, prewarm,
       chunking, or workload-specific splitting where semantics allow it.
     - Redis Cluster hash tags are useful for intentional multi-key locality, but overusing the same
       tag can force too many keys into one slot.
-15. Check HTTP cache semantics.
+16. Check HTTP cache semantics.
     - If responses vary by `Authorization`, `Cookie`, `Accept-Language`, `Accept-Encoding`, content
       negotiation, or user context, verify `Vary` and cache-control behavior.
     - `no-cache` means revalidate before reuse. `no-store` means do not store. Do not use one when
       the other is required.
     - Check freshness, validation, private versus public cacheability, CDN behavior, browser behavior,
       and generated-client or proxy expectations.
-16. Check permission and entitlement caches as security boundaries.
+17. Check permission and entitlement caches as security boundaries.
     - A permission cache, role cache, organization-membership cache, subscription cache, admin cache,
       or entitlement cache must be invalidated by revocation, role change, organization move,
       subscription expiry, ownership change, and emergency access changes.
     - Short TTL alone is not enough for decisions that should fail closed or revoke promptly.
-17. Check cache warming and cold-start behavior.
+18. Check cache warming and cold-start behavior.
     - Deployment, autoscale, failover, and rollback can create synchronized cold caches that push
       traffic to the source.
     - Prewarm only keys with clear ownership and backpressure. Do not build an unbounded warming job
       that becomes the outage.
-18. Check observability.
-    - Hit rate alone lies. Break down hits, misses, stale serves, negative hits, refresh failures,
-      evictions, expirations, and set failures by endpoint, key-pattern, tenant, status-code, and
-      cache layer where useful.
+    - Load-test or smoke the cold, warm, failover, replica-lag, source-slow, and cache-down scenarios
+      when the repository has configured evidence. Otherwise report those as manual operational gaps.
+19. Check observability.
+    - Hit rate alone lies. Break down hits, misses, bypasses, stale serves, refreshes, negative hits,
+      refresh failures, evictions, expirations, fallback serves, Redis errors, and set failures by
+      endpoint, key-pattern, tenant, status-code, and cache layer where useful.
     - Log or measure miss cost: source query time, source call count, value size, generation time,
       and set success.
+    - Track hit-rate cost: origin load avoided, origin load caused by misses, miss amplification,
+      cache write failures, and whether a high hit rate hides a small set of expensive miss paths.
     - Keep cache metrics labels bounded; put high-cardinality keys in logs or traces only when the
       repository privacy rules allow it.
-19. Check tests beyond the happy path.
+20. Check tests beyond the happy path.
     - "Second call is faster" is not enough.
     - Cover concurrent misses, update during read, delete then recreate, source failure, Redis
       failure, synchronized TTL expiry, old-version cached value, permission change, tenant
       separation, list invalidation, negative-cache classification, deploy rollback, and cache-layer
       bypass when those risks exist.
-20. Label evidence honestly. If the repository lacks deterministic cache, Redis, CDN, HTTP, browser,
+21. Label evidence honestly. If the repository lacks deterministic cache, Redis, CDN, HTTP, browser,
     or load tests, report the missing evidence instead of claiming the cache is safe.
 
 <!-- mustflow-section: postconditions -->

package/templates/default/locales/en/.mustflow/skills/change-blast-radius-review/SKILL.md

@@ -2,11 +2,11 @@
 mustflow_doc: skill.change-blast-radius-review
 locale: en
 canonical: true
-revision: 1
+revision: 2
 lifecycle: mustflow-owned
 authority: procedure
 name: change-blast-radius-review
-description: Apply this skill when code is created, changed, reviewed, or reported and maintainability needs review by predicting the next-change blast radius, deletion path, policy owner, workflow owner, controller or service responsibility, boolean and option-mode sprawl, scattered domain rules, scattered authorization, state-transition ownership, direct time or randomness, transaction and external-call coupling, retry idempotency, cache-as-truth decisions, config flag combinations, tenant or partner hardcoding, legacy branch isolation, DTO/entity/view model mixing, nullable meaning, swallowed exceptions, low-context logs, implementation-coupled tests, mock-heavy tests, decorative abstraction, premature DRY, hidden ordering dependency, event contract visibility, migration/runtime compatibility, or feature removal boundary.
+description: Apply this skill when code is created, changed, reviewed, or reported and maintainability needs review by predicting the next-change blast radius, historical co-change spread, deletion path, policy owner, workflow owner, controller or service responsibility, boolean and option-mode sprawl, scattered domain rules, scattered authorization, state-transition ownership, direct time or randomness, transaction and external-call coupling, retry idempotency, cache-as-truth decisions, config flag combinations, tenant or partner hardcoding, legacy branch isolation, DTO/entity/view model mixing, nullable meaning, swallowed exceptions, low-context logs, implementation-coupled tests, mock-heavy tests, decorative abstraction, premature DRY, hidden ordering dependency, event contract visibility, migration/runtime compatibility, or feature removal boundary.
 metadata:
   mustflow_schema: "1"
   mustflow_kind: procedure
@@ -46,6 +46,8 @@ feature is removed, what can I delete?"
   logging, tests, abstractions, helpers, or legacy compatibility.
 - A single requirement would force edits across several files, layers, modules, frontend code, SQL,
   jobs, events, cache keys, tests, or docs.
+- Recent PRs, commits, work orders, or review history show that small requirements routinely
+  co-change many repositories, services, schemas, pipelines, teams, tests, or docs.
 - A file or service has several unrelated reasons to change under one broad noun such as `Manager`,
   `Helper`, `Processor`, `Handler`, or `Service`.
 - A review needs to decide whether to use `module-boundary-review`, `structure-first-engineering`,
@@ -72,6 +74,10 @@ feature is removed, what can I delete?"
 - User goal, current diff or target files, and the requirement or policy that caused the change.
 - Change-reason ledger: which business rule, user flow, data shape, failure path, compatibility
   rule, tenant exception, or operational behavior would make this code change next.
+- Historical co-change ledger when available: recent PRs or commits touching the same requirement
+  family, repositories touched, services touched, DB schemas touched, deployment pipelines touched,
+  teams or reviewers involved, tests changed, docs changed, and whether the current design reduced
+  or repeated that spread.
 - Blast-radius ledger: controllers, services, repositories, entities, DTOs, frontend conditions,
   SQL, migrations, batches, events, caches, config, tests, docs, and templates touched by one reason.
 - Ownership ledger: source of truth for domain rule, authorization rule, state transition, retry
@@ -115,123 +121,128 @@ feature is removed, what can I delete?"
    - Ask: "If this requirement changes next month, which files move?"
    - If one policy edit needs controller, service, repository, SQL, frontend, batch, cache, and test
      edits, the code is a puzzle, not a boundary.
-2. Count reasons to change, not lines.
+2. Check historical co-change when evidence exists.
+   - Look for recent PRs, commits, or work items in the same feature or policy family.
+   - Count repositories, services, schemas, pipelines, test suites, docs, and teams touched by small changes.
+   - Treat repeated cross-boundary co-change as stronger evidence than a clean-looking folder tree.
+   - If history is unavailable or too expensive for the task, report the review as prediction-only instead of pretending the boundary was proven.
+3. Count reasons to change, not lines.
    - A short file can still hold signup, login, points, notification, referral, admin blocking, and
      reporting rules.
    - Split by different change reasons, not by noun labels.
-3. Keep controllers as doors, not bosses.
+4. Keep controllers as doors, not bosses.
    - Controllers should parse requests, call an application boundary, and map the result.
    - Treat controller `if`, `for`, state mutation, external API calls, discount logic, inventory
      checks, or notification orchestration as workflow leakage.
-4. Reject junk-drawer services.
+5. Reject junk-drawer services.
    - Broad names such as `OrderService`, `UserService`, `Manager`, `Helper`, `Processor`, and
      `Handler` often hide unrelated workflows.
    - Name the actual responsibility or split by workflow owner when changes would not arrive
      together.
-5. Decode boolean mode flags.
+6. Decode boolean mode flags.
    - `createUser(user, true)` and `sendNotification(user, true, false)` mean one function already
      has hidden modes.
    - Replace modes with named variants, policy objects, strategy objects, or separate functions when
      behavior contracts differ.
-6. Inspect option objects for combinatorial behavior.
+7. Inspect option objects for combinatorial behavior.
    - Fields such as `skipValidation`, `dryRun`, `force`, `source`, `mode`, `type`, `retry`,
      `legacy`, and `includeInactive` can turn one call into many products.
    - If field combinations change behavior, use explicit mode types or separate boundaries.
-7. Find the policy source of truth.
+8. Find the policy source of truth.
    - Repeated rules such as "VIP gets free shipping" across backend, frontend, SQL, batch, and
      cache code are not harmless duplication.
    - Name one owner and make other layers consume facts or capabilities from that owner.
-8. Centralize authorization policy.
+9. Centralize authorization policy.
    - Scattered checks such as `role == admin`, `ownerId == user.id`, or membership scans make policy
      changes scary.
    - Use `auth-permission-change` when action permission needs one policy source and denial tests.
-9. Make state transitions visible.
+10. Make state transitions visible.
    - Status values are not enough. Review where `status = ...` happens and which transitions are
      legal.
    - Use `state-machine-pattern` when allowed transitions need to be represented explicitly.
-10. Pull time, randomness, and generated IDs to a boundary.
+11. Pull time, randomness, and generated IDs to a boundary.
     - Direct `new Date()`, `Date.now()`, `LocalDateTime.now()`, UUIDs, random order numbers, random
       filenames, and generated referral codes hide reproducibility and future policy changes.
     - Use explicit time, generator, or identifier inputs from the shell.
-11. Draw the transaction boundary.
+12. Draw the transaction boundary.
     - When several saves happen, ask what remains if the middle save fails.
     - If the answer is unclear, use `failure-integrity-review` or the relevant database skill before
       changing behavior.
-12. Separate external calls from committed state.
+13. Separate external calls from committed state.
     - DB save, payment API, DB save, notification API in one flow creates timeout, retry, and
       duplicate-effect traps.
     - Prefer local state plus outbox, idempotency keys, or effect descriptions when the operation
       must survive partial failure.
-13. Check retry idempotency.
+14. Check retry idempotency.
     - `retry(3)`, queues, webhooks, schedulers, and manual replays are dangerous without a duplicate
       rule.
     - Ask what happens when the same event arrives twice.
-14. Reject cache-as-truth for important decisions.
+15. Reject cache-as-truth for important decisions.
     - Cache can speed reads, but it should not become the source of truth for authorization, payment
       eligibility, inventory, or other critical decisions.
     - Use `cache-integrity-review` when cache freshness or fallback can mislead the decision.
-15. Count config flag combinations.
+16. Count config flag combinations.
     - Flags such as `enableNewPolicy`, `useLegacyFlow`, `skipValidationForPartner`, and
       `specialCaseTenantIds` can create untested products inside one code path.
     - Name the supported combinations or isolate the variation behind a policy boundary.
-16. Isolate tenant, partner, country, product, and app-version exceptions.
+17. Isolate tenant, partner, country, product, and app-version exceptions.
     - Hardcoded `tenantId`, `partnerCode`, country code, app version, or product ID branches are
       product debt, not just conditionals.
     - Prefer configured capabilities, adapters, policy tables, or explicit exceptions with removal
       owners.
-17. Keep legacy compatibility out of the new core.
+18. Keep legacy compatibility out of the new core.
     - `legacy`, `old`, `v1`, `deprecated`, and `temp` branches inside the main path pull old rules
       into new code.
     - Put compatibility in adapters, translators, migration paths, or isolated old-entry boundaries.
-18. Separate data-object languages.
+19. Separate data-object languages.
     - DB entities, API DTOs, view models, external provider payloads, and domain objects should not
       quietly become the same object.
     - If one side changes and another side must follow, name the mapping owner.
-19. Give nullable values a reason.
+20. Give nullable values a reason.
     - `null` must not mean absence, unknown, failed calculation, forbidden access, and provider
       timeout at the same time.
     - Use variants, result types, or explicit fields that tell callers why a value is missing.
-20. Do not hide exceptions as normal data.
+21. Do not hide exceptions as normal data.
     - `catch (e) { return null }`, `catch (e) { log.warn(...) }`, and empty catches make the system
       lie far from the failure.
     - Use visible failure values, typed errors, or explicit degraded modes.
-21. Make logs traceable, not decorative.
+22. Make logs traceable, not decorative.
     - Logs like `start` and `failed` without order ID, user ID, request ID, external call ID, tenant,
       or operation name do not help future maintainers.
     - Add safe correlation context when it is the only way to connect the failure path.
-22. Keep tests attached to behavior.
+23. Keep tests attached to behavior.
     - Tests that assert private methods, mock call order, or internal collaborator choreography make
       refactors expensive.
     - Prefer outcomes, state transitions, persisted commands, emitted events, or public results.
-23. Treat mock count as a change-impact sensor.
+24. Treat mock count as a change-impact sensor.
     - More than three mocks deserves a responsibility review.
     - Five or more mocks usually means the class absorbs too many change directions.
-24. Validate abstraction against real volatility.
+25. Validate abstraction against real volatility.
     - Interfaces, factories, strategies, and abstract classes help only when the variation axis is
       real.
     - Ask whether there are two real implementations now or a known future swap along this exact
       axis.
-25. Do not DRY together different futures.
+26. Do not DRY together different futures.
     - Removing duplication is harmful when two similar blocks change for different reasons.
     - Keep duplication when it preserves independent policy evolution.
-26. Make required ordering explicit.
+27. Make required ordering explicit.
     - Initialization, validation, save, event publication, cache invalidation, notification, and
       cleanup steps can be order-sensitive.
     - If swapping two lines would break correctness, encode the sequence in a named workflow,
       transaction, state transition, or command object.
-27. Treat events as invisible function calls until proven otherwise.
+28. Treat events as invisible function calls until proven otherwise.
     - `publish(Event)` hides subscribers, failure behavior, ordering, duplicate delivery, and
       compatibility.
     - Name the event contract, listener expectations, idempotency, and failure handling.
-28. Pair migrations with runtime compatibility.
+29. Pair migrations with runtime compatibility.
     - Schema changes, enum additions, defaults, indexes, and backfills must be checked against old
       code on new schema and new code on old data.
     - Use `database-migration-change` when deploy order or data backfill matters.
-29. Run the deletion test.
+30. Run the deletion test.
     - Ask: "If this feature disappears, what do I delete?"
     - If flags, columns, conditions, events, caches, batch jobs, UI checks, and tests are scattered,
       the feature is already rooted too deeply.
-30. Pick the smallest boundary repair.
+31. Pick the smallest boundary repair.
     - If one owner is missing, introduce that owner.
     - If one mode is hidden, name that mode.
     - If the risk is too broad for the current task, report the exact next-change or deletion path
@@ -240,7 +251,8 @@ feature is removed, what can I delete?"
 <!-- mustflow-section: postconditions -->
 ## Postconditions
 
-- The next likely policy or workflow change has a named owner and a predictable edit path, or the
+- The next likely policy or workflow change has a named owner, historical co-change evidence when
+  available, and a predictable edit path, or the
   unpredictable spread is explicitly reported.
 - Important side effects, transactions, retries, events, caches, config flags, migrations, and logs
   have clear owners or remaining risks.
@@ -287,6 +299,7 @@ public contract.
 
 - Change blast radius reviewed
 - Next likely change and owner
+- Historical co-change evidence, or prediction-only note when unavailable
 - Files, layers, jobs, caches, events, tests, docs, or migrations in the blast radius
 - Policy, authorization, state, transaction, retry, cache, config, tenant, legacy, DTO, nullable,
   log, test, abstraction, ordering, event, migration, or deletion findings

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

@@ -0,0 +1,200 @@
+---
+mustflow_doc: skill.ci-pipeline-triage
+locale: en
+canonical: true
+revision: 1
+lifecycle: mustflow-owned
+authority: procedure
+name: ci-pipeline-triage
+description: Apply this skill when a CI/CD workflow, pipeline, job, runner, matrix, trigger, cache, artifact, deployment job, required check, or post-deploy verification is failing, skipped, queued, flaky, slow, green despite broken output, or not yet localized to trigger, runner, environment, build, test, artifact, deploy, or verification boundaries.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.ci-pipeline-triage
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - lint
+    - build
+    - test_related
+    - test
+    - docs_validate_fast
+    - test_release
+    - mustflow_check
+---
+
+# CI Pipeline Triage
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Localize CI/CD failures by splitting trigger, runner, environment, build, test, artifact, deploy,
+and verification boundaries before editing code or workflow files.
+
+The first question is not "what is the last red log line?" It is "which pipeline boundary first
+changed from the last known-good run, and what evidence would disprove each boundary hypothesis?"
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- A CI workflow, pipeline, job, matrix, required check, runner, cache, artifact, deployment step, or
+  smoke check fails, hangs, is skipped, is queued too long, passes while output is broken, or becomes
+  flaky.
+- A failure is not yet localized to trigger filters, workflow parsing, runner selection, environment
+  setup, tool versions, dependency cache, build output, test isolation, artifact transfer,
+  deployment permissions, rollout completion, or post-deploy verification.
+- A pipeline suddenly breaks without application-code changes, or only fails on forks, protected
+  branches, specific runners, specific regions, specific matrix entries, or reruns.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- The failing command is a local configured intent and CI is not involved; use `failure-triage`.
+- The deployment is already localized and the risk is rollout, rollback, probes, migrations, or
+  runtime safety; use `deployment-rollout-safety-review`.
+- The task is only test-suite speed after the CI boundary is known; use
+  `test-suite-performance-review`.
+- The task requires live production secrets, destructive deploys, cloud-console writes, or
+  unconfigured remote commands. Preserve static evidence and report the manual boundary.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- Failure classification: pipeline not created, queued, job failed, flaky rerun, succeeded with bad
+  service output, deployment failed, or post-deploy verification failed.
+- Run identity ledger: commit SHA, branch or tag, trigger event, workflow file revision, matrix
+  entry, runner label and image, architecture, region, toolchain versions, package-manager version,
+  execution time, and run or job id.
+- Last-good comparison: last successful commit and first failing commit, including workflow files,
+  lockfiles, base images, shared scripts, secrets or permission scopes, runner labels, cache keys,
+  feature flags, deployment config, and required-check settings.
+- Boundary ledger: trigger, parsed job graph, matrix expansion, queue time, runner assignment,
+  checkout, environment variables, tool setup, dependency restore, build, tests, cache, artifacts,
+  deploy, smoke, and final status aggregation.
+- Evidence constraints: redaction needs for secrets, tokens, private URLs, environment values,
+  debug logs, artifacts, and diagnostic files.
+
+<!-- mustflow-section: preconditions -->
+## Preconditions
+
+- The task matches the Use When conditions and does not match the Do Not Use When exclusions.
+- Higher-priority instructions and `.mustflow/config/commands.toml` have been checked.
+- Required CI evidence is available, or missing evidence can be reported without guessing.
+- Secrets and private data are summarized as presence, length, hash, key name, or permission scope;
+  never copy raw secret values into logs, fixtures, docs, commits, or final reports.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- Add or tighten workflow triggers, path filters, matrix guards, version pinning, cache keys,
+  artifact manifests, status aggregation, debug evidence collection, secret-safe diagnostics,
+  timeout classification, runner labels, concurrency locks, environment validation, smoke checks,
+  test isolation, docs, and focused fixtures.
+- Add tests or docs that prove workflow contract behavior, package metadata, template output,
+  release checks, artifact identity, or command-contract mapping when the repository owns those
+  surfaces.
+- Do not add broad reruns, `continue-on-error`, `allow_failure`, `|| true`, blanket cache wipes,
+  floating `latest` references, unbounded debug logging, live deploy commands, or workflow rewrites
+  before the failing boundary is localized.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. Classify the failure shape: not created, queued, job failed, flaky, green-but-bad-output,
+   deployment failed, or verification failed.
+2. Compare the last success with the first failure. Include workflow, lockfile, base image, shared
+   script, secret scope, runner, matrix, cache, environment, feature flag, and deployment changes.
+3. Preserve run identity before reruns overwrite the evidence. Record safe run id, commit, trigger,
+   runner, matrix, tool versions, queue time, start time, and artifact identity.
+4. Rerun only to test determinism. If the same commit and inputs produce different outcomes, treat
+   cache, time, order, network, shared resources, or runner state as first-class suspects.
+5. Check trigger and graph before job logs. Path filters, branch or tag filters, skipped required
+   checks, inherited workflows, matrix expansion, `needs`, and conditional steps can prevent the
+   intended job from existing.
+6. Check false green paths. Look for `continue-on-error`, allowed failures, shell pipelines that
+   ignore non-zero exits, status aggregation that only reads the final notification step, and tests
+   that upload failures as artifacts but return success.
+7. Split queue wait from execution time. Long queue time points to runner labels, concurrency
+   limits, unavailable images, resource quotas, or protected environment approvals, not build code.
+8. Reproduce in a clean environment only after the boundary is known. Prefer the same image,
+   architecture, tool versions, env shape, and lockfile over a developer machine with hidden global
+   state.
+9. Pin floating execution inputs. Base images, actions, plugins, package managers, runtime versions,
+   and shared script refs need stable identities or an explicit freshness policy.
+10. Inspect environment without leaking values. Compare variable presence, safe hashes, lengths,
+    names, permission scopes, timezone, locale, charset, clock, disk, inode, file descriptor,
+    process, and memory limits.
+11. Treat external calls as boundary evidence. Separate DNS, proxy, certificate, HTTP status,
+    retry count, response time, and credential scope, with secrets redacted.
+12. Replace sleeps with readiness evidence. Service containers, databases, queues, and app servers
+    should prove readiness through real health, query, or protocol checks.
+13. Classify cache and artifact separately. Cache is disposable acceleration; artifact is the built
+    output passed forward. Cache keys need lockfile, OS, architecture, runtime, and package-manager
+    dimensions. Artifacts need file list, size, hash, build SHA, and download verification.
+14. Verify that the tested artifact is the deployed artifact. Rebuilding during deploy can make CI
+    test one thing and production receive another.
+15. Check auth and permissions by execution context. Fork PRs, protected branches, environments,
+    OIDC identity, package publishing identity, cloud role, and repository token scopes can differ
+    across otherwise similar runs.
+16. For deployment jobs, require rollout evidence, readiness, smoke checks, error and latency
+    thresholds, and environment concurrency locks instead of treating a zero exit code as success.
+17. Preserve evidence before cleanup. Do not delete runners, caches, artifacts, temporary dirs, or
+    diagnostic logs until the boundary and redaction plan are clear.
+18. Apply the smallest localized fix and verify with the narrowest configured intent that covers the
+    changed workflow, package, docs, template, or test surface.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- The pipeline failure is localized to trigger, runner, environment, build, test, artifact, deploy,
+  verification, or a named evidence gap.
+- Last-good versus first-failure comparison, run identity, false-green risk, cache and artifact
+  behavior, permission scope, and rerun determinism are explicit where relevant.
+- Follow-up deployment, test performance, security, command-contract, or package-release work is
+  selected only after the CI boundary is localized.
+
+<!-- mustflow-section: verification -->
+## Verification
+
+Use configured oneshot command intents when available:
+
+- `changes_status`
+- `changes_diff_summary`
+- `lint`
+- `build`
+- `test_related`
+- `test`
+- `docs_validate_fast`
+- `test_release`
+- `mustflow_check`
+
+Prefer the narrowest configured intent that covers workflow docs, package metadata, template output,
+test fixtures, local reproduced behavior, or release-sensitive pipeline surfaces. Do not infer raw
+CI reruns, deploys, cloud shell commands, or provider dashboard writes outside the command contract.
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If run identity, last-good comparison, trigger graph, runner, cache, artifact, or permission
+  evidence is missing, report the missing field instead of guessing.
+- If debug logs contain secrets or private data, stop copying raw output and summarize safely.
+- If CI evidence requires remote provider access that is unavailable or unconfigured, report the
+  manual evidence boundary and continue with local workflow or static evidence.
+- If the boundary points to tests, deployment, secrets, permissions, artifacts, or command contracts,
+  switch to the narrower matching skill before editing that part.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- CI pipeline triaged
+- Failure shape and localized boundary
+- Run identity and last-good comparison
+- Trigger, runner, environment, build, test, cache, artifact, deploy, and verification findings
+- Hypotheses killed, still open, and selected follow-up boundary
+- Fix applied or recommended
+- Evidence level: provider run evidence, configured-test evidence, static review risk, manual-only,
+  missing, or not applicable
+- Command intents run
+- Skipped diagnostics and reasons
+- Remaining CI pipeline risk