Expose sequence identity registrations through the facade

docs/config.md

@@ -71,8 +71,8 @@ missing file remains an error; it is never interpreted as no input.
 `Options` accepts the application definition, ordinary-source `Destination` and
 `PlacementMode`, explicit imports, one selected overlay, filesystem
 context, explicit CLI overrides, and shared source-version controls. The definition
-may register strict sequence composition paths through
-`SequenceCompositions`. Its zero-valued placement mode places the source mapping
+may register sequence identities through `Definition.SequenceIdentities`. Its
+zero-valued placement mode places the source mapping
 at the destination; `sequence-item` explicitly wraps the mapping as one item at a
 non-root destination. Unknown modes, invalid destinations, and invalid or
 conflicting sequence registrations fail before source acquisition. Overlay and
@@ -811,33 +811,39 @@ validated, but there are no imported peers to combine.
 | Any other pair of present nodes | Any other pair of present nodes | `compose.conflict` |
 
 Every non-mapping overlap is a conflict, even when values are equal, except for
-sequence/sequence contributions at a registered sequence-composition path or a
-source-declared collection destination. Nulls remain atomic conflicts.
+sequence/sequence contributions at a registered sequence identity destination
+or a source-declared collection destination. Nulls remain atomic conflicts.
 Unregistered and undeclared sequences conflict when repeated and are never joined
 by index. Disjoint entries under shared mappings compose, making stable keyed
 mappings the natural representation for independently contributed entries.
 
-`Definition.SequenceCompositions` registers literal mapping paths and one literal
-`IdentityField` for sequences that should compose independently authored records.
-Registration paths follow input-destination key rules: parsed numeric tokens are
-literal mapping keys, explicit index segments and reserved `configkit` or
-mapping-valued `extends` segments are invalid, and the root registration is
-harmless and unused. The identity field is one literal string key; neither the
-field name nor identity strings are normalized.
-At each registered path, every actual sequence contribution in a strict tier is
-validated, including a singleton contribution: each record must be a mapping with
-a present string identity field. Distinct exact identity strings append in source
-and list order; duplicate identities conflict even if the records are otherwise
-equal or disjoint. Empty identity strings are valid. Malformed records produce
-`compose.invalid`; duplicate identities produce `compose.conflict`, with the
-sequence container and source locations identifying a duplicate without exposing
-identity values. Missing paths and non-sequence values do not fail by themselves.
-Identical registrations coalesce; conflicting registrations at one path and
-invalid registration paths produce `options.invalid`. Unused and root registrations
-are allowed and have no effect.
+`Definition.SequenceIdentities` contains registrations created by
+`SequenceIdentityAt` or `SequenceIdentityMatching`. The exact form accepts a
+mapping-only `Path`; the matching form accepts literal-key and any-mapping-key
+segments created by `SequenceLiteralKey` and `SequenceAnyMappingKey`. A literal
+`"*"` key is distinct from the wildcard constructor. Parsed numeric path tokens
+remain literal mapping keys; explicit index segments and reserved `configkit` or
+mapping-valued `extends` segments are invalid. The root selector is harmless under
+the mapping-root schema. Each registration requires one or more literal field
+names; compound field sets are normalized as sets, and field names are not
+otherwise normalized.
+
+At each selected path, records must provide every registered field as a scalar
+string, number, boolean, or explicit null. The type-tagged tuple preserves
+category distinctions, while equivalent finite decimal spellings such as `1`,
+`1.0`, and `1e0` compare as the same number. Distinct tuples append in source and
+list order; duplicate tuples conflict even when records are otherwise equal or
+disjoint. Malformed records produce `compose.invalid`; duplicate identities
+produce `compose.conflict`, with paths and source locations identifying a
+duplicate without exposing identity values. Missing paths and non-sequence values
+do not fail by themselves. Equivalent overlapping registrations coalesce;
+incompatible overlaps and invalid registrations produce `options.invalid` before
+source acquisition. Unused and root registrations are allowed and have no effect.
 
 Registration controls strict composition and supplies identity fields for parent
-lookup when surviving records in that sequence use `extends`. Each underlay group
+lookup when surviving records in that sequence use `extends`. Dynamic selectors
+apply at strict-composition and inheritance destinations without requiring the
+application to enumerate mapping keys. Each underlay group
 and the main tier has independent duplicate-identity state. Precedence assembly
 is unchanged: a present higher-priority sequence replaces the lower sequence as
 one value, including at a registered path. Registration does not add a final
@@ -1092,7 +1098,7 @@ including every match of a glob; placement is not inherited. Sequence-item
 placement requires a nonempty effective destination and wraps the imported
 mapping as one element of a sequence there. It does not split source sequences
 or infer identity fields. Repeated sequences still conflict unless their path is
-registered through `Definition.SequenceCompositions`; registration does not
+registered through `Definition.SequenceIdentities`; registration does not
 change placement or precedence behavior. Sequence records retain source
 locations through placement and history; indexes describe their assembled
 positions while source coordinates continue to identify the declaring files.

docs/roadmap/implementation.md

@@ -1,6 +1,6 @@
 # Sequence Identity And Combination Implementation Plan
 
-Status: implementation in progress; Stages 1–21 complete.
+Status: implementation in progress; Stages 1–22 complete.
 
 Audience: a Luna coding agent implementing one numbered stage per prompt, in
 order. This plan starts at commit
@@ -760,6 +760,11 @@ Scope: the settled facade surface and migration of in-repository callers.
 Validation: root sequence/facade, registration, public/dependency-boundary, and
 consumer example tests plus the everyday check.
 
+**Completion:** Exposed the root-owned exact and dynamic sequence identity
+registration API, migrated maintained callers, and removed the old single-field
+registration adapters. Verified facade, registration, inheritance,
+public/dependency-boundary, and consumer example tests plus `./scripts/check.sh`.
+
 ## Stage 23 — Separate Reusable CLI Override Preparation
 
 Scope: mechanical preparation refactor and a privately tested post-structural