Skip to content

Layer 1 API stability: PrReviewOutcome.findings type and PrVerdict constant #28

@mdproctor

Description

@mdproctor

Context

Layer 1 Part B (devtown#27) uses List<String> for PrReviewOutcome.findings and a raw "reviewed" string literal for the verdict. Both will need to change when Layer 2 introduces casehub-work bindings.

Issues

1. PrReviewOutcome.findings is List<String> — dead-end type

Layer 2 findings need provenance: which agent, which capability, what trust score. A List<String> cannot carry this. The type change will be a breaking API change if not done before Layer 2 consumers exist.

Fix: introduce a PrFinding record in review before Layer 2 ships. Minimum fields: source (capability tag), description (String). Expand in later layers.

2. Verdict "reviewed" is a raw string literal

Layer 2+ will produce typed verdict values (approved, changes-requested, declined). The raw string in NaivePrReviewService has no canonical home — a Layer 2 implementer has nowhere to look for what verdict values exist.

Fix: introduce a PrVerdict constant class (analogous to ReviewDomain) before Layer 2 ships. NaivePrReviewService uses PrVerdict.REVIEWED.

When

Before Layer 2 (casehub-work WorkItem integration) begins.

Refs #27

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions