Repo health report

[claude]

Weekly maintenance run — automated repo health snapshot. This issue is updated in place by future runs rather than duplicated.

Required files (per standards.required_files)

File	Status
README.md	present
LICENSE	present
CLAUDE.md	present
docs/README.md	present

All required files present.

CI status of default branch (main @ c93b40b)

• CI (tests + shell + relay jobs) — success (2026-09-13)
• markdown-oneline — not triggered since (no .md changes on main since it merged in style(markdown): enforce one paragraph per line #112); no signal of breakage
• Dependabot update workflows — success

Two PRs landed on main since the last report: #112 (markdown one-paragraph-per-line rule + CI enforcement) and #115 (raised this repo's own max_turns to 100 so weekly maintenance can finish). Neither introduced new docs drift (checked below).

Open issues/PRs by label

15 open issues, 9 open PRs (down from 13 PRs last run — several PRs, including the draft CI-harness PR #113, have merged or closed since).

Issues: type:chore (2: this report + #114) and claude:triaged (2, same two) from the profiles/_base.yml taxonomy exist; legacy labels still dominate: agent:blocked (all 15 open issues), docs (7), P2 (8), P3 (7), ai-assist/ai-generated (6/5), size:* (12 combined). None of type:bug/feature/docs/question, priority:*, or claude:implement/in-progress/needs-human/auto-merge/skip have been created yet (see action #1, unchanged).

PRs: dependencies+javascript (6, all Dependabot bumps in /frontend — see action #2, unchanged) plus 3 unlabeled (#104/#105 pip floor-pin bumps, #84 a draft health-check PR from copilot-swe-agent).

Top 3 recommended actions

1. Bootstrap the remaining label taxonomy. profiles/_base.yml declares ~20 labels; only type:chore, claude:triaged, and the size:* set exist in this repo. Until claude:implement/claude:auto-merge/claude:needs-human/claude:skip exist, the trigger-label and gating logic in claude-implement.yml and claude-auto-merge.yml have nothing to key off. Run setup/install.sh --labels (or apply the profile taxonomy via the Labels API) — unchanged from prior runs, still open.
2. Close the stale /frontend Dependabot PRs. #88, #94, #95, #96, #97, #100 bump packages in /frontend, a directory that no longer exists (.github/dependabot.yml only configures github-actions and pip now) — Dependabot won't re-visit them and they can't merge. A human should bulk-close what's confirmed obsolete. (#104/#105, the open pytest/PyYAML bumps, are unrelated and fine — both keep this repo's floor-pin (>=) convention, just raising the floor; no action needed beyond normal auto-merge review.)
3. Resolve the open docs_drift issue, #114. Both mismatches it reports are still present as of this run: docs/workflows.md:51 still names only two of ci.yml's three jobs (missing relay), and docs/configuration.md:42-43 still document automation.review.inline_comments/review_bot_prs as live keys that no code reads. auto_fix_docs is off for this repo, so this needs a human decision (wire the keys or mark them reserved) rather than an automated fix.

Other maintenance tasks this run

• docs_drift: checked all files touched by the two PRs that landed since the last run (style(markdown): enforce one paragraph per line #112, fix(ci): raise max_turns to 100 so weekly maintenance can finish #115) — the new markdown-oneline.yml workflow was already documented in docs/workflows.md:51, and the max_turns: 100 override in this repo's own .github/githubai.yml is a per-repo config value, not a schema default, so docs/configuration.md's documented default of 50 is still correct. No new drift found; the pre-existing drift in docs_drift: workflows.md CI description and dead automation.review config keys #114 is unresolved (see action [Feature Request]: Add automated testing or feature #3).
• todo_sweep: grepped for TODO/FIXME/HACK across the codebase — none found (only self-referential mentions of the "TODO sweep" maintenance task name in docs/workflow files), nothing to file.
• dependency_report: requirements-dev.txt/pyproject.toml still use intentional floor pins (pytest>=8, PyYAML>=6), already tracked by open Dependabot PRs #104/#105. app/relay/package.json still has zero dependencies. GitHub Actions still pinned to current majors (actions/checkout@v7, actions/setup-node@v7, actions/setup-python@v7, anthropics/claude-code-action@v1). Nothing outdated or risky beyond what Dependabot already tracks; no report filed.
• stale_nudge: posted nudges on 3 issues silent 30+ days with no claude:skip/claude:needs-human label — #83, #80, #70 (all last touched 2026-08-13). No PR nudges: the only PRs silent 30+ days are Dependabot- or bot-authored (#84, #88, #94-#100, #104, #105) where a "still relevant?" ping can't get a reply — those need a human close/merge decision, not a nudge (see action [Feature Request]: Add automated testing or feature #2).

[bamr87]

🔬 Evidence bundle

No sandbox bundle was built for this issue. The intake run's evidence cap — _data/fleet.yml → issue_pipeline.evidence.max_runs: 6 — was consumed by the six issues ahead of it in the queue, so .evidence/githubai-111/ does not exist. The work order printed Evidence: already attached (Noned old) — None, which is a formatting bug in the queue generator (.github/scripts/dash-gen/issue_pipeline.py), not an attached bundle; it should say "skipped, cap reached". As written it tells the next tier that evidence exists when none does, which is worth fixing on its own.

A sandbox would not have helped here regardless — there is no failing command in this issue to reproduce. Everything below was verified against bamr87/githubai through the GitHub API.

key	value
repo	bamr87/githubai
default branch	main @ 3407e576 (2026-08-20T05:11:30Z, "feat(app): hosted multi-tenant GitHub App relay (PRD M3) (#110)")
report snapshot taken at	main @ 3407e57 — still current, no commits since
report generated	2026-08-24T06:36:34Z by claude-maintenance.yml
verified	2026-08-26 08:19 UTC
runner (intake)	Linux 6.17.0-1022-azure x86_64

---

Analysis

This issue is a self-updating dashboard, not a work item

Its first line is <!-- githubai:maintenance --> and its second says "This issue is updated in place by future runs rather than duplicated." That is not a stylistic note — it is a contract enforced by .github/workflows/claude-maintenance.yml, which runs cron: "17 6 * * 1" (Mondays 06:17 UTC) and instructs its agent:

- health_report: create or update a single issue titled "Repo health report" containing:
  required files present/missing (per standards below), CI status of the default branch,
  open issue/PR counts by label, and the top 3 recommended actions.
  Update the existing issue if it exists.

1. Dedupe before filing anything: search open issues for the marker
   `<!-- githubai:maintenance -->` and matching titles; update existing issues
   instead of duplicating. Include that HTML marker in every issue you create.

So I have deliberately not rewritten the body, and that is the one place I am departing from the tier-1 procedure. Rewriting it into the house template would be overwritten on Monday 2026-08-31, five days from now, taking any acceptance criteria tier 2 was working from with it — silently, because the maintenance agent replaces the body wholesale rather than merging. Restructuring a body that another automation owns would also make a machine-generated snapshot read as a hand-authored specification, which is worse than leaving it plain. The gaps the scan flagged — no-expected-actual, no-logs, no-acceptance — are not defects in this issue; they are categories that do not apply to a status report, and no rewrite can make them apply.

The report's claims, checked

Rather than restructure it, I verified what it asserts. It holds up:

Claim 1 — the label taxonomy is missing. Confirmed. gh label list -R bamr87/githubai returns 46 labels, and of the taxonomy profiles/_base.yml declares, exactly two exist: type:chore and claude:triaged — the two this maintenance run created for itself. Absent: type:bug, type:feature, type:docs, type:question, priority:high|medium|low, size:xs|s|m|l, and claude:implement|in-progress|needs-human|auto-merge|skip.

This matters more than "labels are missing". .github/dependabot.yml applies type:chore to both its ecosystems, and claude-implement.yml / claude-auto-merge.yml gate on trigger_label. A gate keyed to a label that does not exist never fires, and gh issue edit --add-label on an unknown label fails the whole call, taking every other label on that issue with it. So the automation this repo ships has been running against an empty keyhole.

Worth noting for whoever fixes it: this repo also carries the fleet issue-pipeline taxonomy (bug, chore, ci, docs, feature, refactor, security, test, P0–P3, size:xs–size:xl, agent:*, human-review) — 46 labels across two overlapping schemes. Bootstrapping profiles/_base.yml wholesale would add a third size axis (size:xs|s|m|l already exist) and a second priority axis (priority:high|medium|low alongside P0–P3). That collision deserves a decision before setup/install.sh --labels is run, not after.

Claim 2 — nine stale PRs. Confirmed, and the /frontend diagnosis is exactly right. gh api repos/bamr87/githubai/contents/ returns:

.claude, .editorconfig, .github, .gitignore, AGENTS.md, CLAUDE.md, LICENSE, PRD.md,
README.md, VERSION, actions, app, docs, profiles, pyproject.toml, requirements-dev.txt,
setup, template, tests, tools

No frontend/. And .github/dependabot.yml configures only github-actions and pip, both at / — no npm, no /frontend. So Dependabot will never revisit those PRs to auto-close them. All six are still open:

100  open   2026-07-21  chore(deps): bump axios from 1.13.2 to 1.18.0 in /frontend
 97  open   2026-07-17  chore(deps-dev): bump vite and @vitejs/plugin-react in /frontend
 96  open   2026-07-17  chore(deps): bump form-data from 4.0.5 to 4.0.6 in /frontend
 95  open   2026-07-17  chore(deps-dev): bump js-yaml from 4.1.1 to 4.3.0 in /frontend
 94  open   2026-07-17  chore(deps): bump postcss from 8.5.6 to 8.5.19 in /frontend
 88  open   2026-01-09  bump react-router and react-router-dom in /frontend

as are #104 / #105 (the pyyaml / pytest exact-pin bumps that fight this repo's >= floor convention) and #84 (draft, opened 2025-11-22 — now 277 days). Eleven open PRs; the two live ones are #108 and #109.

Claim 3 — CI green on main @ 3407e57. Consistent. No commits have landed since, so the snapshot has not gone stale in two days.

What is actually blocked here

The three "recommended actions" are real, well-scoped work. None of them is this issue. This issue is the place they are reported; it is regenerated weekly and cannot be closed by fixing them, because next Monday it will be rewritten with whatever the state is then.

That is the whole problem: the pipeline has queued a dashboard. It scored 21/100 and flagged nine gaps, every one of which is unclosable by construction — a status report has no expected-vs-actual, no failing log, and no acceptance criteria. Left alone, this will re-enter the intake queue every day, consume a slot, and be re-enriched forever. _data/fleet.yml caps intake at max_issues: 8 fleet-wide, so a permanent resident is a real cost to the other 183 open issues.

Labels — three overrides, stated

Computed: ci / P1 (score 58) / size:s. All three are artefacts of scoring a report as if it were a defect, so I am overriding all three:

• ci → chore. There is no CI failure here. claude-maintenance.yml succeeded; this issue is its output. The repo's own automation already labelled it type:chore, which I am leaving in place.
• P1 → P3. Nothing is broken. main is green, all required files are present, and the report itself found no docs drift, no TODO markers, and no risky dependencies.
• size:s → size:xs. There is no implementation in this issue at all. The only action it needs is a decision about how the pipeline should treat it.

Exit

agent:blocked. Sending this to tier 2 would produce a pull request against a status report.

The one question: should the issue pipeline skip self-updating bot dashboards, and how?

1. Apply agent:hold to this issue. ← recommended as the immediate step. _data/fleet.yml documents it as "human brake: excluded from every tier", which is precisely the semantics wanted. I have deliberately not applied it myself — it is documented as a human brake, and applying it would pre-empt the decision I am asking for. One label from you and this stops consuming an intake slot.

2. Exclude marker-bearing report issues at the scan. More durable: teach .github/scripts/dash-gen/issue_pipeline.py to skip issues whose body opens with a known self-updating marker (<!-- githubai:maintenance -->, <!-- fleet-doctor … -->, <!-- repo-evolution … -->). This generalises — the same shape will keep arriving from every repo that runs a weekly reporter, and [Issue Template]: Logging issue Test #52 and Add automated versioning based on commit message tags #71 in the hub are two more instances of the pipeline enriching something a bot regenerates. Costs a change to the hub's scanner.

3. Split the three recommended actions into their own issues and leave this dashboard alone. That is where the actual work is, and each one would survive tier 1 properly:

   • Bootstrap the profiles/_base.yml label taxonomy — but settle the three-way collision with the existing size:* / P0–P3 axes first.
   • Close the six /frontend Dependabot PRs plus #104/#105/#84 — verified unmergeable above; nine PRs of pure review noise.
   • Triage #59–#78 and #87 — the pre-GitHubAI-era backlog, untouched in over a year.

   I have not opened these. Tier 1 does not create work outside its queue, and [Feature Request]: Add automated testing or feature #3 is a decision about this repo's backlog, not something to infer.

My recommendation is (1) now, (2) this week, (3) as capacity allows — and note that (2) is the only one that stops this recurring across the fleet rather than just here.