Browse Source

G-152 detail: archive marker on the G-143 reference (goals_lint tidy)

Assisted-by: harness=claude; primary-model=claude-opus-5[1m]; api-location=anthropic.com
master
Julian Noble 1 week ago
parent
commit
edf08301cf
  1. 2
      goals/G-152-punkargs-form-viability-verdict.md

2
goals/G-152-punkargs-form-viability-verdict.md

@ -7,7 +7,7 @@ Acceptance: against a tool-shaped multiform definition (literal action leaders;
## Context ## Context
Raised by user review of 'make.tcl help tool info' output (2026-08-02, during the G-143 follow-on session): the one form still on track to be satisfied by supplying MORE args should be differentiable from forms that are impossible regardless of what is appended - feeding form selection and command-line completion. Probes (bootsupport 0.13.0 and dev module) found the channel largely present: the noformmatch throw carries `-errorcode {PUNKARGS VALIDATION {noformmatch forms {...} classes {...}}}` with forms RANKED best-first plus full -argspecs in the return options; the dev module adds per-form formstatus records (status/failureclass/badarg/message), rank_form_failures (literal-affinity + incomplete-first ordering) and the non-throwing parse_status surface. The GAP is semantic soundness, witnessed: parse {info} classes the info form 'incomplete' (correct - exhaustion), but parse {frobnicate} produces the identical classes, also granting info 'incomplete' although no suffix can satisfy it (the wrong word occupies the required leader slot). 'incomplete' today means "a required element was missing when parsing stopped", not "the supplied words are a valid prefix" - the classifier can grant it after mis-seating a contradicting word. Secondary gaps: the class vocabulary is not documented as a stable contract, and the rendered report differentiates only in prose kind, without marking viability. Raised by user review of 'make.tcl help tool info' output (2026-08-02, during the follow-on session to G-143, achieved 2026-08-01 - goals/archive/G-143-maketcl-multiform-help.md): the one form still on track to be satisfied by supplying MORE args should be differentiable from forms that are impossible regardless of what is appended - feeding form selection and command-line completion. Probes (bootsupport 0.13.0 and dev module) found the channel largely present: the noformmatch throw carries `-errorcode {PUNKARGS VALIDATION {noformmatch forms {...} classes {...}}}` with forms RANKED best-first plus full -argspecs in the return options; the dev module adds per-form formstatus records (status/failureclass/badarg/message), rank_form_failures (literal-affinity + incomplete-first ordering) and the non-throwing parse_status surface. The GAP is semantic soundness, witnessed: parse {info} classes the info form 'incomplete' (correct - exhaustion), but parse {frobnicate} produces the identical classes, also granting info 'incomplete' although no suffix can satisfy it (the wrong word occupies the required leader slot). 'incomplete' today means "a required element was missing when parsing stopped", not "the supplied words are a valid prefix" - the classifier can grant it after mis-seating a contradicting word. Secondary gaps: the class vocabulary is not documented as a stable contract, and the rendered report differentiates only in prose kind, without marking viability.
## Notes ## Notes

Loading…
Cancel
Save