Change the public contract
Read the relevant section of docs/reference/specification.md before editing.
State the current contract, the requested change, and any unresolved behavioral
choice. If the request intentionally changes a decided behavior, update the
specification rather than treating the old text as an implementation obstacle.
Before implementation, present every added, removed, or observably changed
public interface as a compact, separate review item. Give its exact signature,
command or endpoint, inputs, defaults, output, errors and compatibility effect
as applicable, then obtain the user's explicit approval. Do not infer approval
for an interface because it appeared inside a long specification or broader
implementation plan. A direct user request naming the exact interface change is
explicit approval for that change.
Trace the complete affected slice before editing:
- persistence model and Alembic migration, when stored data changes;
- Server validation, service transaction, endpoint, error envelope, and OpenAPI;
- Client boundary model, transport, public method/function, and retry behavior;
- CLI command, stdout/stderr shape, help, and exit behavior;
- Worker runtime, journal, fencing, or concurrency behavior when applicable;
- user guides, references, examples, and tests.
Keep the Client and Server distributions independent; duplicate small boundary
models when necessary instead of creating a shared runtime package. Preserve
explicit lifecycle actions and run_id fencing. Define idempotency, concurrent
state changes, uncertain transport outcomes, validation errors, and migration
behavior instead of relying only on the happy path.
Add focused tests at the lowest useful layer plus at least one real boundary test
for each changed public surface. Use independent SQLite connections for race or
transaction claims. Verify generated OpenAPI whenever endpoint schemas or errors
change.
Finish by checking the specification, implementation, tests, and user docs for
the old term or behavior. Run targeted tests during development and the relevant
validation matrix from AGENTS.md before handoff.
1---2name: public-contract-change3description: Change Labtasker's public Task lifecycle, HTTP API, Python API, CLI, configuration, query language, or persisted schema while keeping every public surface and invariant aligned. Do not use for internal refactors with no observable behavior change.4---56# Change the public contract78Read the relevant section of `docs/reference/specification.md` before editing.9State the current contract, the requested change, and any unresolved behavioral10choice. If the request intentionally changes a decided behavior, update the11specification rather than treating the old text as an implementation obstacle.1213Before implementation, present every added, removed, or observably changed14public interface as a compact, separate review item. Give its exact signature,15command or endpoint, inputs, defaults, output, errors and compatibility effect16as applicable, then obtain the user's explicit approval. Do not infer approval17for an interface because it appeared inside a long specification or broader18implementation plan. A direct user request naming the exact interface change is19explicit approval for that change.2021Trace the complete affected slice before editing:2223- persistence model and Alembic migration, when stored data changes;24- Server validation, service transaction, endpoint, error envelope, and OpenAPI;25- Client boundary model, transport, public method/function, and retry behavior;26- CLI command, stdout/stderr shape, help, and exit behavior;27- Worker runtime, journal, fencing, or concurrency behavior when applicable;28- user guides, references, examples, and tests.2930Keep the Client and Server distributions independent; duplicate small boundary31models when necessary instead of creating a shared runtime package. Preserve32explicit lifecycle actions and `run_id` fencing. Define idempotency, concurrent33state changes, uncertain transport outcomes, validation errors, and migration34behavior instead of relying only on the happy path.3536Add focused tests at the lowest useful layer plus at least one real boundary test37for each changed public surface. Use independent SQLite connections for race or38transaction claims. Verify generated OpenAPI whenever endpoint schemas or errors39change.4041Finish by checking the specification, implementation, tests, and user docs for42the old term or behavior. Run targeted tests during development and the relevant43validation matrix from `AGENTS.md` before handoff.