Mount the source code for this repo at a folder in cwd #910

New issue

Open

opened 2026-08-17 17:36:21 +00:00 by coilysiren · 1 comment

coilysiren commented

2026-08-17 17:36:21 +00:00

Owner

No description provided.

coilysiren added the

labels

2026-08-17 17:36:36 +00:00

coilyco-ops commented

2026-08-17 20:05:44 +00:00

Member

One question before I build this, and here is what I found while trying to answer it myself. Angie (ENG, claude seat), working the headless engineer queue.

The gap is real and I can name it exactly

The runtime image sets WORKDIR /app and copies the binary, agent/, agents/, the four skill roots, and the composed bundles. It copies no docs/, no README.md, no AGENTS.md, and no internal/ or cmd/. The build stage takes docs/, the released stage does not.

Meanwhile .agents/skills/repo-sirens-echo/SKILL.md says:

Pointer to ~/projects/coilyco-gaming/sirens-echo/. [...] Read those before answering substantive questions about sirens-echo.

Those paths do not exist in the pod. That is the same decorative-pointer problem #859 just fixed for skill references, one layer out: the skill instructs the model to read files the runtime has no copy of.

Why I am not picking a reading

"Mount the source code for this repo at a folder in cwd" splits three ways and they are not cosmetic variants of each other.

Reference material only - README.md, AGENTS.md, docs/ into /app/source/, so the repo-sirens-echo pointers resolve and Echo can answer questions about herself from the current text. Small, and covers the questions members actually ask.
The Go source too - internal/ and cmd/ as well, which is what "source code" says literally. That puts the service's source in a production image, which is a size and disclosure decision rather than a mechanical one, and #159 already treats the prompt as public while the source is a separate question.
A deployment volume mount - "mount" is a deploy word rather than a Dockerfile one, and if that is the intent this belongs in coilyco-bridge/deploy rather than here.

The question: which of the three? If it is 1 or 2 I can build it today, including the reader Echo needs to actually open the files, since read_skill from #859 only serves skill references.

I am marking this autonomy/async-consult per the gate in AGENTS.md, and I will pick it back up the moment there is an answer. Everything else on the headless engineer queue is done.

**One question before I build this, and here is what I found while trying to answer it myself.** Angie (ENG, `claude` seat), working the headless engineer queue. ## The gap is real and I can name it exactly The runtime image sets `WORKDIR /app` and copies the binary, `agent/`, `agents/`, the four skill roots, and the composed bundles. **It copies no `docs/`, no `README.md`, no `AGENTS.md`, and no `internal/` or `cmd/`.** The build stage takes `docs/`, the released stage does not. Meanwhile `.agents/skills/repo-sirens-echo/SKILL.md` says: > Pointer to `~/projects/coilyco-gaming/sirens-echo/`. [...] Read those before answering substantive questions about sirens-echo. **Those paths do not exist in the pod.** That is the same decorative-pointer problem #859 just fixed for skill references, one layer out: the skill instructs the model to read files the runtime has no copy of. ## Why I am not picking a reading "Mount the source code for this repo at a folder in cwd" splits three ways and they are not cosmetic variants of each other. 1. **Reference material only** - `README.md`, `AGENTS.md`, `docs/` into `/app/source/`, so the `repo-sirens-echo` pointers resolve and Echo can answer questions about herself from the current text. Small, and covers the questions members actually ask. 2. **The Go source too** - `internal/` and `cmd/` as well, which is what "source code" says literally. That puts the service's source in a production image, which is a size and disclosure decision rather than a mechanical one, and #159 already treats the prompt as public while the source is a separate question. 3. **A deployment volume mount** - "mount" is a deploy word rather than a Dockerfile one, and if that is the intent this belongs in `coilyco-bridge/deploy` rather than here. **The question: which of the three?** If it is 1 or 2 I can build it today, including the reader Echo needs to actually open the files, since `read_skill` from #859 only serves skill references. I am marking this `autonomy/async-consult` per the gate in `AGENTS.md`, and I will pick it back up the moment there is an answer. Everything else on the headless engineer queue is done.

coilyco-ops added

and removed

labels

2026-08-17 20:05:49 +00:00