You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
shipgate diff v1 across Route A: manifest-free base synthesis; the capability delta is never unavailable on first adoption; verdict only as a footer #655
P1 under #868. The application comparison route has since produced measured rows (#908), while this issue's older checklist still includes verifier-specific base synthesis and receipt semantics. Before implementing more, map each acceptance clause to current source, installed behavior and exact-ref evidence. Credit what is delivered; name any remaining verifier-specific scope explicitly. A working advisory comparison does not by itself establish a reviewed verifier base, receipt authority or the absolute historical never-unavailable promise. Keep this issue open until that reconciliation is supported.
Selected execution — 2026-09-24
Days 1–5 design is in PR #869. Head selection may seed base discovery but cannot prove old coverage or copy head inventory into base. Generated input origin must survive all evidence identities and must never become a reviewed verifier base or release authority. Refine the absolute never-unavailable target: emit established structural changes plus precise unresolved scope; unsupported/ambiguous input can legitimately remain incomplete. No reader or runtime implementation is claimed by this design. Selected after #580 in milestone 13.
The earlier advisory-release deferral below is historical. This issue is now selected for the application proof milestone; its implementation is not yet complete.
First advisory release scope — 2026-09-11
Owner decision: adoption > completeness; make v1.0 ready with repository-independent work, then expand adoption. Synthesizing a tool-source base is not required for the selected repository-declared host diff. Preserve provenance and absence semantics when this is revisited.
Removed from the selected v1.0 milestone; kept open and deferred, not resolved. #643/#644/#645/#646 define current product acceptance; #572 preserves the historical qualified no-go and #648 owns the actual publication contract. The prior evidence and acceptance below remain a record of the deferred work, not newly satisfied conditions.
Problem
On a FastMCP server repository, after init --write and three hand-filled fields, verify --base main still reports Capability delta (analysed surface): unavailable / Base status: missing_manifest because the base commit has no shipgate.yaml. The pre-existing delete_item and the newly added purge_account are reported identically. The one question a PR gate exists to answer — what did this PR add — is unanswered on the first PR of every adoption.
Proposal
When the base tree has no manifest, synthesize the base surface by applying the head manifest's tool_sources (and, absent a manifest, the discovery result) to the base tree; record base_surface_origin: synthesized_from_head_manifest in the receipt so the provenance is explicit and reproducible.
Rows carry the evidence basis (reviewed_declaration, inferred_keyword, protocol_default) so a reviewer sees what was read versus inferred.
Verdict, blockers and the control envelope render only as a footer and only when the manifest declares policy; otherwise "advisory: no policy configured".
Acceptance
S2 scenario: shipgate diff --base main names purge_account as added with severity and evidence basis, before any field is filled.
verify --base on the same repository no longer prints unavailable; Base status: synthesized_from_head_manifest.
samples/ai_generated_refund_pr and agent_weakens_gate goldens gain a diff projection; existing goldens unchanged.
Receipt and input_set_id include the synthesized-base marker; determinism tests cover it.
Acceptance reconciliation — PM review 2026-10-01
P1 under #868. The application comparison route has since produced measured rows (#908), while this issue's older checklist still includes verifier-specific base synthesis and receipt semantics. Before implementing more, map each acceptance clause to current source, installed behavior and exact-ref evidence. Credit what is delivered; name any remaining verifier-specific scope explicitly. A working advisory comparison does not by itself establish a reviewed verifier base, receipt authority or the absolute historical never-unavailable promise. Keep this issue open until that reconciliation is supported.
Selected execution — 2026-09-24
Days 1–5 design is in PR #869. Head selection may seed base discovery but cannot prove old coverage or copy head inventory into base. Generated input origin must survive all evidence identities and must never become a reviewed verifier base or release authority. Refine the absolute never-unavailable target: emit established structural changes plus precise unresolved scope; unsupported/ambiguous input can legitimately remain incomplete. No reader or runtime implementation is claimed by this design. Selected after #580 in milestone 13.
The earlier advisory-release deferral below is historical. This issue is now selected for the application proof milestone; its implementation is not yet complete.
First advisory release scope — 2026-09-11
Owner decision: adoption > completeness; make v1.0 ready with repository-independent work, then expand adoption. Synthesizing a tool-source base is not required for the selected repository-declared host diff. Preserve provenance and absence semantics when this is revisited.
Removed from the selected v1.0 milestone; kept open and deferred, not resolved. #643/#644/#645/#646 define current product acceptance; #572 preserves the historical qualified no-go and #648 owns the actual publication contract. The prior evidence and acceptance below remain a record of the deferred work, not newly satisfied conditions.
Problem
On a FastMCP server repository, after
init --writeand three hand-filled fields,verify --base mainstill reportsCapability delta (analysed surface): unavailable/Base status: missing_manifestbecause the base commit has noshipgate.yaml. The pre-existingdelete_itemand the newly addedpurge_accountare reported identically. The one question a PR gate exists to answer — what did this PR add — is unanswered on the first PR of every adoption.Proposal
tool_sources(and, absent a manifest, the discovery result) to the base tree; recordbase_surface_origin: synthesized_from_head_manifestin the receipt so the provenance is explicit and reproducible.shipgate diffextends theshipgate diffv0 on the host route: before → after, direction, why, severity;--basesynthesizes the baseline from the base tree #651 table to tool-source subjects:added tool purge_account — destructive (keyword: purge), no approval/confirmation declared — critical;modified stripe.create_refund — scope broadened …; unchanged subjects are not printed.reviewed_declaration,inferred_keyword,protocol_default) so a reviewer sees what was read versus inferred.Acceptance
shipgate diff --base mainnamespurge_accountas added with severity and evidence basis, before any field is filled.verify --baseon the same repository no longer printsunavailable;Base status: synthesized_from_head_manifest.samples/ai_generated_refund_prandagent_weakens_gategoldens gain adiffprojection; existing goldens unchanged.input_set_idinclude the synthesized-base marker; determinism tests cover it.Parent #645. Related #515 (diff-scoped verdict), #557, #403 (exclusion ledger), #470.