docs(output): refresh agent guide

This commit is contained in:
2025-10-15 14:11:02 -05:00
parent 386c6d28f9
commit 36296c4a83

View File

@@ -1,18 +1,28 @@
# Output Agent Guide
## Scope
The `output/` tree houses the delivery pipeline that watches for approved Markdown resumes, converts them to DOCX/PDF using Pandoc, and archives the source material. It is intended to run independently from the `input/` authoring workflow.
## Mission
Operate the output pipeline that turns one approved Markdown resume at a time into DOCX/PDF deliverables while preserving human-reviewed history.
## Key Components
- `ForRelease/inbox`: manually populated with a single vetted `.md` resume for conversion.
- `ForRelease/outbox`: timestamped folders containing generated DOCX/PDF pairs ready for sharing.
- `ForRelease/processed`: timestamped archives of Markdown files that converted successfully.
- `ForRelease/failed`: Markdown originals for conversion attempts that Pandoc could not render.
- `Docker/`: container definition, watcher script, and wrapper to run the stack without root-owned outputs.
## Directory Responsibilities
- `ForRelease/inbox` populated manually with exactly one vetted `.md` resume when it is ready for conversion; otherwise keep this directory empty.
- `ForRelease/outbox` timestamped export folders containing the generated DOCX/PDF pairs. These folders are append-only historical records under human control.
- `ForRelease/processed` timestamped archives of Markdown files that converted successfully; also append-only and human-managed.
- `ForRelease/failed` holding area for Markdown files that Pandoc could not render so the human can inspect, fix, and retry.
- `Docker/` Dockerfile, compose stack, watcher script, and wrapper used to run the containerized conversion service.
## Operational Rules
- Always launch the service with `Docker/run-output-processor.sh` so the container inherits the callers UID/GID.
- Before testing, ensure `ForRelease/inbox` is empty; this watcher expects at most one Markdown file at a time.
- Monitor logs via `./run-output-processor.sh logs -f` while converting to confirm the Markdown leaves inbox and the exports appear in outbox.
- If Pandoc fails, the Markdown moves to `ForRelease/failed`; fix the content there, then move it back to `inbox` for another run.
- Treat `ForRelease/outbox` and `ForRelease/processed` as immutable history managed solely by the human operator. Only create or append new artifacts when explicitly instructed, and never delete, move, rename, or even contemplate cleanup, retention, or consolidation actions in these directories.
## Standard Operating Procedure
1. Confirm `ForRelease/inbox` is empty before the human drops the next Markdown file.
2. Start or inspect the stack through `Docker/run-output-processor.sh` (for example `./run-output-processor.sh up -d`).
3. Monitor activity with `./run-output-processor.sh logs -f` to verify the Markdown leaves inbox, exports appear in outbox, and the source lands in processed.
4. If Pandoc fails, the watcher moves the Markdown into `ForRelease/failed`; alert the human so they can correct the file and requeue it.
5. Shut down the stack with `./run-output-processor.sh down` when instructed.
## Guardrails (Do Not Cross)
- Treat `ForRelease/outbox` and `ForRelease/processed` as immutable history managed exclusively by the human. Only append new artifacts when explicitly directed; never delete, move, rename, reorganize, or even contemplate cleanup, retention, or consolidation actions.
- Refrain from generating additional files outside the described workflow. All job-specific Markdown arrives from the human, and all cleanup decisions belong to the human.
- Leave shared templates mounted from `input/templates` untouched; template maintenance happens in the input system.
- Do not queue multiple Markdown files or attempt parallel conversions. This pipeline is intentionally single-job at any moment.
- Escalate irregularities (missing templates, repeated failures, permission issues) to the human instead of improvising fixes.
## Human Handoff
Provide concise status updates—successful exports, failures encountered, or stack lifecycle changes. After a conversion completes, leave every artifact exactly where it lands and await further instruction from the human operator.