Add timeout, busy-state, parser-variant and build-freshness rules

- 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>
This commit is contained in:
Mikhail Chusavitin
2026-08-18 21:00:42 +03:00
co-authored by Claude Opus 5
parent e092fea98f
commit 59e3107197
5 changed files with 42 additions and 5 deletions
+12 -1
View File
@@ -1,6 +1,6 @@
# Contract: Import / Export Workflows
Version: 1.0
Version: 1.1
See `README.md` for the reference export handler and locale examples.
@@ -11,6 +11,17 @@ See `README.md` for the reference export handler and locale examples.
- Warnings and errors should be visible per row and in aggregate.
- The confirm step must communicate scope and side effects clearly.
## Parsing Real-World Formats
- Before writing a parser for a third-party text export (1C, CSV, vendor reports), enumerate the
actual format variants present in a real sample file: delimiters, encodings, decimal and date
formats, header repetitions, multi-line and merged records, trailing summary rows.
- Write the parser against the enumerated variant list. Do not assume a single convention and repair
it reactively per bug report.
- Record the enumerated variants next to the parser (test fixtures or a short comment) so later
changes know which shapes must keep working.
- Unrecognized lines must be reported as explicit per-row errors, never silently skipped.
## Export Rules
- The user must explicitly choose export scope when ambiguity exists, such as `selected`, `filtered`, or `all`.