Mikhail ChusavitinandClaude Opus 5
59e3107197
- task-discipline: require explicit target platform/language before implementation - go-api: bounded context deadline on every outbound network/DB call - controls-selection: visible busy state for any control triggering such a call - import-export: enumerate real format variants before writing a parser - app-binary: embedded assets do not hot-reload; verify rebuild before diagnosing Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
30 lines
1.6 KiB
Markdown
30 lines
1.6 KiB
Markdown
# Contract: Task Discipline
|
|
|
|
Version: 1.1
|
|
|
|
## Principle
|
|
|
|
Finish before switching. A task is not done until it reaches a logical end.
|
|
|
|
## Scope Definition
|
|
|
|
- Before implementation starts, the task description must state the target platform and language
|
|
explicitly: CLI, server-rendered web app, desktop app, library, and the language/runtime it runs on.
|
|
- If the platform is not stated, ask before writing code. Do not infer it from the surrounding repo.
|
|
- A platform pivot after implementation invalidates connection, config, and transport plumbing built
|
|
around the previous shape. Treat such a pivot as a new task, not as a continuation.
|
|
|
|
## Rules
|
|
|
|
- Do not start a new task while the current one is unfinished. Switching mid-task leaves half-done work that is harder to recover than if it had never been started.
|
|
- If a new idea or requirement surfaces during work, note it and address it after the current task is complete.
|
|
- "Logical end" means: the change works, is committed, and leaves the codebase in a coherent state — not just "the immediate code compiles."
|
|
- Do not open new files, refactor adjacent code, or fix unrelated issues while implementing a specific task. Stay focused on the defined scope.
|
|
- If the current task is blocked, resolve the blocker or explicitly hand off — do not silently pivot to something else.
|
|
|
|
## Anti-patterns
|
|
|
|
- Starting a refactor while in the middle of a bug fix.
|
|
- Leaving a feature half-implemented because something more interesting came up.
|
|
- Responding to a new requirement by abandoning the current one without documenting what was left unfinished.
|