mustflow 2.116.4 → 2.117.1

package/templates/default/locales/en/.mustflow/skills/client-platform-strategy-review/SKILL.md

@@ -0,0 +1,236 @@
+---
+mustflow_doc: skill.client-platform-strategy-review
+locale: en
+canonical: true
+revision: 1
+lifecycle: mustflow-owned
+authority: procedure
+name: client-platform-strategy-review
+description: Apply this skill when a consumer or prosumer product chooses responsive web versus mobile app first, mobile web versus PWA versus cross-platform or native clients, an app as an acquisition or retention surface, native break-even users, operating-system capability dependence, or local-first versus cloud-first desktop data ownership, offline behavior, synchronization, recovery, privacy, and client-platform investment sequencing.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.client-platform-strategy-review
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - lint
+    - build
+    - test_related
+    - test
+    - docs_validate_fast
+    - test_release
+    - mustflow_check
+---
+
+# Client Platform Strategy Review
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Choose web, PWA, cross-platform, native, local-first, cloud-first, or hybrid client architecture
+from the product job, operating-system capabilities, complete funnel economics, data authority, and
+failure recovery. Prevent platform prestige, raw install retention, or storage price from replacing
+an actual investment and usability decision.
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- A new B2C or prosumer service compares responsive web-first with iOS, Android, or another native
+  app-first launch.
+- A product compares mobile web, installable PWA, wrapped web, shared cross-platform client, or
+  separate native clients.
+- A proposal treats an app as acquisition, retention, notification, offline, device-capability, or
+  checkout infrastructure and needs a break-even user or retained-contribution model.
+- A desktop or mobile product compares local-only, local-first with sync, cloud-first with cache, or
+  server-only data ownership.
+- Offline work, device files, collaboration, multi-device recovery, conflict resolution, privacy,
+  encryption, account rights, or sync engineering changes the client strategy.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- The client platform is already chosen and the task only compares website, Microsoft Store, Mac
+  App Store, or hybrid desktop sales and distribution; use
+  `desktop-commercial-distribution-review`.
+- The task only implements one frontend framework, native bridge, service worker, cache, installer,
+  updater, mobile permission, or platform API; use the matching implementation and platform skill.
+- The task only changes synchronization algorithms, database migrations, encryption, access
+  control, backup, or privacy behavior after the authority model is fixed; use the narrower data,
+  security, privacy, migration, or architecture skill.
+- The task only selects a framework, vendor, database, or runtime; use `technology-stack-selection`.
+- The task requests current platform-law, tax, app-store contract, or consumer-rights advice. Use
+  current official policy and qualified authority; this skill supplies the decision packet.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- Product job ledger: target user, first owned value, repeat cadence, session length, acquisition
+  source, sharing, search demand, price, payer, support, accessibility, and expected retention.
+- Capability ledger: camera, location, Bluetooth, wearable, background execution, notification,
+  widgets, low-latency media, offline duration, filesystem, plugins, secure hardware, and platform
+  restrictions.
+- Funnel ledger by eligible user: impression, landing or listing visit, install or open, permission,
+  signup, first value, purchase, refund, retained use, support, and contribution.
+- Client cost ledger: design, implementation, shared and platform-specific code, QA devices,
+  accessibility, analytics parity, store review, deep links, notifications, checkout restoration,
+  OS updates, support, and decommissioning.
+- Data ledger: record and file classes, authoritative owner, size and growth, device count,
+  collaboration, offline edits, consistency, deletion, retention, export, backup, restore, audit,
+  quota, abuse, and legal authority.
+- Sync and recovery ledger: local database, change log, outbox, server replica, versioning, conflict
+  policy, stale client, duplicate, clock, tombstone, account merge, key recovery, device loss, and
+  disaster recovery.
+- Current platform ledger: operating-system and browser versions, install and notification behavior,
+  payment policy, fees, permitted commerce, signing, review, capability support, region, program,
+  source date, and confidence.
+- Experiment ledger: eligible cohort, assignment before channel choice, acquisition source,
+  capability need, platform availability, self-selection, promotion, horizon, and guardrails.
+
+<!-- mustflow-section: preconditions -->
+## Preconditions
+
+- Separate launch surface, installability, native capability, commerce, retention, and data authority.
+  One choice does not prove the others.
+- Compare web and app cohorts from the same eligible population or explicitly model self-selection.
+- Define a usable retained outcome and contribution before calculating break-even users.
+- Treat copied development multipliers, fee percentages, conversion lifts, user thresholds, storage
+  prices, and platform features as dated assumptions, not built-in defaults.
+- Refresh current platform behavior by OS, browser, region, app type, commerce type, and program
+  before changing live product or financial policy.
+- This skill does not authorize developer enrollment, app submission, payment changes, production
+  experiments, data migration, cryptographic key access, release, or deployment.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- Add or refine client strategy, capability matrices, funnel and contribution models, platform
+  sequencing, data-authority maps, offline and sync contracts, recovery and privacy policies,
+  experiments, events, fixtures, tests, docs, route metadata, and synchronized templates.
+- Add explicit handoffs to frontend, mobile, desktop, payments, store distribution, accessibility,
+  sync, database, security, privacy, backup, or migration owners.
+- Replace platform ideology, raw install comparison, gross fee arithmetic, last-write-wins data loss,
+  or local-storage marketing with explicit capabilities, economics, authority, and recovery evidence.
+- Do not fork the domain model without evidence, hide platform limitations, weaken privacy or
+  accessibility, migrate user data silently, or promise offline, sync, recovery, or encryption that
+  the current architecture cannot provide.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. Split two primary decisions: client delivery surface and data authority. A web-first launch can
+   still use local data, and a native app can still be cloud-authoritative.
+2. Classify whether the operating system is part of the product's core value. Mark required camera,
+   continuous location, Bluetooth, wearable, background, notification, widget, low-latency media,
+   filesystem, secure hardware, or offline capability and test whether the web path actually meets
+   the requirement on each target platform.
+3. Start from the smallest surface that can deliver representative first value. Responsive web is a
+   candidate when link, search, sharing, immediate trial, and one code path dominate; native-first
+   is a candidate when a required OS capability or app-native usage loop is the product itself.
+4. Treat the web as an acquisition candidate and an installed app as a retention candidate, not as
+   universal truths. Measure how each surface changes the complete funnel for the same eligible
+   users.
+5. Separate PWA layers. Decide responsive fit, manifest and install, notification, service-worker
+   caching, offline reads, offline writes, background behavior, and sync independently. Do not build
+   a complex offline layer merely to earn a PWA label.
+6. Sequence capability investment. A reversible candidate is responsive product value, then install
+   and notification for proven repeat users, then bounded offline behavior for observed need, then
+   shared or native clients when retained contribution can pay for them.
+7. Compare client costs across the full lifecycle. Include duplicated design and implementation,
+   platform QA, devices, accessibility, analytics drift, permissions, deep links, authentication,
+   payment restoration, store review, OS changes, support, and release coordination.
+8. Use D30-or-product-cadence qualified CAC, not click cost versus install cost. Count a user only
+   after representative value and the chosen retention horizon; an app install is not an accepted
+   product outcome.
+9. Calculate net contribution per eligible user. Include payment and store costs, refund, variable
+   product cost, acquisition, support, platform operations, and retention value. If native contribution
+   per user is not higher after variable costs, more users cannot repay fixed native investment.
+10. Derive break-even users from current inputs. Divide incremental fixed and step-fixed native cost
+    by incremental retained contribution per comparable active user. Include extra acquisition cost
+    and report zero, negative, or unstable denominators instead of manufacturing a threshold.
+11. Run sensitivity around the assumptions that can reverse the result: eligible paid conversion,
+    repeat use, app retention lift, store fee, price, refund, native QA cost, new-user share, and
+    channel-specific CAC. Report a range, not one magic MAU count.
+12. Correct self-selection. App users may have higher pre-existing intent. Use staged invitations,
+    matched cohorts, randomized prompts, or another defensible design before calling observed app
+    retention causal.
+13. Map data authority by class. Keep identity, billing, entitlement, organization membership,
+    quota, abuse, audit, and legal deletion server-authoritative when central enforcement is required.
+    Decide user content authority separately.
+14. Choose local-first when immediate response, offline creation, large personal files, user custody,
+    or long-lived device ownership materially creates value. Choose cloud-first when collaboration,
+    instant cross-device state, central authorization, audit, recovery, or server-side transactions
+    dominate. Treat both as candidates, not ideology.
+15. Prefer explicit hybrids. A local-first client may use encrypted replication and backup; a
+    cloud-first client should still use a durable local cache and outbox where interrupted work must
+    survive. Name the authority and failure behavior for every data class.
+16. Price local-first engineering honestly. Include local schema migration, corruption handling,
+    change logs, retry, deduplication, tombstones, stale clients, conflict UX, compatibility,
+    encryption, key recovery, export, and support. Avoid comparing that engineering cost with raw
+    object-storage price alone.
+17. Define sync semantics before choosing an algorithm. Cover concurrent edits, delete-versus-edit,
+    uniqueness, ordering, access revocation while offline, quota crossing, account merge, and old
+    client reappearance. Last write wins and CRDTs do not decide product policy automatically.
+18. Use the simplest conflict model that meets the product. Document versions, three-way merge, or
+    conflict copies can be safer than a general collaborative CRDT when simultaneous editing is not
+    a core job.
+19. Make privacy claims reconstructable. State what remains only on device, what is replicated,
+    whether the service can decrypt it, what telemetry leaves the device, how keys are stored, and
+    how loss, export, deletion, remote wipe, and recovery work.
+20. Separate confidentiality from recoverability. End-to-end or client-side encryption can reduce
+    provider access while making forgotten-key recovery harder; define recovery keys, trusted-device
+    transfer, or explicit irrecoverability without misleading promises.
+21. Measure full outcomes: eligible acquisition, first value, qualified retained use, purchase,
+    refund, support, sync conflict, lost work, recovery success, privacy complaints, platform failure,
+    and retained contribution.
+22. Promote only a reversible strategy that meets required capabilities, improves retained
+    contribution, preserves accessible and honest UX, assigns every data authority, and has a tested
+    recovery model before irreversible migration.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- Launch surface, install, native capability, commerce, retention, and data authority decisions are
+  explicit rather than collapsed into web versus app ideology.
+- Break-even uses comparable eligible users, full lifecycle costs, incremental retained contribution,
+  self-selection controls, and sensitivity ranges.
+- Every data class has an authority, offline behavior, conflict rule, privacy statement, backup, and
+  recovery owner.
+- Local-first and cloud-first claims include sync and failure cost rather than raw latency, storage
+  price, or marketing language alone.
+
+<!-- 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`, and
+`mustflow_check`. Do not infer live store, browser, mobile device, payment, notification, signing,
+submission, analytics, migration, sync, encryption, backup, recovery, deployment, or production
+commands.
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If required capabilities cannot be verified on a target surface, mark that surface unknown or
+  infeasible instead of assuming parity.
+- If comparable funnel cohorts or incremental per-user contribution are missing, report the native
+  break-even as non-decision-ready.
+- If the denominator is zero or negative, report that no finite user count repays the modeled native
+  investment under those assumptions.
+- If data authority, conflict semantics, key recovery, or lost-device recovery is undefined, do not
+  approve local-first or cloud-first migration.
+- If current store or platform policy cannot be refreshed, keep policy-dependent economics dated and
+  unverified rather than encoding them as a default.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- Product job, eligible user, first value, repeat cadence, platform, and required capability
+- Responsive web, PWA, cross-platform, and native capability and lifecycle-cost matrix
+- Comparable funnel, qualified CAC, retained contribution, break-even range, sensitivity, and
+  self-selection evidence
+- Data classes, authority, local and server state, offline behavior, conflicts, sync, privacy,
+  encryption, backup, export, deletion, and recovery
+- Current platform source and date, files changed, command intents run and skipped checks
+- Remaining client-platform strategy risk

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

@@ -0,0 +1,302 @@
+---
+mustflow_doc: skill.connection-lifecycle-integrity-review
+locale: en
+canonical: true
+revision: 2
+lifecycle: mustflow-owned
+authority: procedure
+name: connection-lifecycle-integrity-review
+description: Apply this skill when TCP sockets, HTTP keep-alive or pooling, HTTP/2 streams or sessions, Node.js streams, Web Streams readers or writers, FIN/RST handling, half-close behavior, destroy or abort races, unconsumed response bodies, backpressure, connection shutdown, transport resource leaks, fault injection, soak tests, or connection-lifetime resolution claims are created, changed, reviewed, debugged, validated, or reported.
+metadata:
+  mustflow_schema: "1"
+  mustflow_kind: procedure
+  pack_id: mustflow.core
+  skill_id: mustflow.core.connection-lifecycle-integrity-review
+  command_intents:
+    - changes_status
+    - changes_diff_summary
+    - lint
+    - build
+    - test_related
+    - test
+    - docs_validate_fast
+    - test_release
+    - mustflow_check
+---
+
+# Connection Lifecycle Integrity Review
+
+<!-- mustflow-section: purpose -->
+## Purpose
+
+Keep physical connections, transport read and write sides, logical requests, response bodies,
+reader or writer ownership, pool eligibility, and process shutdown from being collapsed into one
+misleading lifecycle flag.
+
+The central invariant is not that every connection is destroyed. Graceful FIN paths may never call
+`destroy`. The stronger invariant is that every owned connection record is finalized exactly once,
+and an abortive destroy or reset action is accepted at most once.
+
+<!-- mustflow-section: use-when -->
+## Use When
+
+- TCP, TLS, HTTP/1.1 keep-alive, HTTP/2 multiplexing, HTTP clients, servers, agents, dispatchers,
+  connection pools, upgraded sockets, WebSocket, CONNECT, or raw stream transports change.
+- Code handles `end`, `finish`, `error`, `close`, FIN, RST, timeout, abort, `destroy`,
+  `resetAndDestroy`, half-close, pending writes, drain, or shutdown deadlines.
+- A logical request, response body, body reader, stream, or HTTP/2 stream can finish or cancel while
+  its physical connection or session remains alive.
+- Response bodies can be partially read, paused, abandoned, discarded, cancelled, or left locked.
+- Slow consumers, backpressure, retries, transforms, adapters, or observability capture can retain
+  unbounded buffers.
+- A review or report claims that sockets are leak-free, safely reusable, fully drained, naturally
+  terminating, or closed exactly once.
+
+<!-- mustflow-section: do-not-use-when -->
+## Do Not Use When
+
+- The task only changes HTTP schemas, status codes, or headers with no connection, body, pooling,
+  cancellation, streaming, or shutdown behavior; use `api-contract-change` or
+  `http-api-semantics-review`.
+- The task only changes compression, CDN caching, SSE replay, WebTransport delivery choice, or proxy
+  buffering without transport lifetime risk; use `http-delivery-streaming`.
+- The task is a general retained-object or cleanup review without network or stream lifecycle
+  semantics; use `memory-lifetime-review`.
+- The task models a durable business entity lifecycle rather than independently closing transport
+  dimensions; use `state-machine-pattern`.
+- No connection, request, body, stream, pool, timer, listener, buffer, or shutdown boundary is
+  present to inspect.
+
+<!-- mustflow-section: required-inputs -->
+## Required Inputs
+
+- Protocol and role: raw TCP, TLS, HTTP/1.1, HTTP/2, WebSocket, CONNECT, client, server, proxy, or
+  adapter.
+- Ownership ledger for the physical connection or session, logical request, response body, reader,
+  writer, pool slot, timers, listeners, retry entries, and buffer reservations.
+- Event and action ledger distinguishing observed events from local actions such as graceful end,
+  cancel, destroy, reset, quarantine, pool return, or forced shutdown.
+- State dimensions for transport, readable side, writable side, pool membership, request, body
+  disposition, reader or writer lock, and server or client shutdown when each is relevant.
+- Terminal-cause policy, including which contender records the primary cause and how later causes
+  are retained for diagnostics without repeating side effects.
+- Reuse criteria, parser or framing boundary evidence, pending write state, buffered bytes, protocol
+  corruption state, and body disposition.
+- Success, half-close, timeout, abort, peer reset, writer error, reader cancel, unconsumed body,
+  slow-consumer, and shutdown paths that the implementation supports.
+- Relevant command-intent contract entries for tests, build, docs, release checks, and mustflow
+  validation.
+- For Node.js, Web Streams, or Undici-specific work, read
+  `references/node-stream-transport-lifecycle-checklist.md` before changing event-order,
+  cancellation, body-consumption, active-resource, or natural-exit behavior.
+- For repeated fault injection, soak testing, resource-growth gates, runtime or library attribution,
+  operational containment, or permanent-resolution claims, read
+  `references/connection-fault-injection-resource-lifetime-validation.md` before designing the
+  campaign or accepting its conclusion.
+
+<!-- mustflow-section: preconditions -->
+## Preconditions
+
+- Higher-priority instructions and `.mustflow/config/commands.toml` have been checked for the
+  selected repository.
+- Required inputs are available, or missing protocol and ownership decisions can be reported
+  without inventing behavior.
+- Version-sensitive runtime behavior is tied to current official documentation or repository tests;
+  supplied reference material is guidance, not proof that every runtime version behaves identically.
+- If general retained-reference risk dominates, also use `memory-lifetime-review`.
+- If races between termination contenders dominate, also use `race-condition-review`.
+- If delivery, cache, reconnect, or proxy semantics dominate, also use `http-delivery-streaming`.
+
+<!-- mustflow-section: allowed-edits -->
+## Allowed Edits
+
+- Add or tighten lifecycle state, terminal-cause arbitration, connection and request scopes, body
+  lease policy, pool quarantine, buffer budgets, shutdown phases, diagnostics, and focused tests.
+- Separate physical connection finalization from logical request and body settlement.
+- Centralize graceful-end and abortive-termination actions so timers, abort signals, writer errors,
+  and shutdown do not each perform duplicate cleanup.
+- Add bounded discard, cancellation, drain, grace, or force deadlines where protocol semantics allow.
+- Do not call `destroy` from every completion path merely because repeated destruction is a runtime
+  no-op.
+- Do not remove a connection from the active registry before its physical close event is observed.
+- Do not return a connection to a pool from writable/readable flags alone without parser or framing
+  boundary and body-disposition evidence.
+- Do not use `unref`, garbage collection, finalization registries, or process exit as connection
+  cleanup.
+- Do not weaken event-count, callback-settlement, buffer-bound, natural-exit, or open-handle tests.
+- Do not treat static review, one green reproducer, a flat RSS graph, a restart, or traffic limiting
+  as proof that a connection-lifetime defect is permanently resolved.
+
+<!-- mustflow-section: procedure -->
+## Procedure
+
+1. Draw the ownership layers before editing.
+   - Separate physical connection or HTTP/2 session, logical request, response body or stream,
+     reader and writer locks, pool lease, and process or server lifecycle.
+   - Name which layer owns each timer, listener, pending callback, retry item, buffer reservation,
+     and registry entry.
+2. Replace a single closing enum with orthogonal dimensions where shutdown can happen
+   independently.
+   - Model transport, read side, write side, pool membership, request state, body disposition, and
+     reader or writer ownership separately when the protocol permits independent progress.
+   - Treat remote and local half-close as valid combinations, not impossible intermediate states.
+3. Separate events from actions.
+   - Treat EOF or `end`, write completion or `finish`, `error`, and physical `close` as observed
+     events.
+   - Treat graceful `end`, cancel, discard, quarantine, `destroy`, reset, and force-close as local
+     actions whose admission must be controlled.
+   - Do not require an abortive action on a graceful path.
+4. Centralize terminal-cause arbitration.
+   - Route timeout, abort signal, writer error, protocol error, peer reset, body abandonment, and
+     forced shutdown through one termination admission function.
+   - Atomically accept the first terminal cause and at most one abortive action.
+   - Record later competing causes as secondary diagnostics without repeating destroy, reset,
+     callback settlement, metrics, or registry removal.
+5. Define finalization boundaries.
+   - Finalize and remove a physical connection record once, after physical close is observed.
+   - Permit a request to settle earlier after its request-scoped timers, listeners, retries, body
+     lease, and user result are finalized.
+   - Keep connection-core close and error observation alive even after request cleanup.
+6. Write the protocol-specific reuse gate as a conjunction of observable conditions.
+   - Require open transport sides, parser or framing boundary, terminal body disposition, no pending
+     writes, no reserved buffers, no terminal cause, no protocol corruption, and correct pool owner.
+   - Quarantine any HTTP/1.1 connection that observed premature close, truncated framing, parser
+     failure, content-length mismatch, reset, or unrecoverable body abandonment.
+   - Apply cancellation and reuse at HTTP/2 stream scope unless connection-level GOAWAY, session
+     error, or flow-control corruption invalidates the whole session.
+7. Give every response body a disposition and deadline.
+   - Require consume, bounded discard, protocol-specific cancel, or failure.
+   - Use both byte and wall-clock limits for discard; endless discard is a denial-of-service path.
+   - Settle cancellation separately from releasing a reader lock, and release the owner in a
+     finally-like boundary.
+8. Make write and backpressure accounting explicit.
+   - Stop or pause production after a write or enqueue signal reports backpressure.
+   - Settle every accepted write callback or promise exactly once as success or failure.
+   - Reserve bytes before enqueueing across readable, writable, adapter, parser, transform, retry,
+     discard, and observability layers; do not mistake a high-water mark for a global hard limit.
+9. Build connection and request resource scopes.
+   - Register timers, listener removers, retry tokens, body leases, locks, pending writes, buffer
+     reservations, and close waiters at creation time.
+   - Make disposal idempotent and keep request cleanup from deleting connection-core observers.
+10. Define server and client shutdown as bounded phases.
+    - Stop new accepts or requests first, then drain idle and active work, reject new HTTP/2 streams
+      when applicable, escalate after a deadline, and wait for physical closes.
+    - Track WebSocket, CONNECT, HTTP/2, and other upgraded or separately owned transports explicitly;
+      generic HTTP close-all helpers may not own them.
+11. Add observable conservation and cleanup invariants.
+    - Compare created, active, and closed connections; started and terminal requests; accepted and
+      settled writes; opened and disposed body leases; reserved, current, and released buffers.
+    - Keep identifiers in logs or traces and metric labels bounded to reason, protocol, role, or
+      mode.
+12. Test races and partial orders, not one pretty sequence.
+    - Cover local-first, remote-first, simultaneous FIN, RST, timeout plus abort, pending write plus
+      reset, body end plus cancel, paused read, unconsumed body, slow consumer, and shutdown races.
+    - Assert event counts, primary cause, accepted destroy count, request result, pool state,
+      registry size, pending writes, body disposition, lock ownership, and peak reserved bytes.
+    - Add a child-process natural-exit test without `process.exit` when configured test surfaces can
+      exercise event-loop handle leaks.
+13. Separate heap retention from event-loop liveness and native resource leakage.
+    - An unresolved promise alone does not keep the event loop alive, but a reachable promise chain
+      can retain request state.
+    - Check active timers, sockets, DNS/TLS work, file descriptors or handles, and heap retaining
+      paths with the configured diagnostics available to the repository.
+14. Design fault campaigns around closed cohorts and uncontaminated resource evidence when the task
+    requires more than focused lifecycle tests.
+    - Separate the system under test from load generators, raw fault peers, proxies, and packet or
+      network injectors so their timers and handles do not enter the system ledger.
+    - Give each request deterministic bytes, digest, idempotency identity, lifecycle timestamps, and
+      exactly one terminal outcome; compare clean and faulted traffic under predeclared load, seed,
+      duration, and statistical gates.
+    - Keep explicit-agent teardown campaigns separate from pool-reuse steady-state campaigns.
+15. Attribute the owner with differential reproduction before choosing a fix.
+    - Repeat the same fault schedule through the full application, a library-only reproducer, a
+      runtime-core reproducer, and direct versus production-like network paths where available.
+    - Classify application, library, runtime, or environment cause only from the layer where the
+      failure appears or disappears, retaining-path evidence, version bisect, or reproducible
+      infrastructure mechanics.
+16. Calibrate the conclusion to the evidence.
+    - Distinguish fix candidate, mitigation, symptom suppression, and permanent resolution.
+    - Require pre-fix failure, post-fix success, compatible correctness and performance regression,
+      bounded repeated and soak evidence, and a causal owner before claiming permanent resolution.
+    - Treat long-running soak, packet, native-handle, heap, or production-path checks as manual-only
+      or missing unless the selected repository configures them.
+17. Verify through configured command intents and report unavailable protocol, fault-injection,
+    active-resource, heap, file-descriptor, or natural-exit evidence instead of inventing commands.
+
+<!-- mustflow-section: postconditions -->
+## Postconditions
+
+- Physical connection, request, body, stream, lock, pool, and shutdown ownership are distinct where
+  their lifetimes can diverge.
+- Every connection record has one observable finalization path; graceful paths do not require
+  destroy, and abortive paths accept at most one destroy or reset action.
+- Primary terminal cause, secondary contenders, event counts, callback settlement, and registry
+  removal are deterministic under supported races.
+- Connection reuse requires framing completion, terminal body disposition, clean transport state,
+  zero pending writes or reservations, and protocol-specific eligibility.
+- Response bodies, locks, timers, listeners, retries, buffers, and upgraded connections have bounded
+  ownership and shutdown behavior.
+- Tests or explicitly reported evidence gaps cover the highest-risk FIN, RST, timeout, abort,
+  cancellation, backpressure, and shutdown paths.
+- Fault and soak conclusions preserve the tested protocol, role, environment, cohort, seed,
+  duration, measurement gate, and causal-owner boundary instead of generalizing from one run.
+
+<!-- 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 tests that exercise the changed protocol and lifecycle boundary.
+Do not infer raw packet tools, load generators, heap profilers, active-handle inspectors, open-FD
+commands, or child-process harnesses from this skill.
+
+<!-- mustflow-section: failure-handling -->
+## Failure Handling
+
+- If protocol and ownership boundaries are unknown, stop and list the missing decisions before
+  inventing a universal state machine.
+- If observed event order differs across valid runs, encode the supported partial order and event
+  counts instead of forcing one total order.
+- If a second termination contender repeats side effects, centralize admission before patching each
+  callback independently.
+- If safe reuse cannot be proved from parser or framing and body evidence, quarantine the connection.
+- If a body cannot be consumed, discarded, or cancelled within bounds, fail the body and retire the
+  owning stream or connection at the narrowest safe protocol scope.
+- If shutdown passes only after adding `unref` or `process.exit`, keep the test failing and report the
+  live handle or missing owner.
+- If exact runtime behavior is version-sensitive and current official evidence is unavailable,
+  narrow the claim and report the freshness gap.
+- If a reproducer turns green without retained-owner, handle, version, or infrastructure evidence,
+  report a fix candidate rather than a resolved root cause.
+- If only traffic limiting, isolation, version pinning, or process restart prevents exhaustion,
+  report mitigation and preserve the unresolved ownership risk.
+
+<!-- mustflow-section: output-format -->
+## Output Format
+
+- Protocol, role, and ownership layers reviewed
+- Transport, read, write, pool, request, body, lock, and shutdown states
+- Event versus action ledger
+- Primary and secondary termination-cause policy
+- Finalization and destroy or reset admission result
+- Reuse and quarantine gate
+- Body disposition, reader or writer ownership, and backpressure or buffer budget
+- Resource scopes, timers, listeners, retries, registries, and upgraded transports
+- Shutdown phases and escalation deadline
+- Invariants, fault matrix, event counts, and natural-exit or active-resource evidence
+- Harness isolation, closed-cohort ledger, repeated-fault and soak gates, and clean-traffic isolation
+- Application, library, runtime, or environment attribution evidence
+- Fix candidate, mitigation, symptom suppression, or permanent-resolution classification
+- Command intents run
+- Skipped diagnostics and reasons
+- Remaining connection lifecycle risk