coilyco-flight-deck/repo-recall

Archived

Fork 0

Retire repo-recall's bespoke deploy + repoint build to the in-cluster registry #113

New issue

Closed

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

coilysiren commented

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

Owner

Scope

The repo-recall side of the deploy migration. The deploy surface itself is built in the monorepo under coilyco-bridge/deploy#17 (adds services/repo-recall/ + CD). This issue does the two things that land in this repo: repoint the build, and shed the deploy.

Depends on coilyco-bridge/deploy#17 Phase 2 being green. Do not delete the old deploy path here until the monorepo CD has proven it rolls the live service. repo-recall is live and healthy (ns repo-recall, 1/1, ~29d) - keep it serving.

Work

1. Repoint build-publish to the in-cluster registry.
.forgejo/workflows/build-publish-deploy.yml currently builds + pushes 192.168.0.194:30500/repo-recall-api:${sha} (correct registry) but the live pod drifted onto ghcr.io/coilysiren/repo-recall-api:sha-d48225e. The house registry of record is the in-cluster registry 192.168.0.194:30500 (matching atlas/eco-app), NOT ghcr and NOT Docker Hub. Ensure this repo's build publishes 192.168.0.194:30500/repo-recall-api:${sha} and nothing publishes to ghcr anymore. The monorepo main.yml (deploy#17) pins this same image.

2. Retire the bespoke deploy (only after deploy#17 Phase 2 is green).
Per the bridge/deploy boundary rule (deploy concerns must not live in a service's own repo):

Delete deploy/repo-recall.yml.
Reduce .forgejo/workflows/build-publish-deploy.yml to build-publish only - build + push 192.168.0.194:30500/repo-recall-api:${sha}, drop the kubectl/deploy job entirely. The repo keeps building its image (build is not a deploy concern); it stops owning the rollout.
Point this repo's README.md / docs/FEATURES.md deploy section at coilyco-bridge/deploy services/repo-recall/.

Acceptance

This repo's CI publishes 192.168.0.194:30500/repo-recall-api:<sha>; no ghcr/Docker Hub publish remains.
deploy/repo-recall.yml is gone; the workflow is build-publish only, no deploy job.
README/FEATURES point deploy at the monorepo.
pre-commit run --all-files green.

Why headless

All code in this repo. The cluster, secrets, and the new deploy surface are handled by deploy#17; this is a registry string + a deletion + a workflow trim. No design fork (registry = in-cluster 192.168.0.194:30500, decided here). The ordering guard (wait for deploy#17 Phase 2) keeps the running service safe.

## Scope The repo-recall side of the deploy migration. The deploy surface itself is built in the monorepo under **`coilyco-bridge/deploy#17`** (adds `services/repo-recall/` + CD). This issue does the two things that land in *this* repo: repoint the build, and shed the deploy. **Depends on `coilyco-bridge/deploy#17` Phase 2 being green.** Do not delete the old deploy path here until the monorepo CD has proven it rolls the live service. repo-recall is live and healthy (ns `repo-recall`, `1/1`, ~29d) - keep it serving. ## Work **1. Repoint build-publish to the in-cluster registry.** `.forgejo/workflows/build-publish-deploy.yml` currently builds + pushes `192.168.0.194:30500/repo-recall-api:${sha}` (correct registry) but the **live pod drifted onto `ghcr.io/coilysiren/repo-recall-api:sha-d48225e`**. The house registry of record is the in-cluster registry `192.168.0.194:30500` (matching atlas/eco-app), NOT ghcr and NOT Docker Hub. Ensure this repo's build publishes `192.168.0.194:30500/repo-recall-api:${sha}` and nothing publishes to ghcr anymore. The monorepo `main.yml` (deploy#17) pins this same image. **2. Retire the bespoke deploy (only after deploy#17 Phase 2 is green).** Per the bridge/deploy boundary rule (deploy concerns must not live in a service's own repo): - Delete `deploy/repo-recall.yml`. - Reduce `.forgejo/workflows/build-publish-deploy.yml` to **build-publish only** - build + push `192.168.0.194:30500/repo-recall-api:${sha}`, drop the kubectl/deploy job entirely. The repo keeps building its image (build is not a deploy concern); it stops owning the rollout. - Point this repo's `README.md` / `docs/FEATURES.md` deploy section at `coilyco-bridge/deploy` `services/repo-recall/`. ## Acceptance - This repo's CI publishes `192.168.0.194:30500/repo-recall-api:<sha>`; no ghcr/Docker Hub publish remains. - `deploy/repo-recall.yml` is gone; the workflow is build-publish only, no deploy job. - README/FEATURES point deploy at the monorepo. - `pre-commit run --all-files` green. ## Why headless All code in this repo. The cluster, secrets, and the new deploy surface are handled by deploy#17; this is a registry string + a deletion + a workflow trim. No design fork (registry = in-cluster `192.168.0.194:30500`, decided here). The ordering guard (wait for deploy#17 Phase 2) keeps the running service safe.

coilysiren changed title from ~~Re-prove the push-to-main build->deploy loop and reconcile manifest image drift~~ to Onboard repo-recall into the bridge/deploy monorepo and retire its bespoke deploy

2026-06-18 07:28:10 +00:00

coilyco-ops commented

2026-06-18 07:56:00 +00:00

Member

🔒 Reserved by ward agent claude — container ward-repo-recall-issue-113-claude-be4849fe on host kais-macbook-pro.local is carrying this issue (reserved 2026-06-18T07:55:59Z). Concurrent ward agent runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); --force overrides.

— Claude (she/her), via ward agent

🔒 Reserved by `ward agent claude` — container `ward-repo-recall-issue-113-claude-be4849fe` on host `kais-macbook-pro.local` is carrying this issue (reserved 2026-06-18T07:55:59Z). Concurrent `ward agent` runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); `--force` overrides.  — Claude (she/her), via `ward agent`

coilysiren changed title from ~~Onboard repo-recall into the bridge/deploy monorepo and retire its bespoke deploy~~ to Retire repo-recall's bespoke deploy + repoint build to the in-cluster registry

2026-06-18 07:59:09 +00:00

coilysiren commented

2026-06-18 08:00:12 +00:00

Author

Owner

Status from `ward agent claude` (container `ward-repo-recall-issue-113-claude-be4849fe`)

Picked up #113 but I'm stopping without changing this repo, because the issue can't be safely carried end-to-end from a repo-recall-scoped container. Surfacing rather than guessing.

Where the work actually lives:

Phase 1 + 2 (stand up services/repo-recall/: deploy/{namespace,main}.yml, scripts/rollout.sh, Makefile/ward/coily verbs, path-scoped deploy-repo-recall.yml, then prove CD green) → coilyco-bridge/deploy.
Infra prereq (deploy-runner SA RoleBinding in ns repo-recall) → infrastructure.
Phase 3 (delete deploy/repo-recall.yml; reduce build-publish-deploy.yml to build-publish-only) → this repo — but explicitly gated on Phase 2 being green to keep the service 1/1.

Why I stopped: this container targets repo-recall. coilyco-bridge/deploy and infrastructure are present only as read-only /substrate reference copies, and container doctrine forbids (a) pushing to repos other than the target and (b) pushing from /substrate. The only in-repo work, Phase 3, is unsafe to do first — retiring the bespoke path before the bridge/deploy path is proven would break the live deploy, which the issue forbids ("do NOT delete the old path until the new one is proven"; "stays 1/1 across the whole migration"). With no explicit cross-repo opt-in, the doctrine wall holds.

Recommended sequencing:

Run Phase 1 + 2 from a coilyco-bridge/deploy container, and the RoleBinding from an infrastructure container.
Once deploy-repo-recall is green and the live api image is docker.io/coilysiren/repo-recall-api:<tag>, re-run a repo-recall container for Phase 3.

No code changed in this repo; tree left clean; #113 left open.

— Claude (she/her), via ward agent

## Status from `ward agent claude` (container `ward-repo-recall-issue-113-claude-be4849fe`) Picked up #113 but I'm **stopping without changing this repo**, because the issue can't be safely carried end-to-end from a `repo-recall`-scoped container. Surfacing rather than guessing. **Where the work actually lives:** - **Phase 1 + 2** (stand up `services/repo-recall/`: `deploy/{namespace,main}.yml`, `scripts/rollout.sh`, Makefile/ward/coily verbs, path-scoped `deploy-repo-recall.yml`, then prove CD green) → **`coilyco-bridge/deploy`**. - **Infra prereq** (deploy-runner SA RoleBinding in ns `repo-recall`) → **`infrastructure`**. - **Phase 3** (delete `deploy/repo-recall.yml`; reduce `build-publish-deploy.yml` to build-publish-only) → **this repo** — but explicitly gated on Phase 2 being green to keep the service `1/1`. **Why I stopped:** this container targets `repo-recall`. `coilyco-bridge/deploy` and `infrastructure` are present only as **read-only `/substrate` reference copies**, and container doctrine forbids (a) pushing to repos other than the target and (b) pushing from `/substrate`. The only in-repo work, Phase 3, is unsafe to do first — retiring the bespoke path before the bridge/deploy path is proven would break the live deploy, which the issue forbids ("do NOT delete the old path until the new one is proven"; "stays `1/1` across the whole migration"). With no explicit cross-repo opt-in, the doctrine wall holds. **Recommended sequencing:** 1. Run **Phase 1 + 2** from a **`coilyco-bridge/deploy`** container, and the RoleBinding from an **`infrastructure`** container. 2. Once `deploy-repo-recall` is green and the live api image is `docker.io/coilysiren/repo-recall-api:<tag>`, re-run a **`repo-recall`** container for **Phase 3**. No code changed in this repo; tree left clean; #113 left open.  — Claude (she/her), via `ward agent`

coilyco-ops commented

2026-06-18 08:30:34 +00:00

Member

🛫 ward pre-flight: NO-GO

ward agent claude headless ran a pre-flight feasibility read on this issue before detaching a fire-and-forget run, and the agent judged it NO-GO - it should not be carried unattended until a human weighs in.

full acceptance requires deleting the bespoke deploy, which is gated on deploy#17 Phase 2 being proven green - an external state unverifiable from the issue, and the latest comment shows it was not yet confirmed. A human should confirm Phase 2 is green (or explicitly authorize Part-1-only) before this runs unattended.

No container was launched. Review the issue (clarify the scope, resolve the unknown, or split it), then re-dispatch - ward agent claude headless <ref> --no-preflight skips this gate once you've decided it's good to go.

full pre-flight read

The hard dependency is external and unverifiable from here: Part 2 (delete deploy/repo-recall.yml, trim the workflow to build-publish-only) is explicitly gated on coilyco-bridge/deploy#17 Phase 2 being green and proving the monorepo CD rolls the live service - and the most recent comment is the prior ward agent stopping for exactly this reason, with no confirmation that Phase 2 has since gone green. Part 1 (repoint build to 192.168.0.194:30500) is safe and in-repo, but full acceptance requires the gated deletion, and doing it before the new path is proven risks breaking a live, healthy service (1/1, ~29d). I can't confirm the gate from the issue text alone, and unattended I'd either stall on a partial or risk the running deploy.

NO-GO: full acceptance requires deleting the bespoke deploy, which is gated on deploy#17 Phase 2 being proven green - an external state unverifiable from the issue, and the latest comment shows it was not yet confirmed. A human should confirm Phase 2 is green (or explicitly authorize Part-1-only) before this runs unattended.

Posted automatically by ward agent claude headless pre-flight (ward#147, ward#149).

— Claude (she/her), via ward agent

### 🛫 ward pre-flight: NO-GO `ward agent claude headless` ran a pre-flight feasibility read on this issue before detaching a fire-and-forget run, and the agent judged it **NO-GO** - it should not be carried unattended until a human weighs in. > full acceptance requires deleting the bespoke deploy, which is gated on deploy#17 Phase 2 being proven green - an external state unverifiable from the issue, and the latest comment shows it was not yet confirmed. A human should confirm Phase 2 is green (or explicitly authorize Part-1-only) before this runs unattended. No container was launched. Review the issue (clarify the scope, resolve the unknown, or split it), then re-dispatch - `ward agent claude headless <ref> --no-preflight` skips this gate once you've decided it's good to go. <details><summary>full pre-flight read</summary> The hard dependency is external and unverifiable from here: Part 2 (delete `deploy/repo-recall.yml`, trim the workflow to build-publish-only) is explicitly gated on `coilyco-bridge/deploy#17` Phase 2 being green and proving the monorepo CD rolls the live service - and the most recent comment is the prior ward agent stopping for exactly this reason, with no confirmation that Phase 2 has since gone green. Part 1 (repoint build to `192.168.0.194:30500`) is safe and in-repo, but full acceptance requires the gated deletion, and doing it before the new path is proven risks breaking a live, healthy service (`1/1`, ~29d). I can't confirm the gate from the issue text alone, and unattended I'd either stall on a partial or risk the running deploy. NO-GO: full acceptance requires deleting the bespoke deploy, which is gated on deploy#17 Phase 2 being proven green - an external state unverifiable from the issue, and the latest comment shows it was not yet confirmed. A human should confirm Phase 2 is green (or explicitly authorize Part-1-only) before this runs unattended. </details> --- Posted automatically by `ward agent claude headless` pre-flight (ward#147, ward#149).   — Claude (she/her), via `ward agent`

coilyco-ops added the

label

2026-07-04 17:38:53 +00:00

coilyco-ops closed this issue

2026-07-07 10:16:46 +00:00

coilyco-ops added the

consult

label

2026-07-10 11:58:05 +00:00

Commenting is not possible because the repository is archived.