v0.3.3.0 — Evidence fidelity, durable execution, and self-correcting governance

IMPLEMENTAUDIT v0.3.3.0 — Trustworthy evidence, durable runs, and safer releases

v0.3.3.0 is a reliability and hardening release built from sustained use of IMPLEMENTAUDIT across real implementation, review, recovery, integration, and release work.

The release focuses on a simple question:

When IMPLEMENTAUDIT says that something
passed, changed, resumed, merged, published, or closed,
can another person verify that claim from the evidence that survived?

Real campaigns exposed concrete failure modes:
truncated logs could hide failures, shell pipelines could report the wrong exit status,
editing commands could claim success without landing the intended change,
interrupted workers could lose completed work, and remote state could be assumed instead of read back.

v0.3.3.0 turns those lessons into durable rules, checks, and recovery paths.

What changes in day-to-day use

• Verification keeps the complete output and the real producer exit status.
• Interrupted work can resume from durable state instead of replaying an entire programme.
• Long-running work can declare how it finishes, how often it should be checked, and which process or resource it owns.
• Small repairs can use a compact micro-run instead of the full campaign artifact set.
• Independent review records who or what actually performed it, what source state was reviewed, and whether the review was genuinely separate.
• Repeated defects stop being rediscovered indefinitely: they must eventually change the governing rule or acquire a durable owner.

Evidence that can support the claim being made

Verification output is treated as evidence from the moment it is produced.

Checks preserve their complete output and real exit status.
A short transcript excerpt may still be shown for readability, but it is not allowed to replace the full capture or silently change a failing verdict into a passing one.

Claims such as “all,” “none remaining,” and “N of N” must identify the population examined and explain how it was enumerated.
Partial captures, stale snapshots, and instruments that cannot distinguish their inputs cannot prove complete coverage merely because they returned green.

A phase cannot be marked complete when a declared evidence capture is missing or empty.

External state follows the same rule.
The output of a command that edits, pushes, merges, publishes, deploys, comments, or closes something is not proof that the effect landed.
The resulting object—and any automatic workflow or deployment triggered by it—must be read back from the system that owns it.

Changes prove that they actually landed

A successful editing command is no longer enough to establish that the intended change happened.

IMPLEMENTAUDIT can require explicit postconditions,
detect generated files before they are edited,
preserve deliberately duplicated implementations through parity checks,
and account for hashes or identities that a change may invalidate.

Verification also gains a stable window:
the work being checked is not silently changed underneath the running verification.

When one named concept is changed, the run can enumerate every affected
code, documentation,
state, and external-record location
before propagation.
This reduces partial updates in which different parts of the project describe different rules.

Authorisation, interruption, and recovery survive context loss

Owner authorisation is stored as durable run state and bound to its source, rather than depending only on conversation history.

Deferred, blocked, superseded, and non-verdict work remains visible.
Pending terminal actions can be resumed without replaying the entire programme.
Completed child work, partial child work, and genuinely absent work are distinguished instead of being flattened into the same “failed” state.

Provisional output can survive an interruption without being promoted into a verdict.
Owned processes and resources are recorded so recovery does not depend on guessing what a disappeared worker created.

Supported run paths now validate the run root,
and small repairs can use micro-run mode to retain the important evidence and closure rules without the full footprint of a large phased campaign.

Less supervision without weaker checks

Long-running commands can declare
terminal signals, polling limits,
reporting cadence, transport limits,
timeout behavior, kill authority,
and owned process identity.
This reduces repeated “is it done yet?” turns while preserving a clear distinction between running, timed out, interrupted, passed, and failed.

Independent units can be batched when their independence is established,
instead of paying a complete implementation-review-verification cycle for every tiny sibling change.

Verification depth is proportional to the risk being retired.
A proposed repeat verification must identify what changed or what residual risk the extra run will remove.

Before an expensive, scarce, create-once, or externally consequential launch,
the exact wrapper, path, arguments, environment, and terminal-write behavior
can be rehearsed against a safe substitute.

Independent review is now an auditable property

The canonical final lifecycle is:

6 → 6.i → 6.ii → 7

where:

• 6 is plan review and self-critique;
• 6.i is independent cold review;
• 6.ii is preflight;
• 7 is handoff or dispatch.

Legacy 6.2 → 6.i and 6.5 → 6.ii aliases remain readable for compatibility.

Independent review records
the separation, reviewer identity,
requested and resolved runtime/model identity,
reviewed source anchor, and relevant concurrent changes.
A clean verdict can no longer conceal silent model substitution, a stale review anchor, or repeated attempts using effectively the same configuration.

A deterministic refusal caused by the review packet itself is distinguished from a transient transport failure.
Sending the same packet to nominally fresh reviewers is not counted as independent progress when the failure is content-deterministic.

Free-text acceptance checks gain paired positive and negative controls.
Scored prompts cannot contain the answers they are meant to test.
Diagnostic and formal paths need parity when one is used to reason about the other,
and a measuring instrument needs a known-good signal so a broken instrument cannot manufacture a confident false result.

Repeated problems must improve the mechanism

Repeated environment quirks can be recorded and reused instead of rediscovered.

Repeated failures of the same class can mechanically trigger a review of the governing rule, rather than another indistinguishable repair attempt.
A repository defect that appears in a second independent run must acquire a durable tracker or owner, or an explicit recorded refusal.

Countermeasures state what they target, what else they might affect, and how non-target behavior was protected.
Continued repair remains allowed; what changes is that repeated evidence must eventually cause the process itself to be questioned.

IMPLEMENTAUDIT can audit its own process

Process-history and transcript-corpus retrospectives are now first-class audit objects.
They use the same evidence, census, citation, independent-review, residual, and closure rules as implementation work.

An audit of prior audits does not create an infinite hierarchy.
It is another governed audit under the same rules, with an explicit stopping boundary.

Commit history is treated as durable cross-context evidence.
Meaningful commits can record
what changed, why it changed,
the evidence anchor, the relevant boundaries,
and the finding or decision that motivated the change.

The audit playbook also gives operational proof standards for
error handling, type-strength boundaries,
duplication, dependency cycles, and dead-code claims.

Evaluator, validation, and Linux hardening

The v0.3.3.0 campaign applied the new code-hygiene rules to IMPLEMENTAUDIT’s own evaluator.

Broad exception handling and failure-reporting paths were censused.
Sites where failures could be hidden behind normal-looking results were repaired,
while legitimate fail-closed and best-effort behavior was retained and documented.

Hosted Linux validation was repaired and requalified.
The release campaign also removed a platform-specific fixture-cleanup failure,
provisioned the tools and Git history required by the tests,
and removed a timing race from child-process recovery testing.

Validation registry checks no longer rely on a false documentation-test exemption or brittle hard-coded suite counts.
Adding a legitimate test should not create a misleading release failure,
and an unregistered validation path should not silently disappear from the complete verifier.

Safer publication, integration, and release identity

A version label is no longer treated as sufficient package identity.
The source anchor, package bytes, and digest identify the release together.
Replacing bytes under an existing version requires an explicit superseded-to-superseding digest record,
and stale build artifacts cannot silently stand in for the current source.

External publication now has a governed path:
establish the intended scope, check for overlap,
make citations and source references resolvable,
obtain the required independent review and authorisation,
publish, and then read the published object back.

Pushes and merges declare the workflows, deployments, issue transitions, and other automatic effects they are expected to trigger.
Those effects are read back after the mutation.

Multi-issue campaigns declare their branch and integration topology before implementation.
Stacked integration can verify
retargeting, patch identity,
synthetic merge results, exact heads,
ancestry, and resulting trees
before proceeding.

Pull requests do not auto-close tracked issues before the evidence-first closure step.
An issue closes only after its implementation evidence is posted, the relevant state is read back, and closure is performed explicitly.

Package-budget enforcement now uses:

• a calibrated current ceiling;
• a required minimum headroom;
• a separately recorded owner outer bound; and
• a controlled calibration path.

This avoids both silent package growth and repeated emergency compression every time the asset grows by a few bytes.

Optional tools remain optional and non-authoritative

Graphify and ActiveGraph remain optional orientation tools.
They do not become proof sources or a second lifecycle authority.

Graphify is limited to the terrain-orientation capabilities supported by evidence.
Its freshness is checked mechanically, and semantic or clustering use has explicit privacy, backend, and spend boundaries.

ActiveGraph remains available for bounded checkpoint, fork, diff, or mirror assistance.
Authoritative run artifacts, live files, and independently read-back external state continue to decide correctness.

The proposed local audit dashboard is not part of v0.3.3.0 and no dashboard code is bundled into IMPLEMENTAUDIT.skill.
Work on scoped Graphify catalogs and scope-bound freshness is also future work, not a hidden feature of this release.

Qualification

The exact v0.3.3.0 package was installed and used as the IMPLEMENTAUDIT runtime during qualification.

The complete package verifier passed.
The final independent cold review passed.
The exact release candidate passed hosted Ubuntu validation and the documentation deployment checks before publication.

The release asset remains within its calibrated package budget. No dashboard code is present in the release package.

Upgrade

Copied skills do not update automatically.

Reinstall or update through the documented method for your host, then verify that the loaded runtime reports version 0.3.3.

Asset integrity

IMPLEMENTAUDIT.skill

• bytes: 215126
• SHA-256: 8ddf80e0c4545e0d66e5f81eff30a224943264a25e52a1fbb9ee0e3c3f4d778a

CHECKSUMS.txt is included for local integrity verification.

Maintainer traceability: issues represented by this release

The main release notes above are organized by user-visible behavior rather than by internal campaign order.

• Evidence fidelity and mutation integrity: #74, #75, #76, #77, #79, #88, #139
• Durable execution and lower supervision: #78, #80, #81, #82, #83, #84, #90, #137, #140
• Review, measurement, and recurrence: #85, #86, #87, #91, #92
• Meta-audit, recordkeeping, code hygiene, and optional-tool boundaries: #93, #95, #98, #99, #100, #101
• Release, validation, integration, and closure hardening: #89, #94, #96, #134, #135, #136, #138, #141, #142

Tracking or future work—not shipped as v0.3.3.0 functionality: #97, #117, #144.