Skip to content

vscode: generalize viewPlanFile to siblings (viewSpecFile, viewReviewFile) with protocol-aware menu visibility #793

@amrmelsayed

Description

@amrmelsayed

Problem

codev.viewPlanFile (commands/view-artifact.ts:29, registered in extension.ts:539) is restricted to PIR builders only via the menu when clause (viewItem =~ /^(builder|blocked-builder|awaiting-builder)-pir$/). Other protocols that produce on-disk artifacts of the same shape (SPIR/ASPIR/PIR plans; SPIR/ASPIR specs; SPIR/ASPIR/AIR reviews) have no equivalent quick-open path. The audit also flagged this as the only protocol-gated artifact command in an otherwise protocol-agnostic menu set.

Current state

  • view-artifact.ts is already generic-ready: ArtifactKind = 'plan' (line 23) and ARTIFACT_SUBDIR: Record<ArtifactKind, string> = { plan: 'codev/plans' } (line 26). The dispatcher viewArtifact(connectionManager, builderIdArg, kind) (line 36) does all the work; only plan is wired.
  • A deliberate comment at view-artifact.ts:13–14 says "View Review File was intentionally not added: the review file is the PR body in PIR's review phase, so reviewers read it on GitHub." This rule needs updating now that other protocols ship review files on disk and vscode: builder row → expandable phase children, each phase reveals its artifact (spec / plan / diff / review) #792 wants tree-driven access to them.
  • File-naming convention is <id>-<slug>.md across codev/specs/, codev/plans/, and codev/reviews/ — the existing filter logic works for all three with no change.

Proposed behavior

1. Extend view-artifact.ts

  • ArtifactKind = 'plan' | 'spec' | 'review'.
  • ARTIFACT_SUBDIR = { plan: 'codev/plans', spec: 'codev/specs', review: 'codev/reviews' }.
  • Register two new commands: codev.viewSpecFile, codev.viewReviewFile, each delegating to viewArtifact(...) with the matching kind.

2. Protocol-aware menu when clauses

Encode each command's visibility using the existing viewItem regex pattern:

Command Appears for
codev.viewSpecFile SPIR, ASPIR
codev.viewPlanFile SPIR, ASPIR, PIR
codev.viewReviewFile SPIR, ASPIR, AIR, PIR (PIR with the file-or-hide rule below)

Update the existing PIR-only when on viewPlanFile to include SPIR and ASPIR.

3. PIR review handling

For PIR builders specifically: viewReviewFile opens the on-disk codev/reviews/<id>-<slug>.md if it exists. If the file does not exist, the menu entry hides for that row (rather than fallback-opening the PR). This requires the row's contextValue to encode "has-review-file" so the when clause can gate visibility.

For non-PIR protocols, the existing missing-file toast handles absence (no menu hiding needed since these protocols always produce a review file by convention).

4. Remove the deprecated comment

Strike view-artifact.ts:13–14; replace with a one-line note that PIR reviews fall back to "menu hides if file absent" — the new rule.

Acceptance criteria

  • ArtifactKind extended to 'plan' | 'spec' | 'review'; ARTIFACT_SUBDIR covers all three.
  • Two new commands registered: codev.viewSpecFile, codev.viewReviewFile, both delegating to viewArtifact.
  • view/item/context menu entries for Builders updated with protocol-aware when clauses per the table above.
  • PIR rows that have a review file on disk show viewReviewFile; PIR rows without one hide the entry.
  • Existing PIR-only behavior for viewPlanFile extended to SPIR/ASPIR without regressing PIR.
  • Stale comment about "View Review File was intentionally not added" removed.
  • Unblocks vscode: builder row → expandable phase children, each phase reveals its artifact (spec / plan / diff / review) #792 (phase children call these commands to reveal artifacts).

Out of scope

  • A fallback path that opens the PR URL when the review file is missing (intentionally rejected in favor of menu-hiding for PIR).
  • Adding viewSpecFile for protocols that don't produce specs (BUGFIX, MAINTAIN, etc.).
  • A generic "View Artifact" picker that lets users choose kind at invocation time.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type
No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions