Parked after 0.2.0: follow-up proposal for Object-member requirement paths, and two documented known gaps #8

Parked at the 0.2.0 release (IP 0001, #7). Nothing here is scheduled: the follow-up proposal is approved but not started, and enters the process later through its normal intake; the two documented gaps have no follow-up planned.

1. Follow-up proposal (approved draft, not started)

0002-object-member-paths: Improvement Proposal; Stage: Proposed

• Motivation. SPEC 4.1 makes a missing requirement path a TypeScript type error against the generated module, and 14.7 repeats this for spellings without escape sequences. TypeScript cannot honour this when the path reaches a member of its global Object interface (constructor, toString, toLocaleString, valueOf, hasOwnProperty, isPrototypeOf, propertyIsEnumerable) and no section of that name exists. Every object type inherits Object's members, so TypeScript resolves the access to the inherited member, and it keeps resolving through that member's own type (SPEC.toString.call). In bracket form (SPEC.a["toString"]) no generated typing can make TypeScript report it at all. This was accepted as a known residual of IP 0001 (Developer, 2026-10-22). xspec's own unknown-TypeScript-reference finding (14.7) already reports every such path, so build and check still catch the reference.
• Proposed SPEC.md change. One sentence in 4.1 that covers both 4.1's type-error rule and 14.7's type-error clause: neither requires a type error for a path whose first segment that names no section is one of those seven names, in dot or bracket form, whatever follows it. The 14.7 finding stays required for every such path.
• Non-goals. No rejecting or blacklisting of these names (1.4 already rules out constructor as a segment; the other six remain valid segments). No new finding and no exit-code change. No change to which paths resolve.
• Archival. Developer, 2026-10-22, verbatim: "to be clear, dont implement the blacklist or tests for the blacklist now. just accept the error as is and we will add the sentence to the spec and implement later through the official process"

Paths that continue past one of the seven names

The residual as first recorded covered paths whose last segment is such a member. TypeScript also accepts paths that continue past one. Checked with TypeScript 5.9.3 (tsc --noEmit --strict) against a module the product built at 6caa3ba:

• No type error: SPEC.toString.call;, SPEC.constructor.name;, SPEC.a.valueOf.length;, SPEC.a.hasOwnProperty.bind;
• Still an error: SPEC.nope;, SPEC.toString.nope;, text(SPEC.toString.call), text(SPEC.a.toString)
• xspec's own 14.7 finding reports all four of the first group: build --json exits 1 with four unknown-ts-reference findings.

The cause is the same, and the draft's exemption ("whatever follows it") covers these paths. For the 0.2.0 release they count as part of this accepted residual (Developer), not as a new gap.

2. Documented known gaps (no follow-up planned)

Both are recorded in AGENTS.md and were accepted for IP 0001's run.

• 14.20 syntax-failure locations. For a few constructed MDX shapes, the location xspec reports for a 14.20 syntax failure differs from the offset that SPEC 14's location rule fixes. The failure itself is still reported; only its position is off. These were found only by constructed probes, batteries and fuzzing. The recorded shapes are:
  • a run past a probe's 256-character reach;
  • an end of file inside a text tag at a paragraph's end;
  • a spread attribute beginning a line inside a text tag;
  • a brace line below a paragraph line holding an open text expression;
  • a text expression open at an ATX heading's end.
• SPEC 6.5: import removals joined by automatic semicolon insertion. SPEC 6.5 deletes a TypeScript import declaration in place and drops the line it leaves empty. It names no refusal reason for a removal that joins two top-level statements through automatic semicolon insertion. That happens when the import stands between a statement lacking a terminating ; and a line opening with /, (, [, `, + or -, in a file needing no import addition, such as one already importing the target module. The joined text then either:
  • fails to parse, so the product refuses the move through its post-move re-validation (14.20) and modifies nothing, although 6.5 says a successful move's finishing regeneration cannot fail; or
  • parses with a changed meaning that nothing detects (a joined line opening with ( or [ continues the previous expression).

Generated by Claude Code