Verify repo-recall live health + agent MCP reachability, re-bless the luca-stack skill #114

New issue

Closed

opened 2026-06-18 07:20:15 +00:00 by coilysiren · 0 comments

coilysiren commented

2026-06-18 07:20:15 +00:00

Owner

Context

repo-recall was unarchived on 2026-06-18 and is live in k3s (ns repo-recall, 1/1 Available, ~29d). Its deploy is migrating into the coilyco-bridge/deploy monorepo (see the onboarding issue). The mcporter entries already exist in coilyco-bridge/agentic-os-kai/config/mcporter.json:

repo-recall -> https://repo-recall.${COILYSIREN_TAILNET_DOMAIN}/mcp (prod, tailnet)
repo-recall-staging -> http://127.0.0.1:7777/mcp
repo-recall-dev -> http://127.0.0.1:7780/mcp

So config-wise agents can already point at it. Unverified after the archive: that an agent can actually reach the live tailnet endpoint and get tool responses, that the pod is not quietly crash-looping (the api container shows ~22 restarts, last ~23h ago), and that the skill docs no longer imply the stack is archived / off.

Goal

Prove an agent can call repo-recall's MCP tools against the live deployment, confirm the service is healthy, and update the luca-stack skill to reflect it is live again (with its deploy home now in bridge/deploy).

Steps

Health. coily ops kubectl -n repo-recall get deploy,po - confirm 1/1, pod Running. Inspect the api container restart cause via kubectl -n repo-recall describe pod <pod> (Last State). If OOMKilled, note it and bump the api memory limit (currently 1Gi) - in services/repo-recall/deploy/main.yml once the onboarding lands, else flag it there. If a panic, file a follow-up with the log excerpt. A periodic self-recovering restart is acceptable to note-and-move.
Reachability. With mcporter, list tools and call a read tool against the live prod endpoint, e.g. mcporter run repo-recall recall_dashboard and recall_search with a trivial query. Confirm a real JSON response, not a connection error. If ${COILYSIREN_TAILNET_DOMAIN} does not resolve in the dispatch env, document the env it needs and verify against the tailnet FQDN directly.
Corpus freshness. Confirm the dashboard returns current repos/sessions - the pod hostPath-mounts /home/kai/projects/coilysiren and /home/kai/.claude read-only, so it should be hydrating, not empty.
Re-bless docs. Update agentic-os/.agents/skills/tooling-mcp-servers/references/luca-stack.md and SKILL.md so they reflect repo-recall is live again, its deploy home is coilyco-bridge/deploy services/repo-recall/, and luca + session-lattice remain intentionally archived (downstream consumers, not needed for the dispatch oracle). Keep the staging-default wording accurate.

Acceptance

Deployment 1/1; restart cause identified and either benign-noted, limit-bumped, or a follow-up filed.
mcporter run repo-recall recall_dashboard returns a valid response from the live pod.
The dashboard shows a non-empty, current corpus.
luca-stack skill text matches reality (live, deploy home in bridge/deploy, siblings archived).

Why headless

Cluster + MCP config already in place. Verification + a doc edit + at most a memory-limit bump. No secrets to mint, no design fork, no destructive step. A real crash bug found in step 1 spawns a follow-up rather than blocking - the verification completes headless.

## Context repo-recall was unarchived on 2026-06-18 and is live in k3s (ns `repo-recall`, `1/1 Available`, ~29d). Its deploy is migrating into the `coilyco-bridge/deploy` monorepo (see the onboarding issue). The mcporter entries already exist in `coilyco-bridge/agentic-os-kai/config/mcporter.json`: - `repo-recall` -> `https://repo-recall.${COILYSIREN_TAILNET_DOMAIN}/mcp` (prod, tailnet) - `repo-recall-staging` -> `http://127.0.0.1:7777/mcp` - `repo-recall-dev` -> `http://127.0.0.1:7780/mcp` So config-wise agents can already point at it. **Unverified** after the archive: that an agent can actually reach the live tailnet endpoint and get tool responses, that the pod is not quietly crash-looping (the api container shows ~22 restarts, last ~23h ago), and that the skill docs no longer imply the stack is archived / off. ## Goal Prove an agent can call repo-recall's MCP tools against the live deployment, confirm the service is healthy, and update the luca-stack skill to reflect it is live again (with its deploy home now in bridge/deploy). ## Steps 1. **Health.** `coily ops kubectl -n repo-recall get deploy,po` - confirm `1/1`, pod `Running`. Inspect the api container restart cause via `kubectl -n repo-recall describe pod <pod>` (Last State). If `OOMKilled`, note it and bump the api memory limit (currently `1Gi`) - in `services/repo-recall/deploy/main.yml` once the onboarding lands, else flag it there. If a panic, file a follow-up with the log excerpt. A periodic self-recovering restart is acceptable to note-and-move. 2. **Reachability.** With mcporter, list tools and call a read tool against the live prod endpoint, e.g. `mcporter run repo-recall recall_dashboard` and `recall_search` with a trivial query. Confirm a real JSON response, not a connection error. If `${COILYSIREN_TAILNET_DOMAIN}` does not resolve in the dispatch env, document the env it needs and verify against the tailnet FQDN directly. 3. **Corpus freshness.** Confirm the dashboard returns current repos/sessions - the pod hostPath-mounts `/home/kai/projects/coilysiren` and `/home/kai/.claude` read-only, so it should be hydrating, not empty. 4. **Re-bless docs.** Update `agentic-os/.agents/skills/tooling-mcp-servers/references/luca-stack.md` and SKILL.md so they reflect repo-recall is live again, its deploy home is `coilyco-bridge/deploy` `services/repo-recall/`, and luca + session-lattice remain intentionally archived (downstream consumers, not needed for the dispatch oracle). Keep the staging-default wording accurate. ## Acceptance - Deployment `1/1`; restart cause identified and either benign-noted, limit-bumped, or a follow-up filed. - `mcporter run repo-recall recall_dashboard` returns a valid response from the live pod. - The dashboard shows a non-empty, current corpus. - luca-stack skill text matches reality (live, deploy home in bridge/deploy, siblings archived). ## Why headless Cluster + MCP config already in place. Verification + a doc edit + at most a memory-limit bump. No secrets to mint, no design fork, no destructive step. A real crash bug found in step 1 spawns a follow-up rather than blocking - the verification completes headless.