About WORKFLOW.md in the Elixir reference implementation

[jesus-gomez-aetonix]

I'm trying to understand the intended deployment model for the Elixir reference implementation of Symphony, and I'm a bit confused by the documentation.

The README instructs me to:

1. Copy WORKFLOW.md (and optionally the .codex skills) into my project's repository.
2. Clone the openai/symphony repository.
3. Run the Elixir reference implementation with:

./bin/symphony ./WORKFLOW.md

If I follow these instructions literally, I end up with two copies of WORKFLOW.md:

• one in my project's repository, and
• another one in the Symphony repository (or another local path passed to ./bin/symphony).

At that point, it's not clear to me which one is the source of truth.

The specification describes WORKFLOW.md as an in-repository workflow contract, which suggests that it should live with the project and evolve alongside it. However, the Elixir reference implementation appears to read a single WORKFLOW.md when the daemon starts, and I don't see where it would later read the WORKFLOW.md from the repository that gets cloned into each workspace via after_create.

So my questions are:

• During normal operation, does the Elixir reference implementation ever read the WORKFLOW.md from the cloned project repository?
• Or is the only active workflow the one passed to ./bin/symphony (or the one in the current working directory), with the copy committed to the project repository serving only as a version-controlled configuration that I must manually keep in sync?
• If the latter is correct, what is the recommended way to avoid ending up with two copies of WORKFLOW.md that could drift over time?

I suspect I'm missing something about the intended deployment model, so I'd appreciate any clarification.

[AliFozooni]

You’re reading the implementation correctly: Symphony does not discover or load WORKFLOW.md from each repository cloned by after_create. The active workflow is the single file passed to the Symphony process (or WORKFLOW.md in the process working directory when no path is supplied).

The CLI expands that argument to an absolute path and registers it before startup. The workflow store then watches and reloads that same path. after_create only runs the configured shell hook with the new issue workspace as its working directory; it does not change the workflow source.

So I would keep one maintained copy in the target project and pass that exact file to the Symphony binary:

cd /path/to/symphony/elixir
mise exec -- ./bin/symphony \
  --i-understand-that-this-will-be-running-without-the-usual-guardrails \
  /absolute/path/to/your-project/WORKFLOW.md

With a downloaded release binary, the same pattern is:

/path/to/symphony-v... \
  --i-understand-that-this-will-be-running-without-the-usual-guardrails \
  /absolute/path/to/your-project/WORKFLOW.md

That project file is then both the version-controlled source of truth and the daemon’s active configuration. A per-issue clone may naturally contain its own checked-out WORKFLOW.md, but Symphony does not use that copy as runtime configuration.

One useful caveat: valid edits to the active file are hot-reloaded (the current store polls about once per second). If a later edit is invalid, Symphony keeps the last known-good workflow and logs the reload error, as the README notes.

I agree the setup wording can read as though ./WORKFLOW.md in the Symphony checkout must be a second copy; in the project-specific invocation, that argument should instead be the path to the project-owned file.