redhat-et / redhat-et/ProtoBot

Build ProtoBot's first single-player vertical slice

Open
#66 4 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

blocked component:drafting-table component:ears-manager component:specification-toolkit component:validation-rules component:wms-adapter
Dominant language
Go
Stars
5
Forks
6
Avg merge
23h 24m
Merged PRs (30d)
66

Description

Purpose

Turn the approved architecture into the smallest runnable ProtoBot system. The slice should let a local developer use the Specification Toolkit in OpenCode, create or revise governed specification records through ears-manager, record reviewable Git history, and persist the corresponding request/work-item state through a minimal WMS boundary.

Outcome

A fixture project can demonstrate:

  • a user starts or resumes a local Drafting Table session;
  • the agent invokes a reusable Toolkit skill;
  • ears-manager validates and writes a proposed specification change;
  • Git records the governed change on a reviewable branch;
  • the WMS boundary records the request or build-work-item contract with deterministic validation;
  • all state and failure boundaries are observable in tests or a recorded demonstration.

Out of scope

  • Web Drafting Table.
  • Multiple WMS backends beyond the first GitHub-compatible path or test double.
  • Hosted OpenShift deployment.
  • Full autonomous Job Site execution before the control-plane contracts work.
  • Production-scale performance, multi-tenancy, or every prototype output type.

Related contracts

The work builds on #28, #30, #31, #32, #33, #34, #46, #56, and PRs #61 and #64. Child issues below are implementation slices, not replacements for those design contracts.

Exit criteria

  • The complete local flow is executable against a fixture project.
  • The flow has deterministic tests for valid input, invalid specification data, stale WMS mutations, and Git failure.
  • The fixture demonstrates that specification writes do not bypass ears-manager.
  • The implementation remains backend-neutral at the documented boundaries.

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 related contracts in issues #28, #30, #31, #32, #33, #34, #46 and #56, plus PRs #61 and #64. Use the fixture project and local flow described in the outcome as the investigation boundary, then verify completion against the deterministic valid, invalid, stale-WMS, and Git-failure cases in the exit criteria.

Written by the indexing model from the issue text.

Assessment

Tech stack
git, go
Domain
backend-api-design, developer-experience, testing
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.