redhat-et / redhat-et/ProtoBot

Create a cross-project evaluation corpus for requirements and Job Site conformance

Open
#135 2 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

blocked component:job-site component:specification-toolkit enhancement
Dominant language
Go
Stars
5
Forks
6
Avg merge
23h 24m
Merged PRs (30d)
66

Description

Purpose

Create a versioned, representative evaluation corpus for ProtoBot's
requirements elicitation and autonomous Job Site flow.

The corpus should make it possible to answer two separate questions:

  1. Did ProtoBot convert a free-form project description into a complete,
    correct, implementable set of requirements?
  2. Can the Job Site turn a known-good requirements set into a working,
    behaviorally conformant prototype?

The combined pipeline should also be runnable, but its scores must remain
attributable to the elicitation and building stages separately.

Scope

  • Define a versioned fixture format containing:
    • a free-form project description;
    • golden Vision and Architecture artifacts;
    • a golden set of EARS requirements;
    • interface and runtime metadata;
    • reference behavior tests and evaluation metadata.
  • Seed representative projects, initially including:
    • a command-line application;
    • a server-side API application;
    • a web application.
  • Build or integrate evaluation runners for:
    • semantic comparison of generated requirements against the golden set;
    • Job Site execution from golden requirements;
    • end-to-end execution from the free-form description.
  • Record reproducible inputs, outputs, model/settings metadata, traces, scores,
    failures, and corpus revisions.
  • Keep holdout behavior tests outside the generator-visible fixture inputs so
    the Job Site cannot optimize directly against the evaluator.

Evaluation rules

  • Compare requirements by behavior, coverage, applicability, and
    implementability, not exact wording.
  • Treat missing requirements, unsupported additions, false readiness, and
    implementation leakage as explicit failure categories.
  • Use the golden requirements as the stable Job Site input baseline.
  • Score prototype behavior with hidden conformance tests appropriate to each
    interface type.
  • Preserve per-case evidence so aggregate scores cannot hide critical failures.
  • Calibrate human or semantic judges before promoting a corpus revision as a
    trusted baseline.

Dependencies

  • Blocked by #63 for the calibrated requirements-evaluation baseline and
    judging conventions.
  • Blocked by #69 for the deterministic Worker/Triage fixture execution path.
  • Blocked by #79 for the executable Job Site sandbox contract.
  • Related to #66 and #77, which provide the local vertical slice and
    replayable Drafting Table flow that this corpus should exercise.

Out of scope

  • Production applications or production-quality code.
  • Benchmarking model latency or cost as the primary objective.
  • Supporting every language, framework, or interface type in the first corpus
    revision.
  • Replacing the existing requirements-skill corpus in #63.
  • Making exact generated source-code comparison the success criterion.

Acceptance criteria

  • The fixture schema and versioning policy are documented.
  • At least three projects covering CLI, server-side API, and web application
    interfaces are committed with free-form descriptions and reviewed golden
    artifacts.
  • Each project has behavior-level reference tests, including hidden holdout
    tests for Job Site evaluation.
  • A headless run produces separate requirements, Job Site, and end-to-end
    results with per-case evidence.
  • Repeated evaluation of unchanged inputs is reproducible within documented
    nondeterminism limits.
  • A corpus change records rationale, reviewer/calibration evidence, and its
    effect on the prior baseline.
  • The corpus can run locally without a hosted cluster or external service
    credentials.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reading the dependency issues #63, #69, and #79, then review related work in #66 and #77 to understand the available evaluation and execution paths. Define the versioned fixture schema, seed CLI, server-side API, and web projects, and specify separate reproducible requirements, Job Site, and end-to-end results with per-case evidence. Done means the documented corpus runs locally with hidden holdout tests and records revision rationale and baseline impact.

Written by the indexing model from the issue text.

Assessment

Tech stack
go
Domain
testing-qa
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
28/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.