Clean up proposed specs: reconcile status against the codebase

spec/accepted/ncmul_canonicalization.md

@@ -5,7 +5,7 @@
 Accepted. Ports the structural rule set from
 [sympy/sympy#28392](https://github.com/sympy/sympy/pull/28392)
 (`sympy/physics/quantum/transforms.py`) onto Uhlenbeck's
-[`SlidingWindow` engine](../proposed/sliding_transform.md). Adds always-on
+[`SlidingWindow` engine](../accepted/sliding_transform.md). Adds always-on
 canonicalization for adjacencies that produce `InnerProduct`,
 `OuterProduct`, type errors, and concrete matrix/vector folding,
 plus like-base combining for non-commutative factors.

spec/accepted/qapply.md

@@ -5,7 +5,7 @@
 Accepted. Ports operator application from
 [sympy/sympy#28392](https://github.com/sympy/sympy/pull/28392)
 (`sympy/physics/quantum/qapply.py`) onto Uhlenbeck's
-[`SlidingWindow` engine](../proposed/sliding_transform.md). Implements the
+[`SlidingWindow` engine](../accepted/sliding_transform.md). Implements the
 system-dependent half of operator-state algebra:
 `Operator·Ket → applied_state`, `Bra·Operator → applied_state` (when
 explicit rules exist), `Pow(Op, n) · Ket` repeated application,
@@ -281,7 +281,7 @@ parent. Why `mul` and not `ncmul` as the wrapper:
 - `ncmul(...)` would route the same cascade output through its own
   partitioning anyway — the result is identical, but the `mul`
   wrapper is more explicit about the intent.
-- Per [`sliding_transform.md`](../proposed/sliding_transform.md) §4.5: "Prefer
+- Per [`sliding_transform.md`](../accepted/sliding_transform.md) §4.5: "Prefer
   `Mul` explicitly when uncertain."
 
 The cascade's `qapply_spec` is **NCMul-headed** so its
@@ -1002,7 +1002,7 @@ semantics.
 
 Every recursive `ctx.qapply` call consumes one unit of
 `Context::max_strategy_depth` (default `10_000` per
-[`sliding_transform.md`](../proposed/sliding_transform.md) §A.2.4). For
+[`sliding_transform.md`](../accepted/sliding_transform.md) §A.2.4). For
 G-deep gate circuits the depth is `O(G)`; budget exhaustion
 manifests at G ≳ 10⁴, far beyond practical needs. Users with
 unusual depth requirements can raise the budget explicitly.
@@ -1126,7 +1126,7 @@ intermediate result
 
 The splice combinator path through `evaluate_splice_combinator` →
 `run_sliding_window` is exactly as documented in
-[`sliding_transform.md`](../proposed/sliding_transform.md) §3.6 and exists in
+[`sliding_transform.md`](../accepted/sliding_transform.md) §3.6 and exists in
 `pattern.rs:2071`. No engine changes required.
 
 For the cascade output:
@@ -2055,7 +2055,7 @@ fixture(s) the Rust test consumes and any cross-coverage in
    can be much simpler than SymPy's.
 
 3. **NCMul-headed cascade with `mul(...)` wrapper.** Per
-   [`sliding_transform.md`](../proposed/sliding_transform.md) §4.5, this is
+   [`sliding_transform.md`](../accepted/sliding_transform.md) §4.5, this is
    the safe combination: NCMul-head flattens both `Mul` and
    `NCMul` wrappers (so scalar coefficients from rules reach
    c_parts), and the `mul(...)` wrapper accepts the c_parts
@@ -2069,7 +2069,7 @@ fixture(s) the Rust test consumes and any cross-coverage in
    which reuses the same reverse cascade on a daggered expression.
 
 5. **Single binary dispatcher with priority match arms.** Per
-   [`sliding_transform.md`](../proposed/sliding_transform.md) Decision 8, all
+   [`sliding_transform.md`](../accepted/sliding_transform.md) Decision 8, all
    binary cases live in one match expression. Match-arm order is
    priority order: specific operator-state cases first, then
    binder combinations, then Add/binder distribution, then

spec/accepted/quantum_systems.md

@@ -1162,7 +1162,7 @@ fn phonon_field_system() -> QuantumSystem {
   in favor of `swap_rules` for unusual cases.
 - **Anyons / multiplicative swaps.** `a·a' → e^{iθ}·a'·a` doesn't fit the
   `X·Y → Y·X + remainder` shape. Future spec, possibly built on
-  `proposed/sliding_transform.md`.
+  `accepted/sliding_transform.md`.
 - **Imperative escape hatch.** Rejected — `swap_rules` and `Guard` strategies
   cover the cases that motivated it.
 - **`rewrite_rules` and `rewrite_with(expr, name)`.** Named user-invocable

spec/accepted/sequence_bindings.md

@@ -379,6 +379,6 @@ Proposed landing order, each a self-contained PR:
 4. **Splice combinators (optional).** `Filter`, `Reverse`, `Sort` — same
    shape as `Map`.
 5. **Spec acceptance.** Move this document to `spec/accepted/` and update
-   `pattern_matching.md` and `strategies.md` to reference it.
+   `strategies.md` to reference it.
 
 Phases 1–3 cover the motivating use cases; phase 4 is incremental.

spec/accepted/strategies.md

@@ -867,7 +867,7 @@ for step in trace:
 
 ### Phase 4: Domain Strategies
 
-1. Port `trig_expand`, `trig_simplify`, etc. (from `function_simplification.md`) as
+1. Port `trig_expand`, `trig_simplify`, etc. (function-simplification operations) as
    named strategies built from rules.
 2. Add `SlidingWindow` variant to `Strategy` enum for NCMul quantum rewrites.
 3. Build quantum normalization pipeline strategy.

spec/accepted/strategy_as_expr.md

@@ -511,14 +511,10 @@ named strategies gone, the walk is exact: it visits every node in the strategy s
 and returns `true` iff it finds `Expr::RandomChoice(_)`. For `Expr::StrategyFn`, the
 walk conservatively returns `true` (we cannot inspect closures) — same precedent.
 
-**"What about the impact on downstream specs?"** The following proposed specs reference
+**"What about the impact on downstream specs?"** Other specs that reference
 strategies:
-- `proposed/function_simplification.md` — will compose domain rules via strategy
-  combinators. Simpler under this proposal.
-- `proposed/sliding_transform.md` — may use strategy primitives for rule dispatch.
+- `accepted/sliding_transform.md` — uses strategy primitives for rule dispatch.
   Simpler under this proposal.
-- `proposed/pattern_matching.md` (research) — no structural changes needed; `Rule`
-  is still a two-`ExprRef` pair.
 
 ## Migration Plan
 

spec/design.md

@@ -122,6 +122,9 @@ move from **proposed** to **accepted** once they are implemented and validated.
 | [evaluate.md](accepted/evaluate.md) | Top-level semantic evaluation transform — opt-in head-driven `evaluate(...)` |
 | [qapply.md](accepted/qapply.md) | Operator Application — system-aware operator-on-state evaluation, Add / Sum / Integral distribution, built on the SlidingWindow engine |
 | [conjugate.md](accepted/conjugate.md) | Complex Conjugation Variant — first-class `Conjugate` head with three-involution collapse rules (D = T∘C = C∘T) |
+| [sliding_transform.md](accepted/sliding_transform.md) | Sliding Transform engine + StrategyRef primitive + change_only combinator (Phase 1 — `qapply` and NCMul canonicalization are built on it) |
+| [integral_evaluation.md](accepted/integral_evaluation.md) | Integral Evaluation — Direct Rule Table |
+| [density_operator.md](accepted/density_operator.md) | Density Operator Variant |
 
 ### Proposed
 
@@ -131,19 +134,14 @@ Ordered by implementation priority, respecting dependencies.
 |:----:|------|-------------|
 | 1 | [expand.md](proposed/expand.md) | Top-level algebraic expansion transform — opt-in strategy-driven `expand(...)` mirroring `evaluate`'s architecture (distribute, power, trig, exp, log, commutator, anticommutator, func) |
 | 2 | [special_functions.md](proposed/special_functions.md) | Special Functions Catalog |
-| 3 | [function_simplification.md](proposed/function_simplification.md) | Function Simplification and Rewriting (depends on strategies) |
-| 4 | [integral_evaluation.md](proposed/integral_evaluation.md) | Integral Evaluation — Direct Rule Table |
-| 5 | [decision_procedures.md](proposed/decision_procedures.md) | Boolean Decision Procedure (Tier 1) and SMT Backend Hook (Tier 2) |
-| 6 | [tensors.md](proposed/tensors.md) | Tensors — Abstract Index Notation |
-| 7 | [sliding_transform.md](proposed/sliding_transform.md) | Sliding Transform engine + StrategyRef primitive + change_only combinator (Phase 1; quantum canonicalization and qapply land as follow-up specs) |
-| 8 | [density_operator.md](proposed/density_operator.md) | Density Operator Variant |
+| 3 | [decision_procedures.md](proposed/decision_procedures.md) | Boolean Decision Procedure (Tier 1) and SMT Backend Hook (Tier 2) |
+| 4 | [tensors.md](proposed/tensors.md) | Tensors — Abstract Index Notation |
+| 5 | [represent.md](proposed/represent.md) | Represent — project a quantum expression into a chosen basis (`represent` / `represent_in`), producing a concrete Matrix/Vector, kernel, or scalar |
 
 The following are long-form design documents and research/exploration notes
 rather than ranked implementation specs:
 
 | Spec | Description |
 |------|-------------|
 | [predicate_system.md](proposed/predicate_system.md) | Predicate System — Design Research |
-| [pattern_matching.md](proposed/pattern_matching.md) | Pattern Matching and Transformation — Design Research |
-| [design_alternatives.md](proposed/design_alternatives.md) | Design Alternatives for Extensibility |
 | [documentation.md](proposed/documentation.md) | Narrative Documentation — IA, outline, agent authoring conventions, notebook template |

spec/proposed/decision_procedures.md

@@ -562,7 +562,7 @@ consults `query(x, Pred::Real)`, this collapses to `Number(1)` directly.
 
 ### 4. Pattern matching guards
 
-The future `pattern_matching.md` spec will introduce side conditions
+A future pattern-matching spec will introduce side conditions
 ("apply rule R only when `n > 0`"). Those guards are exactly Boolean
 formulas over relation atoms — Tier 1 is the natural decision procedure
 for them. This spec doesn't depend on pattern matching landing first;