SkillsBar

Problem

The release decision could inherit stale evidence.

A changed Skill candidate could still appear safe because validation, evaluation, registry, and runtime observations belonged to an older package. The maintainer needed to know which evidence still counted before acting on a release.

Discovery

A score was context, not candidate proof.

The product could not treat a registry score or a green local check as universal readiness. Every downstream receipt had to bind to one canonical package digest, while historical and external observations remained visible only as context.

Constraints

The interface had to preserve the evidence boundary.

• Candidate identity had to be established before downstream evidence could count.
• Local validation, security, evaluation, registry, runtime, review, and release truth had to remain separate.
• Demo fixtures needed explicit labels so deterministic presentation could not be mistaken for live provider evidence.
• Provider-backed or publishing operations could not run automatically when the app opened.

Decisions

Jamie made the release logic inspectable.

• Model the journey as a nine-gate evidence chain rather than one blended readiness score.
• Hold downstream gates when the canonical candidate identity is missing or stale.
• Expose one exact next command so the maintainer can repair the weakest gate first.
• Keep the public web demo on safe mock data and state its non-production boundary.

Delivery

A native product and a public-safe explanation.

The public repository contains the SwiftUI menu-bar application, deterministic demo fixtures, package and launch routes, and a public walkthrough. The portfolio adds an interactive safe-data version that explains the same release decision without credentials or production endpoints.

Failure and correction

The first interface overstated a fixed gate.

An earlier presentation treated the focused gate too rigidly. The merged adaptive pipeline work derived the active section from receipt state, added light and dark coverage, moved scanning off the main actor, and constrained inherited shell configuration.

Outcome

The next action is visible without inventing readiness.

A maintainer can inspect why a candidate is held, distinguish current proof from historical context, and copy the next corrective command. Merged pull request 6 records a passing Swift build and 80 executed tests; it does not prove notarized distribution, external adoption, or a production registry integration.