editorial: split open questions into open/resolved lists; rescope Q11

Restructure spec Section 15 into two state-partitioned lists under one
frozen numbering: open forks in 15, resolved forks (10 naming, 33 wire
encoding) in a new 15.1 with a Question/Resolution format, and
Deliberately out of model becomes 15.2. Open questions convert to
explicit bold numbering so removing 10 and 33 does not renumber the rest.
Rescope Q11 to its true residue (substrate adoption and the concrete
identifier encoding) and reconcile Sections 3 and 13, which had called
the signature algorithm both fixed and open.

Signed-off-by: Chris Raynor <chris@raynor.tech>

Author: cbraynor

extensions/README.md

@@ -24,7 +24,7 @@ Two invariants keep the structure honest:
 
 ## Reserved seams
 
-The core names several mechanisms it does not yet deepen: content-based routing (Section 8.5), heterogeneous capability composition (Section 15.1), confidential and authenticated discovery (Section 4.7), and transport profiles and bridges (Sections 6.3 and 6.4). The first three each become an extension when an implementation needs one. Transport profiles differ in kind. The profile concept and its rules are core, and the concrete per-substrate profiles, each with its conformance vectors, will land in a future `profiles/` directory rather than here, because a profile is a binding rather than the deepening of a mechanism. That directory is named `profiles/` to avoid colliding with "binding", the core's term for authority admission, and the reference adaptors that demonstrate the profiles live in the reference daemon, not in the specification. Nothing in the core forecloses any of these.
+The core names several mechanisms it does not yet deepen: content-based routing (Section 8.5), heterogeneous capability composition (Section 15.2), confidential and authenticated discovery (Section 4.7), and transport profiles and bridges (Sections 6.3 and 6.4). The first three each become an extension when an implementation needs one. Transport profiles differ in kind. The profile concept and its rules are core, and the concrete per-substrate profiles, each with its conformance vectors, will land in a future `profiles/` directory rather than here, because a profile is a binding rather than the deepening of a mechanism. That directory is named `profiles/` to avoid colliding with "binding", the core's term for authority admission, and the reference adaptors that demonstrate the profiles live in the reference daemon, not in the specification. Nothing in the core forecloses any of these.
 
 ## A note on ownership
 

extensions/pools.md

@@ -24,7 +24,7 @@ Model:
 - Promotion policy is a pluggable slot-level declaration, the same shape as transport properties and election policy.
 - The data interface stays transparent through the virtual winner, but the control interface MUST emit promotion as an event: degradation reasoning depends on knowing what is currently live.
 
-A pool presents one capability while internally orchestrating many; this is capability composition, with the pool as the degenerate case where all sub-members satisfy the same interface. A composing node is a steward downward (to its members) and a producer or consumer upward (to its own steward) at once. Heterogeneous composition, where sub-members satisfy different interfaces, is recognized but deliberately out of model (Section 15.1).
+A pool presents one capability while internally orchestrating many; this is capability composition, with the pool as the degenerate case where all sub-members satisfy the same interface. A composing node is a steward downward (to its members) and a producer or consumer upward (to its own steward) at once. Heterogeneous composition, where sub-members satisfy different interfaces, is recognized but deliberately out of model (Section 15.2).
 
 ## The selection locus
 

primer.md

@@ -34,7 +34,7 @@ The names are load-bearing, not decorative. A starling murmuration is the canoni
 
 The lineage is MANET (mobile ad-hoc networking) and swarm robotics: no infrastructure, dynamic membership, route around partition, no required central ground. That posture is inherited deliberately. What is not inherited is MANET routing: Murmur is a contract, identity, and authority layer above whatever moves bytes, not a multi-hop routing protocol. A transport underneath it may itself be a mesh; Murmur is not in that business.
 
-The reference implementation follows a per-language naming convention (specification, open question 10): `murmur-rs` first, then `murmur-go`, `murmur-haskell`, and so on, so that no single implementation wears the protocol's bare name. The daemon binary stays `murmurd`, the shared library is `murmur-core`, and the relay is `murmur-bridge`. The bare token `murmur` is deliberately kept off the command line. It carries a residual association with Mumble's VoIP server (historically named "Murmur"), and that echo would surface only where a binary name travels context-free. The per-language repos and prefixed artifacts avoid putting it there.
+The reference implementation follows a per-language naming convention (specification, question 10, resolved): `murmur-rs` first, then `murmur-go`, `murmur-haskell`, and so on, so that no single implementation wears the protocol's bare name. The daemon binary stays `murmurd`, the shared library is `murmur-core`, and the relay is `murmur-bridge`. The bare token `murmur` is deliberately kept off the command line. It carries a residual association with Mumble's VoIP server (historically named "Murmur"), and that echo would surface only where a binary name travels context-free. The per-language repos and prefixed artifacts avoid putting it there.
 
 ## The grandfather's axe
 
@@ -302,6 +302,6 @@ The status matches the datacenter case: unvalidated, and not the wedge. Cyber-ph
 
 The specification is written to be objected to. Its open questions section is not an appendix of loose ends; it is the working surface, and several of its entries (persistent system identity through total churn; owner re-rooting versus certification; the fast-versus-supervisory boundary; making graceful exit cheaper than disappearing) are the deepest design problems in the project. Where prose elsewhere touches one of them, it is presented as open and inviting objection, not as solved.
 
-The model is deliberately maximal up to a named ceiling (specification, Section 15.1) and minimal in what the witness actually builds, which is the degenerate-case law at work (specification, Section 1). The discipline for growth is fixed: new needs should arrive through the reserved seams (predicate subscriptions, the capability shape type, the steward-of-stewards recursion), not by reopening the spine.
+The model is deliberately maximal up to a named ceiling (specification, Section 15.2) and minimal in what the witness actually builds, which is the degenerate-case law at work (specification, Section 1). The discipline for growth is fixed: new needs should arrive through the reserved seams (predicate subscriptions, the capability shape type, the steward-of-stewards recursion), not by reopening the spine.
 
 The most useful contributions at this stage are objections to the open questions, field accounts from domains that feel the underlying pain, and demonstrations that extend the witness into a harder corner.