Docs: RepoMan architecture spec (multi-owner input model) - #67
Conversation
Publish the RepoMan architecture agreed in the 2026-08-27 design session as a
review-only spec so teammates can comment before implementation begins. Captures
the discovery/onboarding/configure/schedule interface, the per-repo {owner, name}
input model that replaces single-$ORG, state and persistence layers, the stateless
skill layer, and the DAM/OpenClaw deployment split.
Motivated by discussion rossoctl#62 (owner-model portability) and issues rossoctl#65 and rossoctl#39.
Assisted-By: Claude Code (Anthropic AI) <noreply@anthropic.com>
Signed-off-by: Gloire Rubambiza <gloire@ibm.com>
mrsabath
left a comment
mrsabath
left a comment
There was a problem hiding this comment.
Clean, well-structured architecture spec. Documentation only — no code or behavior changes.
Every factual claim about the current system was verified against the repo: the dashboard's hardcoded link-scan/ and dep-bump/ paths (LINK_SCAN_DIR/DEP_BUMP_DIR in automation-health-dashboard.sh), the standing-orders/repo-sync.md standing order, the FORK_OWNER → clawgenti fallback in scripts/org.sh, and all three cross-references (discussion #62, issues #65 and #39) are accurate and correctly linked. The per-{owner, name} input model, the durable/persistent/ephemeral state tiers, and the DAM/OpenClaw deployment split are coherent and consistent with the referenced portability discussion.
Areas reviewed: Docs (spec accuracy, internal consistency, cross-references), commit/PR conventions, CI status
Commits: 1 commit, signed-off: yes (DCO passes)
CI status: passing (all 5 checks)
One non-blocking suggestion inline. Nice work.
| ## Automation health dashboard | ||
|
|
||
| The dashboard is a consumer of the other programs' reports, not a scanner itself. Today it has | ||
| hardcoded paths to `link-scan/latest.json` and `dep-bump/latest.json`. Under RepoMan it reads |
There was a problem hiding this comment.
The new design consistently names the report directory link-health (invocation flow, the state diagram, and the _index.json report_path), while this section correctly notes the existing dashboard hardcodes link-scan/latest.json — which does match the current on-disk name (REPORTS_DIR/link-scan, LINK_SCAN_DIR in automation-health-dashboard.sh, and the scanner's own REPORTS_DIR=…/reports/link-scan).
So the spec is internally consistent about this being a rename. But since this is the one place the old and new names sit side by side, consider a one-line explicit note that link-scan → link-health is an intentional rename under RepoMan. That way an implementer migrating the dashboard to the _index.json lookup won't mistake the mismatch for an oversight. Suggestion only — not blocking.
2 participants
Summary
Publishes the RepoMan architecture as a review-only spec at
docs/specs/2026-08-27-repoman-architecture.md, agreed in the 2026-08-27 designsession. RepoMan wraps the existing scanner/fixer programs behind a discovery and
configuration interface, replacing the single-
$ORGplus flat$REPOS_DIRidentitymodel with per-repo
{owner, name}tuples drawn from a user-managed list. That lets onedeployment cover any mix of org and user repos, which is the portability gap raised in
the discussion below.
This is documentation only. No code changes, and no program behavior changes. The intent
is to give the team a single URL and a comment thread to weigh in on before implementation
begins.
What the spec covers
{owner, name}input model that replaces single-$ORG$HOME, ephemeral)## RequirementsblocksContext
The implementation plan and epic sub-issues will be filed after this spec merges, so the
dependency graph references a stable spec doc.
Assisted-By: Claude Code