Filed from infra#265, which is closing — brain-mcp's code lives here, not in infra.
Where this actually lives
Confirmed 2026-08-11 from koala:
kubectl get ingress -A | grep brain-mcp → supervisor/ingestion serves brain-mcp.d-ma.be
kubectl get deploy -n supervisor ingestion → Ready 1/1, age 111d
source → config/supervisor + ingestion/internal/claudewatcher
So brain-mcp is a component inside hyperguild's ingestion service, not a standalone deployable. The original issue's "can't find where this code lives" complaint was accurate — that's the finding, not a side note.
Part 1 — the bug
capture with a tickets array fails. Callers currently fall back to N individual issue_create calls: no data loss, but N round-trips instead of one.
Reproduce with a tickets array of length 1
Either fix the array path or strip the field from the schema — a schema field that always fails is worse than an absent one, because callers write code against it
Regression test at length 1 and length > 1
Part 2 — the repo question (decide, don't build)
Should brain-mcp graduate to mathias/brain-mcp? Zero runtime blast radius either way; this is purely about whether a service with its own public ingress and its own consumers should be discoverable at its own name. Worth deciding rather than leaving implicit — the discoverability problem is what generated the original issue.
Refs
infra#265 (closed)
infra docs/superpowers/specs/2026-08-11-backlog-verification.md
Filed from infra#265, which is closing — brain-mcp's code lives here, not in infra.
## Where this actually lives
Confirmed 2026-08-11 from koala:
```
kubectl get ingress -A | grep brain-mcp → supervisor/ingestion serves brain-mcp.d-ma.be
kubectl get deploy -n supervisor ingestion → Ready 1/1, age 111d
source → config/supervisor + ingestion/internal/claudewatcher
```
So brain-mcp is a component *inside* hyperguild's `ingestion` service, not a standalone deployable. The original issue's "can't find where this code lives" complaint was accurate — that's the finding, not a side note.
## Part 1 — the bug
`capture` with a `tickets` array fails. Callers currently fall back to N individual `issue_create` calls: no data loss, but N round-trips instead of one.
- [ ] Reproduce with a `tickets` array of length 1
- [ ] Either fix the array path or strip the field from the schema — a schema field that always fails is worse than an absent one, because callers write code against it
- [ ] Regression test at length 1 and length > 1
## Part 2 — the repo question (decide, don't build)
Should brain-mcp graduate to `mathias/brain-mcp`? Zero runtime blast radius either way; this is purely about whether a service with its own public ingress and its own consumers should be discoverable at its own name. Worth deciding rather than leaving implicit — the discoverability problem is what generated the original issue.
## Refs
- infra#265 (closed)
- infra `docs/superpowers/specs/2026-08-11-backlog-verification.md`
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Filed from infra#265, which is closing — brain-mcp's code lives here, not in infra.
Where this actually lives
Confirmed 2026-08-11 from koala:
So brain-mcp is a component inside hyperguild's
ingestionservice, not a standalone deployable. The original issue's "can't find where this code lives" complaint was accurate — that's the finding, not a side note.Part 1 — the bug
capturewith aticketsarray fails. Callers currently fall back to N individualissue_createcalls: no data loss, but N round-trips instead of one.ticketsarray of length 1Part 2 — the repo question (decide, don't build)
Should brain-mcp graduate to
mathias/brain-mcp? Zero runtime blast radius either way; this is purely about whether a service with its own public ingress and its own consumers should be discoverable at its own name. Worth deciding rather than leaving implicit — the discoverability problem is what generated the original issue.Refs
docs/superpowers/specs/2026-08-11-backlog-verification.md