Skip to content

FE-674: Plan V3.1 verification strategy + node-edit cards#119

Open
kostandinang wants to merge 2 commits into
ka/fe-674-cascade-polishfrom
ka/fe-674-plan-v3-1-verification
Open

FE-674: Plan V3.1 verification strategy + node-edit cards#119
kostandinang wants to merge 2 commits into
ka/fe-674-cascade-polishfrom
ka/fe-674-plan-v3-1-verification

Conversation

@kostandinang
Copy link
Copy Markdown
Contributor

@kostandinang kostandinang commented May 8, 2026

What

Planning-doc updates only (memory/SPEC.md, memory/PLAN.md). Records the verification strategy and node-edit cards for V3.1. No code.

Stacked on #118 per user direction (default for planning PRs is main).

Changes

  • SPEC.md gains a V3.1 oracle strategy (inner/middle/outer rings), three blind-spot entries, and a classifier-lifecycle invariant.
  • PLAN.md rewrites the V3.1 entry to land two node-edit cards before the agent backend, with build order and verification approach.

Test plan

  • CI green (memory-only)

kostandinang added a commit that referenced this pull request May 8, 2026
memory/CARDS.md is the per-branch execution queue for the next three
buildable scope cards on this frontier (ka/fe-674-cascade-edit-and-agent):

  1. Source-content snapshots on reconciliation_need (server)
     - Add source_previous_content + source_current_content TEXT NULL
     - Thread through OpenReconciliationNeedInput + edit-route hard path
     - Expose on ReconciliationNeedRecord shared type

  2. Source diff rendered inline on each Pending review row (client)
     - Reuse <ContentDiff> from FE-665
     - Render only when both snapshots are present and non-equal
     - Legacy rows (snapshots null) keep today's bare layout

  3. Edit-target affordance per Pending review row (client + reuse)
     - Inline textarea pre-filled with target's current content
     - Saves through existing PATCH /knowledge-items/:id then resolve endpoint
     - Re-entrant cascade works without reload

All three are light scope cards; promotion checklist run on each, all
stay light (no new requirements, assumptions, decisions, invariants;
all stay inside the V3.0 cascade seam).

The V3.1 agent slices (4-6) are deliberately NOT pre-queued -- they
depend on Card 3's inline-edit shape and on the LLM oracle strategy
landing in PR #119 (ka/fe-674-plan-v3-1-verification). Re-run ln-scope
for slice 4 after Card 3 ships.

CARDS.md follows AGENTS.md's sanctioned exception: it is a derivative
queue scoped to one branch and one frontier item, not canonical
narrative -- so it lives on the feature branch, not the planning PR
(per /planning-pr decision rule).
@kostandinang kostandinang force-pushed the ka/fe-674-plan-v3-1-verification branch from 51310d0 to a492dcf Compare May 8, 2026 18:59
@kostandinang kostandinang marked this pull request as ready for review May 11, 2026 09:02
@cursor
Copy link
Copy Markdown

cursor Bot commented May 11, 2026

PR Summary

Low Risk
Doc-only updates that refine the planned V3.1 reconciliation-agent lifecycle and testing strategy; no runtime behavior changes.

Overview
Updates planning/spec docs for Side-chat V3.1 to explicitly separate reconciliation_need’s durable status from new agent-driven agent_status/agent_classification and to define the intended lifecycle (null → queued → classifying → classified|failed).

Extends SPEC.md’s verification design with a three-ring approach (inner state-machine tests, middle golden-fixture corpus, outer manual cascade walkthroughs), adds the new I114 invariant, and revises PLAN.md to scope V3.1 MVP sequencing so the cascade-edit cards (inline diffs + edit-target affordance) ship before the agent.

Reviewed by Cursor Bugbot for commit 466e4cb. Bugbot is set up for automated code reviews on this repo. Configure here.

@augmentcode
Copy link
Copy Markdown

augmentcode Bot commented May 11, 2026

🤖 Augment PR Summary

Summary: Updates the V3.1 reconciliation verification plan and execution sequencing in the canonical planning docs.

Changes:

  • Extends memory/SPEC.md §Verification Design with a three-ring oracle strategy (inner state-machine tests, middle golden corpus, outer manual walkthroughs) plus related design notes/blind spots.
  • Rewrites the V3.1 entry in memory/PLAN.md to fold in the cascade node-edit cards, record build order, and link the verification approach back to SPEC.

🤖 Was this summary useful? React with 👍 or 👎

Copy link
Copy Markdown

@augmentcode augmentcode Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Review completed. 2 suggestions posted.

Fix All in Augment

Comment augment review to trigger a new review at any time.

Comment thread memory/SPEC.md
Comment thread memory/PLAN.md Outdated
@kostandinang kostandinang changed the base branch from ka/fe-674-cascade-polish to graphite-base/119 May 11, 2026 09:19
@kostandinang kostandinang force-pushed the ka/fe-674-plan-v3-1-verification branch from a492dcf to 7fc63be Compare May 11, 2026 09:20
@kostandinang kostandinang changed the base branch from graphite-base/119 to ka/fe-674-cascade-polish May 11, 2026 09:20
@kostandinang kostandinang force-pushed the ka/fe-674-plan-v3-1-verification branch from 9ed2e7b to 9e27baa Compare May 11, 2026 09:41
@kostandinang kostandinang force-pushed the ka/fe-674-cascade-polish branch from f74f37c to 37085de Compare May 11, 2026 09:41
@kostandinang kostandinang force-pushed the ka/fe-674-plan-v3-1-verification branch from 9e27baa to 642f4f7 Compare May 11, 2026 09:47
@kostandinang kostandinang force-pushed the ka/fe-674-cascade-polish branch 2 times, most recently from 41359bd to 675db5b Compare May 11, 2026 09:49
@kostandinang kostandinang force-pushed the ka/fe-674-plan-v3-1-verification branch from 642f4f7 to 387cbb5 Compare May 11, 2026 09:50
@kostandinang kostandinang requested a review from lunelson May 11, 2026 09:57
@kostandinang kostandinang force-pushed the ka/fe-674-cascade-polish branch from 675db5b to bfeff81 Compare May 11, 2026 10:04
@kostandinang kostandinang force-pushed the ka/fe-674-plan-v3-1-verification branch from 387cbb5 to 95f6976 Compare May 11, 2026 10:04
Updates memory/SPEC.md §Verification Design with the three-ring oracle
strategy for the side-chat V3.1 reconciliation classifier, and rewrites
the V3.1 entry in memory/PLAN.md §Next to fold in two adjacent
node-edit cards that ship before the agent itself.

memory/SPEC.md
  - §Oracle Strategy by Loop Tier: 3 new rows for V3.1
    - Inner: deterministic state-machine tests over agent_status with a
      stubbed classifier (queue lifecycle + label vocabulary)
    - Middle: golden-fixture corpus of (source change, target content,
      relation kind) -> expected classification, regressable across
      prompt revisions
    - Outer: manual cascade walkthroughs on dense specs comparing
      agent-grouped vs flat-list resolution -- the only ring that can
      validate A88 ("does grouping help")
  - §Design Notes: 2 new notes
    - Three-ring rationale for V3.1 classifier verification, with the
      recoverability argument (agent_proposal never auto-applied) that
      lets the inner/middle rings stay shallow
    - Cascade-edit cards (snapshots + inline target edit) are inner-loop
      only; promote a route/query ownership oracle if re-entry surfaces
      issues under manual walkthrough
  - §Acknowledged Blind Spots: 4 new entries
    - V3.1 classifier label correctness on substantive items (highest
      stakes; recoverable but not testable without ground-truth corpus)
    - V3.1 classifier multi-run determinism (single-shot first cut, no
      temperature pinning or variance characterization)
    - V3.1 cross-need correlation (per-need independence; agent cannot
      see shared root concepts)
    - Re-entrant cascade behavior under inline target edit (Card 3)

  No new A##, D###, I###, or Requirement N rows -- existing IDs cited
  but not modified, so the planning-pr hard rule on tracked-ID rows
  does not fire. Verification Design is paragraph/table-row level.

memory/PLAN.md
  - V3.1 Next entry: rewritten description folds in node-edit cards;
    explicit Linear note (FE-674, separate stacked branch); explicit
    "user has elected to proceed without V3.0 corpus signal" note.
  - Adds **Verification approach** with the three-ring summary and
    cross-reference to SPEC.md §Verification Design.
  - Adds Build order: Cards 1-3 (snapshots, inline source diff,
    Edit-target affordance) ship first; re-run ln-scope for the agent
    backend slice after Card 3.

Per the /planning-pr skill (FE-703): paragraph-level rewrites of
PLAN.md and Verification Design changes go on a planning PR. The
planning-pr default base is main; per user direction this branch
stacks on ka/fe-674-cascade-polish so the V3.1 work stays under
FE-674 rather than spawning a sibling Linear issue.

memory/CARDS.md (the per-branch execution queue for Cards 1-3) is
deliberately NOT included here -- it lives on the downstream feature
branch ka/fe-674-cascade-edit-and-agent as a per-frontier artifact,
not canonical narrative.

Verification: pre-existing structured-list-view.test.tsx failures on
the parent branch baseline (cascade-polish) are unrelated to this
memory-only change; full test suite otherwise green.
Add the I114 invariant row for the V3.1 reconciliation-agent classifier
lifecycle (the two existing 'planned I114' references in SPEC's
verification table were dangling). Spell out in PLAN that agent_status
is a separate V3.1 field from the durable status (open/resolved)
shipped in V3.0.
@kostandinang kostandinang force-pushed the ka/fe-674-cascade-polish branch from bfeff81 to d2a3611 Compare May 11, 2026 10:06
@kostandinang kostandinang force-pushed the ka/fe-674-plan-v3-1-verification branch from 95f6976 to 466e4cb Compare May 11, 2026 10:06
@kostandinang kostandinang changed the title FE-674: V3.1 verification strategy + node-edit cards in PLAN FE-674: Plan V3.1 verification strategy + node-edit cards May 11, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant