CHANGELOG.md and .env.example are scanned by project tooling, but no
workstream owns them in .governance/manifest.json. Agents therefore either
claim paths that governance rejects or omit required release evidence
(ticket-048’s known gap).
The recommended decision is Option A: assign both paths to the existing
governance workstream. CHANGELOG.md is release/governance evidence, while
.env.example is a reviewed, non-secret environment contract enforced by
verify:env. One owner keeps their policy atomic and avoids overlapping
governance and integration scopes.
The installed manifest is managed and hash-locked to immutable
wellmanifest/new-project 0.11.0. The ownership change therefore cannot be
made as a standalone local patch. Implementation proceeds upstream-first:
wellmanifest/new-project.Option B remains a fallback only if the upstream maintainers reject the ownership model: permanently exclude both paths, make wrong claims fail closed, and designate an owned release-note surface.
The user approved ticket-049, selected Option A and authorized the upstream
work on 2026-08-08. Ticket-049 is complete. Upstream tickets 036 and 037
published the ownership contract in immutable v0.12.0. Upstream tickets 038
and 039 then published the bounded atomic-adoption contract in immutable
v0.13.0 at 12158ef0c009428deddceebb1049ddc3cb898eb3.
A read-only adoption comparison found that v0.12.0 would replace 15 managed
target files and update the customized manifest, lock and changelog. The
current policy and ticket both cap a delivery at five implementation files;
the v0.12.0 validator has no immutable-adoption accounting exception.
The managed replacement also crosses existing ownership boundaries:
scripts/runtime.sh belongs to integration, while the governance contracts
and wrappers belong to governance. The one-ticket/one-workstream rule has no
provenance-bound adoption transaction that can own this indivisible diff.
Splitting the managed-file replacement is invalid because the regenerated lock
binds the complete managed set atomically. Ticket-050 therefore returned to
PLAN / WAIT_FOR_APPROVAL before Goal changed any target file.
The revised plan is to add a narrow upstream rule for a provenance-bound, atomic standard adoption, publish that capability in a new immutable release, and then resume this target adoption. The rule must not create a general file budget bypass: it must recognize only the complete managed set bound to one published source revision, account for that managed set without transferring ordinary path ownership, and leave all target-local changes normally budgeted and owned.
That prerequisite is now complete and the user authorized continuation. This
ticket resumed IN_PROGRESS / EDIT on 2026-08-08. Its intent binds the exact
installed revision and exact v0.13.0 release revision; the seed manifest,
lock and changelog remain ordinary governance-owned implementation files.
The first downstream PR #70 passed functional, host and Docker validation but
protected Koru rejected five pre-existing complexity findings in the managed
v0.13.0 Python payload. The PR closed without merge and its branch was
preserved. Upstream tickets 040–041 reduced those findings without changing
behavior or review thresholds and published immutable v0.13.1 at
7979cfe76797a4da6925be49496ff2462e78b3f7. After explicit user approval,
ticket-050 returned from VALIDATION to EDIT to adopt that exact repair.
Protected governance then exposed one remaining caller dependency: Goal
updated the managed package and lock, but the target-local reusable-workflow
reference in .github/workflows/ci.yml still selected the pre-adoption
standard SHA 9706e63d5f121323e9087d0db47a16acdbd276bb. That resolver cannot account
for the v0.13 atomic-adoption transaction. The ticket therefore returned to
EDIT to bind both the reusable workflow and its standard-ref input to the
same exact v0.13.1 release SHA already recorded by the lock.
That alignment exposed a separate v0.13.1 protected-acquisition regression:
the restricted REST repository response omitted delete_branch_on_merge, so
the lifecycle snapshot omitted the required boolean. Upstream tickets 042–043
replaced that optional REST property with typed GraphQL acquisition and
published immutable v0.13.2 at
85631ea24d127f1f4797d2a67f3524a63cbbc95a. The approved adoption therefore
returned to EDIT for the exact v0.13.2 managed payload and caller reference.
Exact-head review passed, but the repository ruleset retained a failing
governance check from the duplicate feature-branch push run. Unlike the
pull_request and pull_request_review runs, a push event has no PR base or
number, so an atomic adoption cannot be validated against its accepted base.
The caller currently invokes the reusable governance job for both event
classes under the same required-check name. Ticket-050 therefore returned to
EDIT to run push governance only for the default branch while retaining the
PR and review gates unchanged.
The caller fix is implemented at
72549610767b07fb0f73f1ad26655f7acef70667: feature-branch pushes skip only
the duplicate governance invocation, default-branch pushes retain it, and
pull_request plus pull_request_review continue to run the protected gate.
Workflow YAML and exact-base governance pass, so the ticket returned to
VALIDATION for a fresh exact-head review.
The fresh review proved that GitHub requires every check-run sharing a required
context name to pass; a later success does not erase an earlier failure on the
same SHA. Pre-approval PR runs and automatic dismissal of a review for an old
SHA must therefore not create governance failures for the new SHA. The ticket
returned to EDIT to run governance only for submitted reviews, same-HEAD
manual dismissals, default-branch pushes and explicit dispatches.
The authoritative-event condition is implemented at
09a24f32e2f9900d2ecae1620623e2e73c6362f2. It preserves fail-closed review
submission and same-HEAD dismissal checks without creating a pre-approval
failure on a new SHA. Workflow YAML and exact-base governance pass, so the
ticket returned to VALIDATION.
Protected PR #70 then passed Koru, host, Java, Docker and governance checks.
Trusted Validator App ifuri-validator-agent[bot] approved exact head
fee491aac475ecbe6ce843d5fdbba25471c1db0e, and the ruleset reported a clean
merge state. The PR merged without bypass as
main@f60d3cc317995bc618fea1c25d9c4ec9bf09bc30; the implementation branch was
deleted and archived by Diagit. All acceptance criteria are satisfied, so the
ticket is DONE.
85631ea24d127f1f4797d2a67f3524a63cbbc95a; a repeated --check reports
the package up to date.b23d255c6bafbcc204ad7ec1e84e0a48ca675f97, including verification of both
immutable package revisions, locks and managed-file hashes.standard-ref input both select
exact v0.13.2 release SHA
85631ea24d127f1f4797d2a67f3524a63cbbc95a; workflow YAML validation and
exact-base governance pass after the alignment.make verify passed 388 tests with one controlled JDK-unavailable skip;
environment, module, generated-analysis, schema and workflow checks passed.make docker-smoke built the runtime image and passed.main@f60d3cc317995bc618fea1c25d9c4ec9bf09bc30..env.example to land an unrelated feature.verify:env fail-closed behavior.