Reject invalid task configuration before starting a command
A misspelled dependsOn entry silently removed a typecheck prerequisite. Introduce a validated task configuration with clear locations for configuration errors.
- Focused work estimate
- 1h + prerequisites
- Priority in the scenario
- Medium
- Engineering practice
- Schema validation · CLI design · Path safety
Estimated field mix
- Developer tooling80%
- Security20%
Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence.
Review it, then add it to your workspace.
The board opens an editable draft; nothing is saved until you confirm it. Sign-in and workspace permissions apply, and Demo boards remain ephemeral.
Project context
A product team waits for every package to rebuild after small changes. An experimental cache is faster but occasionally returns success after a shared type changed. Build a small, auditable task runner around fixture packages.
Setup prerequisites
- Prepare four fixture packages with one shared library and two applications.
- Use only trusted fixture commands in local tests.
Preceding work
No earlier ticket is required. Complete the project setup above.
Acceptance criteria
- Every task has a unique ID, command argument list, working directory, and declared dependencies.
- Unknown dependencies and paths outside the workspace fail validation.
- Validation reports all independent configuration errors without starting commands.
Implementation constraints
- Commands are trusted fixture configuration; no shell interpolation.
- Keep configuration parsing independent of execution.
Verification to include
- Validate a four-task graph successfully.
- Submit a missing dependency and escaping working directory together and confirm both errors and zero process starts.
Deliverables
- Configuration schema and validation diagnostics
Rollout and recovery
Use validation in a read-only plan command first; refuse execution for older unsupported config versions.
Value of the work
For the engineer: Practice incremental computation, dependency scheduling, cache correctness, and cancellation.
For the team: Inspect whether faster checks preserve the guarantees reviewers depend on.
Evidence boundaries
Outcome Evidence: Tests, patches, and runbooks are requested deliverables. They become Outcome Evidence only through a qualified Mission and immutable Evidence IDs.
Ownership Evidence: Independent adaptation must be observed under a declared verification policy and cite immutable Evidence IDs. Completing a planning ticket establishes no Ownership Evidence.