Synthetic exampleNot customer workReport excerpt

Release Boundary Review / Sample 01

A release report should end in a decision.

This fictional excerpt shows the density, evidence references, and implementation order a buyer should expect. It is not an assessment of a real repository and does not imply that the synthetic project is secure, correct, or releasable.

Read the sample Inspect the paid scope
Synthetic boundary

Every project name, path, line reference, workflow excerpt, and finding on this page was authored as a neutral demonstration. No customer, third-party repository, private code, production log, credential, or real vulnerability is represented.

Executive readout

Do not treat the current green run as sufficient release-admission evidence.

DecisionHold

The workflow does not bind the tested package bytes to the package later published and attached to the release.

What this establishes

The synthetic configuration contains an identity break, an ambiguous attempt boundary, and no machine-evaluated admission rule.

What this does not establish

No conclusion is made about vulnerabilities, application behavior, package correctness, compliance, or production fitness.

Current decision map

The artifact changes after the evidence is produced.

  1. 01Tag pushedv* triggers release.yml
  2. 02Package A builtnpm pack in the build job
  3. 03Source testedtests run after a fresh checkout
  4. 04Package B rebuiltnpm pack runs again in publish
  5. 05Package B releasedregistry and release receive the rebuilt bytes

The visible check marks can all be green while the release still lacks an exact identity link from evaluated bytes to published bytes.

Boundary findings

Three gaps, ordered by effect on the release claim.

F-01 · High

Tested and published package identities diverge.

Release claim affected

Evidence

  • .github/workflows/release.yml:31 — build job creates northstar-relay-1.4.0.tgz.
  • .github/workflows/release.yml:58 — test job runs against a fresh source checkout.
  • .github/workflows/release.yml:91 — publish job runs npm pack again.

Why it matters

The evidence supports a source state and one packed artifact, while the release distributes independently rebuilt bytes. A green run cannot answer whether the released archive is the object that was evaluated.

Recommended boundary

Build once, record SHA-256 once, pass the exact package through tests, and publish only that immutable artifact. Fail if the expected digest is absent or changes.

F-02 · Medium

Preflight rejection and consumed publish attempt share one failure state.

Attempt accounting affected

Evidence

  • scripts/publish.mjs:44 validates tag syntax immediately before registry invocation.
  • scripts/publish.mjs:71 maps validation, timeout, and registry rejection to the same exit status.

Why it matters

An operator cannot distinguish “the real publish command never began” from “the publish command began and failed.” Retry policy therefore lacks a reliable consumed-attempt boundary.

Recommended boundary

Complete deterministic preflight before invocation, record an attempt only at the execution boundary, and emit a create-only receipt that preserves outcome and retry lineage.

F-03 · Medium

Promotion remains a convention rather than an evaluated policy.

Admission decision affected

Evidence

  • .github/workflows/release.yml:104 creates the release when prior jobs report success.
  • docs/releasing.md:22 names review expectations but no exact evidence or verifier identity.

Why it matters

Job success is substituted for an explicit rule over artifact digest, required evidence, lifecycle state, freshness, and verifier identity.

Recommended boundary

Add a fail-closed admission decision over the exact package digest, required evidence digests, approved verifier identity, acceptable state, and freshness before release creation.

Implementation sequence

Repair identity before adding more checks.

  1. P0
    Make one package the subject.

    Build once; move the exact archive and SHA-256 through test, admission, registry publication, and release attachment.

    Blocks F-01
  2. P1
    Separate preflight from the real attempt.

    Move deterministic checks ahead of invocation and create a bounded receipt at the execution boundary.

    Resolves F-02
  3. P1
    Evaluate an explicit admission policy.

    Require the exact subject, evidence, state, freshness, and verifier identity before promotion.

    Resolves F-03
  4. P2
    Harden the evidence channel.

    Add signed provenance or an external attestation system only after the local identity and decision contract are stable.

    Optional hardening

Evidence register

Every observation points back to a bounded input.

E-01.github/workflows/release.ymlSynthetic workflow · lines 1–112
E-02scripts/publish.mjsSynthetic publisher · lines 1–86
E-03docs/releasing.mdSynthetic operator guide · lines 1–39
E-04package.jsonSynthetic package contract · version 1.4.0

This excerpt intentionally omits the working notes, full evidence table, exact reproduction record, and report front matter included in a completed engagement. It demonstrates structure—not free analysis of a real repository.

Apply this structure to your repository

One public repository. One release path. One decision made explicit.

Review the $450 scope Request the $450 review