Create a fast local feedback entrypoint

[zack-nova]

What to build

Delivery mode: AFK

Add or clarify a fast local validation entrypoint for day-to-day development while preserving mise run ci as the full strict validation command before review and landing.

Acceptance criteria

• A fast local command, such as mise run check or an equivalent task, is documented as the normal development feedback loop.
• The fast command uses cached Go tests where appropriate and avoids unnecessary full no-cache integration sweeps.
• mise run ci remains the full strict validation command and still matches repository testing expectations.
• The difference between fast feedback and full strict CI is clear in task descriptions and contributor docs.
• Release-surface changes still clearly require the release-surface validation path.

Blocked by

• Unify lint tool versions and CI validation coverage #117

[zack-nova]

This was generated by AI during triage.

Triage Notes

Current decision: blocked

Facts established:

• Issue has exactly one state label: state:needs-triage.
• Issue has exactly one type label: type:task.
• Requested delivery mode is AFK, and the work appears AFK-compatible after unblock because the expected changes are validation task/docs updates with objective repository gates.
• The local task surface currently includes mise run check as a fast local path using cached Go tests through test:go, and mise run ci as the full strict path using test:go:ci, vuln, and shell validation.
• Contributor testing docs currently emphasize mise run fix and mise run ci; the fast feedback distinction still needs documentation once the validation surface is stable.
• Blocker Unify lint tool versions and CI validation coverage #117 is open and currently state:in-progress; it is changing lint/tool-version and local/remote validation parity.

Blocking reason:

#120 depends on #117 because the fast-vs-strict local validation guidance should be written against the final validation task surface after #117 lands. Starting implementation now risks documenting or adjusting a moving validation contract.

Intended resume state:

Move back through triage to state:ready-for-dev after #117 is merged or otherwise resolved with an equivalent stable validation surface. At that time, create a complete ## Dev Brief before implementation starts.

Split / info check:

No split needed. No reporter clarification needed at this time.

[zack-nova]

This was generated by AI during triage.

Dev Brief

Type: task

Delivery mode: afk

HITL rationale:

N/A - this is a validation documentation and task-surface clarification slice with objective repository gates.

Summary:

Clarify the day-to-day fast local validation entrypoint while preserving mise run ci as the full strict validation command before review and landing.

Current behavior / context:

• mise.toml already exposes mise run check as a fast local path that runs lint plus cached Go tests through test:go.
• mise.toml keeps mise run ci as the full strict local CI path with lint, no-cache Go tests through test:go:ci, vulnerability scanning, and shell validation.
• Contributor and maintainer testing docs still emphasize only mise run fix and mise run ci, so the normal fast feedback loop is not clearly documented.
• Shell validation includes the release-surface check through scripts/test_shell_validation.sh; release-surface-specific changes still need the explicit release-surface validation path called out in docs.
• Prior blocker Unify lint tool versions and CI validation coverage #117 is closed and state:merged, so the validation task surface is stable enough to document.

Desired behavior:

Contributors and maintainers should see mise run check as the normal fast local development feedback loop, with task descriptions and docs making clear that it uses cached Go tests and avoids the full no-cache integration sweep. mise run ci must remain documented as the strict validation command before review and landing. Release-surface changes must still clearly require sh ./scripts/test_release_surface_hyard.sh.

Key interfaces / constraints:

• Preserve hyard as the only public release binary; this issue must not change product command behavior.
• Keep mise run ci as the repository contract validation command required before review and landing.
• Prefer documenting or testing existing task behavior over broad validation refactors unless the acceptance criteria require a small task-description change.
• Do not remove the release-surface validation path or weaken release-surface documentation.
• Keep changes within checked-in docs, task metadata, and validation drift tests.

Acceptance criteria:

• A fast local command, such as mise run check or an equivalent task, is documented as the normal development feedback loop.
• The fast command uses cached Go tests where appropriate and avoids unnecessary full no-cache integration sweeps.
• mise run ci remains the full strict validation command and still matches repository testing expectations.
• The difference between fast feedback and full strict CI is clear in task descriptions and contributor docs.
• Release-surface changes still clearly require the release-surface validation path.

Validation plan:

• Unit/script: add or update a shell validation test that fails until docs and task descriptions distinguish fast feedback from strict CI.
• Integration: run mise run fix.
• Integration: run mise run ci.
• Release-surface: confirm release-surface validation remains documented; run sh ./scripts/test_release_surface_hyard.sh if release-surface-facing docs or checks are changed.
• Regression risk: verify contributor and maintainer testing docs still name the strict command for pre-review/pre-landing validation.

Out of scope:

• Changing product command behavior or release artifacts.
• Reworking the whole validation graph beyond clarifying the fast local path.
• Replacing mise as the local task runner.

[zack-nova]

Dev Workpad

repo: zack-nova/harnessyard
issue: #120
branch: issue-120-fast-local-feedback
base: main
owner: Codex

Plan

• Confirm current validation task behavior after Unify lint tool versions and CI validation coverage #117 landed.
• Create a dedicated implementation branch before editing files.
• Add a failing validation parity check for the fast-vs-strict local validation contract.
• Update task descriptions and testing docs to satisfy the contract.
• Validate with targeted, fast, strict, and release-surface checks.
• Review and commit intended scope only.
• Push branch and publish review artifact.
• Review sweep.
• Land.

Acceptance Criteria

• A fast local command, such as mise run check or an equivalent task, is documented as the normal development feedback loop.
• The fast command uses cached Go tests where appropriate and avoids unnecessary full no-cache integration sweeps.
• mise run ci remains the full strict validation command and still matches repository testing expectations.
• The difference between fast feedback and full strict CI is clear in task descriptions and contributor docs.
• Release-surface changes still clearly require the release-surface validation path.

Validation

• Command: sh ./scripts/test_validation_parity.sh
• Result: passed after RED/GREEN cycle.
• Command: mise run fix
• Result: passed with MISE_TRUSTED_CONFIG_PATHS and temporary cache paths under /tmp/harnessyard-issue-120.
• Command: mise run ci
• Result: passed; lint reported 0 issues, Go tests passed, govulncheck reported no called vulnerabilities, and shell validation passed.
• Command: mise run check
• Result: passed; fast path ran lint plus cached Go tests.
• Command: sh ./scripts/test_release_surface_hyard.sh
• Result: passed; goreleaser was not installed, so the goreleaser config check was skipped.
• Review-commit: completed intended-scope review; no blockers remained; debt recorded as none.

Review Artifact

• Commit: b338e92aa84ec1a7b87075b2bcb36ab571dd669e
• Pull request: Clarify fast local validation #135
• PR closes: Create a fast local feedback entrypoint #120

Notes

• TDD loop used one focused RED/GREEN slice: parity assertions failed first on the missing fast feedback task description, then passed after task/docs updates.
• mise run ci already includes sh ./scripts/test_release_surface_hyard.sh through shell validation; the release-surface script was also run directly because contributor release-surface guidance was touched.

Confusions

• None.