Skip to content

Spec: pin ordering, field-handling, and error-coverage clarifications #81

Closed

Description

@e54-bot

Audit findings M13 + M15 + M18 + L8 + L9 + L10 + L12 + L13 + L14 + L15 + N14 + N15 — spec-verified.

Problem — underspecified or self-contradictory spec text

  • M13 §19.1 "MUST ignore unknown fields" vs §4.1 -32602: clarify that a defined field used in an inapplicable context (e.g. entry on lpp/symbols) is -32602, while genuinely unknown fields are ignored — matching the mock.
  • M15 §10.2 "MUST advertise the sourceIdentity capability" contradicts capability independence/absent≡false (fixture 44 pins false). Reword to "the capability is defined from 1.3".
  • M18 §9.2 result ordering ("request-observed order" vs "mock orders by URI") is self-contradictory; pin URI order (or explicitly provider-defined deterministic order). Same gap for symbols and rename result ordering.
  • L8 §16.3 overlappingEdits "the later edit in the original request order" is ambiguous; mock reports the later-in-document-order edit's index.
  • L9 §14.2 "sorted by range.start" + "declaration first" conflict for forward-referencing languages; pin the declaration-first carve-out explicitly.
  • L10 invalidPosition is only named for lpp/definition; mock applies it to all position-taking methods — extend the spec.
  • L12 DocumentSet key vs inner Document.uri authority is unspecified; mock treats the map key as the lookup key and the inner uri as identity — pin that or require equality.
  • L13 Post-shutdown responses have no defined error; pin one or forbid responding.
  • L14 languageList marker asserts non-empty languages + 2-key entries beyond the §7.2 type contract; align one side.
  • L15 Whitespace-only lines and the error-precedence pipeline are undocumented.
  • N14 §18.3 invalidLanguage wording covers only document-level languageId, but §21/§22 raise it for the top-level param too.
  • N15 §16.3 equal-start zero-length edits: order undefined.

Acceptance criteria

  • Each item gets normative text matching mock + fixture behavior (or an explicit provider-defined marker).
  • Review-based acceptance; suite green.

Activity

  1. added
    documentationImprovements or additions to documentation
    ready-for-implementationContract settled; an Engineer can implement without inventing a decision
    on Oct 15, 2026
  2. e54-bot commented on Oct 15, 2026

    @e54-bot
    ContributorAuthor

    Fixed in #86 (commit 9e49de1).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    documentationImprovements or additions to documentationready-for-implementationContract settled; an Engineer can implement without inventing a decision

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions