You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
fix(server/workflows): resolve project workflows with .yml extension
`GET /api/workflows/:name` and `DELETE /api/workflows/:name` constructed
the on-disk filename as `${name}.yaml` and only tried that one extension.
The discovery scanner in `workflow-discovery.ts` (the source for
`GET /api/workflows`) accepts both `.yaml` and `.yml`, so a project that
named its workflow `phase-0-spike.yml` would appear in the list endpoint
but 404 on the detail endpoint and could not be deleted via the API.
This is the same scope-mismatch class as the trailing-newline / case-sensitivity
bugs that crop up whenever two endpoints derive paths independently — fix it
once at the read site rather than forcing every author to rename files.
Changes:
- GET /api/workflows/:name now probes `${name}.yaml` then `${name}.yml`
in each scope (project, home, default). Extracted as a small inline
helper so the same logic isn't duplicated three times.
- DELETE /api/workflows/:name probes both extensions before returning 404.
- PUT (save) is unchanged: writes continue to use `.yaml` as the
canonical extension for newly-created workflows. Existing `.yml` files
remain readable and deletable.
- Bundled defaults are still keyed on `${name}.yaml` (the suffix is a
synthetic in-memory key there, not a filesystem path).
Tests:
- Added regression: `phase-0-spike.yml` in `<cwd>/.archon/workflows/`
returns 200 with `source: project` and `filename: phase-0-spike.yml`.
- All 36 tests in `api.workflows.test.ts` pass (was 35).
- `tsc --noEmit` on `packages/server` is clean.
0 commit comments