Companion-side bookkeeping for the M29 cross-repo fix.

The technical work itself shipped at paiml/aprender#1103 — five-whys
analysis of `apr code` against Qwen3-Coder-30B-A3B-Instruct.gguf
failing with "Tensor 'blk.0.ffn_up.weight' not found", traced to
the contract treating GGUF tensor naming as a flat fallback rather
than an architecture-aware namespace. Fix:

  contracts/tensor-names-v1.yaml v1.0.0 → v1.1.0
    - 6 new architecture_map entries → qwen3_moe
    - dense FFN roles marked required_per_arch.qwen3_moe = false
    - 4 new MoE-specific layer roles
    - F-TNV-002 falsifier validated against the real 17.3 GB GGUF

  crates/aprender-serve/{src,tests}/...:
    - normalize_architecture extended for 6 new HF class names
    - 4 new falsification tests including a live-GGUF-inventory check

Spec relevance: the M28 ccpa measure → apr code --emit-trace
measurement path cannot produce a non-tautological FALSIFY-CCPA-013
discharge against tool-dispatching fixtures until apr-code can
actually run a capable model. M28 + M29 are the two cleanly-
separable enabling steps. Full MoE forward-pass implementation
remains a separate larger workstream.

Contract bump v1.16.0 → v1.17.0 with full five-whys transcript +
the cross-repo fix narrative; aprender contract-mirror at byte-
identical commit 499f8b978; pin.lock refreshed via the M22 4-step
ritual.

Gates (all green locally):
  pv validate / pv lint                       PASS
  pmat comply check (is_compliant)            true, 0 Fail, 12 advisory Warn
  cargo test --workspace                      all pass (0 new tests companion-side)
  scripts/pin-check.sh                        sha256 matches
  scripts/pin-check-roundtrip.sh              byte-identical to aprender@499f8b978

Refs: paiml/aprender#1103 (M29 upstream contract PR)
      contracts/claude-code-parity-apr-v1.yaml § status_history (M29)

Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>

…oseout (#35)

The companion-side spec markdown's milestone table stopped at M27.
M28 (apr code --emit-trace + Qwen3-Coder default + qwen3-coder
short-name alias) and M29 (five-whys + tensor-names-v1 v1.1.0
contract amendment + F-TNV-002 falsifier) both landed at aprender
main but their narrative hadn't reached the spec.

This PR closes that gap:

  - status snapshot bumped: M0–M30 all SHIPPED, contract v1.18.0
  - new line on the M28+M29 cross-repo enabling chain
  - sub-milestones table extended through M30:
      M28 — cross-repo apr code --emit-trace + default model
      M29 — qwen3_moe contract amendment v1.1.0 + F-TNV-002 falsifier
            (paiml/aprender#1103 merged at 15d504cfe)
      M30 — this spec-table refresh (closeout)
  - outstanding next-goal reframed: MoE forward-pass implementation
    is the only piece remaining for a measured tool-dispatch parity
    score. That's realizar/aprender-serve engineering — not a CCPA
    POC scope item. The contract namespace, falsifier, model
    availability, and emit-trace plumbing are all in place.

State at M30 close:
  - Companion-side spec POC: complete (M0–M30 all SHIPPED)
  - Aprender-side enabling chain (M28+M29): complete
  - Both repos byte-identical at sha256
    7b1d79db710a91786033792a68b32a3cc7396472f7f7a61413c3e87728f88752
  - 13/13 falsification gates green
  - Corpus complete (30/30 fixtures, 15/15 reachable)
  - 100% mutation coverage workspace-wide
  - Companion ↔ aprender drift guard mechanically enforced
  - Contributor onramp documented (CONTRIBUTING.md)
  - Cross-repo audit trail intact across status_history

Contract bump v1.17.0 → v1.18.0 with the M30 status_history entry
documenting the doc closeout. Aprender mirror pushed in paired
commit b7f42619d. pin.lock refreshed via the M22 4-step ritual.

Gates (all green locally):
  pv validate / pv lint                       PASS
  pmat comply check (is_compliant)            true, 0 Fail, 12 advisory Warn
  cargo test --workspace                      all pass (0 new tests)
  scripts/pin-check.sh                        sha256 matches
  scripts/pin-check-roundtrip.sh              byte-identical to aprender@b7f42619d

Refs: paiml/aprender#1103 (M29 contract — merged 15d504cfe)
      contracts/claude-code-parity-apr-v1.yaml § status_history (M30)

Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>

…oE forward gap

M32a — first slice of the MoE forward-pass implementation chain that the
companion claude-code-parity-apr POC named as the "Outstanding next-goal
(in-scope, M32)" in v1.19.0 (M31 spec).

WHY THIS CONTRACT EXISTS
========================
`apr run <qwen3-coder>.gguf` currently fails with:

  Invalid shape: Tensor 'blk.0.ffn_up.weight' not found

at the FFN load step. The M29 contract amendment (tensor-names-v1
v1.1.0, #1103) declared the qwen3_moe tensor namespace
but explicitly deferred the forward-pass implementation. This contract
discharges that deferral with a 4-stage staged plan.

WHAT THIS PR SHIPS
==================
A KernelContract `qwen3-moe-forward-v1.yaml` (DRAFT status) that:

  * Composes existing kernels: tensor-names-v1 v1.1.0 + moe-router-v1 +
    moe-expert-dispatch-v1 + qwen3moe-shapes-v1 + swiglu-kernel-v1 +
    silu-kernel-v1 + rmsnorm-kernel-v1 + rope-kernel-v1
  * Names 5 acceptance criteria (AC_QW3_MOE_001 .. _005)
  * Names 4 implementation stages (M32a SHIPPED, M32b/c/d PENDING)
  * Names 4 falsification tests (F-QW3-MOE-FORWARD-001 REPRODUCED at
    commit 15d504c = end of M29; the other three are PENDING and
    each maps to one stage)
  * Names the Qwen3-Coder-30B-A3B-Instruct shape algebra explicitly
    (L=48, d=2048, d_ff=6144, N_experts=128, k=8, n_heads=32, n_kv=4,
    vocab=151936, RoPE θ=1e7) so the contract is testable on the live
    cached GGUF (~/.cache/pacha/models/2b88b180a790988f.gguf, 17.3 GB)

WHAT M32b/c/d WILL SHIP (in subsequent PRs)
============================================
M32b: Architecture-aware FFN load. Branch transformer_loader.rs (line
      ~145) on tensor_names_fallback::normalize_architecture(...).
      For arch == "qwen3_moe", load the 4 contract-named tensors per
      layer (ffn_gate_inp/ffn_gate_exps/ffn_up_exps/ffn_down_exps)
      into a new MoeLayerWeights field. Forward emits structured
      UnsupportedOperation containing this contract's id.

M32c: Wire CPU MoE forward. The pure-Rust moe_forward_token in
      gpu/scheduler/moe_dispatch.rs already implements the full
      router + per-expert SwiGLU + weighted aggregation kernel.
      Populate MoeExpertWeights from M32b-loaded tensors and call
      it from the FFN dispatch site. After M32c, `apr run` emits
      tokens.

M32d: Numerical parity vs llama.cpp Q4_K (primary) + HF FP16
      (secondary) per CLAUDE.md ground-truth checklist. Discharges
      AC_QW3_MOE_001 and AC_QW3_MOE_005. Flips this contract from
      DRAFT to ACTIVE_RUNTIME and unblocks companion-repo
      FALSIFY-CCPA-013 measured tool-dispatch parity score.

CROSS-REPO LINKS
================
This contract is the aprender-side spine of:

  * paiml/claude-code-parity-apr v1.19.0 (M31 spec, 2026-04-28) —
    "Outstanding next-goal (in-scope, M32)" was created exactly for
    this 4-stage plan; the user clarified at M31 that aprender and
    claude-code-parity-apr are the same monorepo, so this work IS
    in-scope companion-repo work, not "upstream realizar engineering"

  * paiml/aprender contracts/tensor-names-v1.yaml v1.1.0 (M29) —
    declared the namespace this contract operates over

VALIDATION
==========
$ pv validate contracts/qwen3-moe-forward-v1.yaml
0 error(s), 0 warning(s)
Contract is valid.

NO CODE CHANGE in this PR. M32a is contract-only by design; M32b is
where Rust changes start. Authoring contract before code per CLAUDE.md
rule 1 (CB-1400).

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>