obot.roadmap · proposal for review · 2026-07-04

A thinner harness: safety.agent on gsm.agent

Two Requirements that rebuild safety.agent as a thin project overlay on the gsm.agent base harness, then stand up the autonomous lanes the July consolidation retired. Approved and posted 2026-07-04 as #17 and #18.


Where things stand

gsm.agent has a published roadmap

v0.1 (end of July 2026): agent personas for all three pillars. v1.0 (Q3): bot identities live, per-agent skills libraries, formalized handoffs. Autonomy stance: "Ops & Roadmap rollups autonomous · rest interactive."

safety.agent is a second full harness

Written pre-consolidation: its own conventions, 8 skills, test framework, interview framework. Much of it restates gsm.agent ground; its remote still points at the archived obot-claw org.

The enablers just landed

Hub lifecycle is live on obot.roadmap. Issue #3 (obot GitHub App obotclaw) has an approved design — and explicitly deferred scheduled agentic runs to a separate Requirement.

The layering model

Today — two parallel harnesses
safety.agent Own mission, conventions, approval gates, TDD rules, 8 skills — overlapping gsm.agent, drifting as upstream evolves
gsm.agent Conventions + skills, actively developed, separately restated above
Proposed — base + thin overlay
safety.agent · overlay Only the safety-graphics layer: GxP stance, renderer skills, requirement matrices, interview logs
gsm.agent · base All shared conventions (drafts, attribution, approval gates, worktrees, TDD) + shared skills (tdd, issue-review, sub-issue-linking); generic safety.agent pieces contributed upstream where Gilead accepts them

The obot2 workspace already imports the gsm.agent clone's AGENTS.md — the inheritance mechanism exists. This proposal makes safety.agent honor it instead of duplicating it, which also answers the gsm.agent roadmap's open "shared scaffolding location" question in practice: obot becomes the first external consumer of gsm.agent as a base harness.

Alignment with the gsm.agent roadmap

gsm.agent plans
obot mirrors it with

v0.1 — parallel agent personas per pillar; workspace conventions stay in AGENTS.md, agent-specific bits extracted

R1 below — safety.agent restructured as the project persona/overlay; conventions inherited, not restated

v0.1 → v1.0 — bot identity plan, then bots live (@gsm-roadmap-bot, @gsm-dev-bot)

#3 (already approved) — the obotclaw GitHub App is obot's bot identity

v1.0 — Roadmap rollups autonomous; richer skills (/regression-sweep, /security-review, release helpers)

R2 below — scheduled rollups, diary, event-driven responder, background dev lane under the App identity

Requirement 1 — posted as #17

obot.roadmap #17 · open

Rebuild safety.agent as a thin overlay on the gsm.agent harness

requirement infrastructure ai milestone · 2026q3

Business requirement

Two harnesses means every gsm.agent improvement is either manually mirrored or silently drifts, and it is ambiguous which rulebook wins. Direction: leverage gsm.agent as much as possible; safety.agent carries only project-specific instructions. Success: one source of truth, upstream improvements flow through without copying, no stale obot-claw references.

Overview

  • Audit and classify every safety.agent artifact: duplicates → deleted with a pointer upstream; generic-but-useful (split-phase test-driver, stakeholder-interview workflow) → proposed to gsm.agent via PR; project-specific (GxP stance, renderer skills, requirement matrices) → kept, restructured.
  • Restructure as the overlay: an explicit "gsm.agent conventions apply; this adds the safety-graphics layer" contract.
  • Housekeeping: remote retargeted to jwildfire/safety.agent; obot-claw-era URLs and the stale staging-fork write policy swept out.

Posted 2026-07-04 · draft archived at .github/drafts/obot.roadmap/ISSUE_17_agent-overlay.md

Requirement 2 — posted as #18

obot.roadmap #18 · open

Autonomous obot operations — scheduled and event-driven agent runs

requirement infrastructure ai milestone · 2026q3 depends on #3

Business requirement

The goal is increased automation, but today nothing runs unattended: the diary routine is paused for lack of a push identity, hub status is updated by hand, and all work is interactive. This is the Requirement that #3 explicitly deferred — the runs that use the App identity it created. The operating contract holds: bots draft, report, and update status; Jeremy approves and merges.

Candidate lanes (final slate chosen in Design)

LaneTriggerWritesHuman gate
Requirement rollupScheduleStatus comments on open RequirementsNone — report only
Nightly diarySchedule, active days onlyobot.roadmap/diary/Pre-authorized policy (2026-07-01)
@claude responderPR / issue eventsComments, review replies, checksJeremy merges
Background dev laneLabeled issueWorktree branch + draft PRPR review

Posted 2026-07-04 · draft archived at .github/drafts/obot.roadmap/ISSUE_18_autonomous-ops.md · Cross-cutting: a lane runbook in safety.agent — identity, trigger, scope, kill switch per lane

Not duplicated here: bot identity itself (#3, design approved), QC test tooling (#15), and the renderer work these serve (#1, #2, #9).

Open questions

Q1

File as two issues, or merge into one harness Requirement?

Recommend two — R1 is self-contained restructuring; R2 depends on #3 and will run on a different clock.

Q2

Milestones: both 2026q3?

Recommend yes — R1 tracks gsm.agent's July v0.1; R2 follows #3, which is already 2026q3 with design done. Fallback for R2 is 2026q4.

Q3

Upstream contributions: propose the generic safety.agent pieces to Gilead's gsm.agent via PR, or carry them in safety.agent for now?

Recommend offering upstream (it's their roadmap's open question) with safety.agent as the fallback home until accepted — R1 is written that way.

Q4

R2 lane slate: all four lanes in scope, or trim?

The rollup and diary are low-risk report-only lanes; the responder and background dev lane are the real autonomy step. Design can stage them, but say now if any lane is out.

Next steps

  1. Done — both drafts approved and posted (#17, #18); Q1–Q4 resolved per the recommendations. Diary entry for the day is PR #19.
  2. @jwildfire: 👍 #17 and #18 to advance them from Requirement Gathering into Design; merge diary PR #19.
  3. Each Requirement then enters the design phase (requirement-design) per the hub lifecycle — #18 implementation additionally waits on #3.