wf(wf-jssdk-qs01): [FIX-R1] correct stale RED/TDD comments in anchored test files

Beads: ai-driven-product-dev-kz6x
Review R1 (conf 95): header comments claimed methods/gate not-yet-implemented (RED);
now shipped + passing. Rewrote to describe shipped behavior for sibling-SDK porters;
fixed stale data-manager.ts:620-637 -> :685 gate ref. Comment-only. Suites unchanged
(bucketing 28, data 97).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Author: abbaseya

packages/bucketing/tests/bucketing-manager-anchored.tests.ts

@@ -7,19 +7,34 @@
  */
 
 /**
- * qs-01 (BUCK-2) — anchored bucketing algorithm tests.
+ * qs-01 — anchored bucketing algorithm tests.
  *
  * Spec of record: _bmad-output/planning-artifacts/2026-07-02-convert-js-sdk/qs-01-anchored-bucketing-layout.md
  * "The contract (normative)" section, AC2/AC3/AC4/AC5.
  *
+ * These tests lock the shipped behavior of the three anchored bucketing methods on
+ * BucketingManager (packages/bucketing/src/bucketing-manager.ts): `getBucketRanges`
+ * (builds the anchor/width layout from a set of variation allocations), `selectBucketAnchored`
+ * (resolves a raw bucket value against that layout via a half-open [anchor, anchor + width)
+ * interval), and `getBucketForVisitorAnchored` (reuses the existing visitor-based hash,
+ * unmodified, and routes it through the two methods above). Together the suites below verify:
+ *   - the raise-superset property: anchors are computed over the total weight of ALL
+ *     entries so growing an experience's total allocation only ever grows arms and never
+ *     reshuffles an already-bucketed visitor into a different arm (AC2 thirds/superset
+ *     fixtures);
+ *   - half-open boundary semantics at the anchor and anchor + width edges (AC5);
+ *   - zero/inactive-arm handling: stopped or explicit zero-allocation entries keep their
+ *     weight for anchor stability but get a zero-width range so they can never be selected,
+ *     and a totalWeight <= 0 layout yields no bucketing (AC4/AC5);
+ *   - determinism: getBucketForVisitorAnchored returns the same result for the same
+ *     (visitorId, experienceId) and matches selectBucketAnchored(getBucketRanges(...), hash)
+ *     composed directly from the existing hash oracle.
+ *
  * Expected numbers below are derived BY HAND directly from the spec's normative
  * pseudocode (anchor = (cumWeight / totalWeight) * 10000; width = active ? allocation * 100 : 0),
  * written as literal arithmetic expressions so the doubles are IEEE754-exact and
  * independently verifiable against the spec's layout table — never computed by calling
- * the SUT. `getBucketRanges`, `selectBucketAnchored` and `getBucketForVisitorAnchored`
- * are declared on BucketingManagerInterface (packages/bucketing/src/interfaces/bucketing-manager.ts)
- * but are NOT YET implemented on the BucketingManager class — every assertion below is
- * expected to FAIL (RED) until BUCK-3 implements them.
+ * the SUT.
  */
 import 'mocha';
 import {expect} from 'chai';
@@ -154,9 +169,9 @@ const ZERO_TOTAL_WEIGHT_CASES: Array<{
 ];
 
 describe('BucketingManager anchored tests (qs-01 / BUCK-2 — contract v9 anchored algorithm)', function () {
-  // Matches the existing packed-path suite's convention: no explicit type annotation,
-  // so calls to the not-yet-implemented anchored methods do not introduce additional
-  // (pre-implementation) compile errors beyond the ones already tracked separately.
+  // Matches the existing packed-path suite's convention: no explicit type annotation
+  // is needed since the anchored methods are implemented directly on the
+  // BucketingManager class.
   let bucketingManager;
 
   beforeEach(function () {

packages/data/tests/data-manager-anchored-gate.tests.ts

@@ -6,41 +6,43 @@
  */
 
 /**
- * qs-01 (DATA-1) — anchored-vs-packed GATE tests in DataManager._retrieveBucketing.
+ * qs-01 — anchored-vs-packed GATE tests in DataManager._retrieveBucketing.
  *
  * Spec of record: _bmad-output/planning-artifacts/2026-07-02-convert-js-sdk/qs-01-anchored-bucketing-layout.md
  * "The contract (normative)" section (the Gate paragraph + the allocation-build mapping),
  * AC1, AC4, AC8, AC9.
  *
- * The gate ("run anchored iff Number(experience.version) > 8") does not exist yet in
- * DataManager._retrieveBucketing's fresh-bucketing branch (packages/data/src/data-manager.ts:620-637)
- * -- every experience, regardless of `version`, currently goes through the existing packed
- * cumulative walk. The AC1 and AC4 assertions below therefore FAIL today (RED) because the
- * disagreement they assert between "what a version-9 experience should do" (anchored) and
- * "what it actually does" (still packed, pre-implementation) is real. AC8/AC9 protect
- * EXISTING behavior that runs entirely before/independently of the gate (the stored-decision
- * guard short-circuits before the version check is ever reached; the returned object's shape
- * doesn't change with the algorithm) -- those are expected to already PASS, and are included
- * as regression locks for after the gate lands. See this feature's decision log for why each
- * fixture is (or isn't) expected to fail pre-implementation.
+ * These tests lock the shipped gate in DataManager._retrieveBucketing's fresh-bucketing
+ * branch (packages/data/src/data-manager.ts:685): `Number(experience.version) > 8` routes
+ * fresh bucketing through the anchored layout (built by `_buildVariationAllocations`,
+ * data-manager.ts:586, and resolved via `BucketingManager.getBucketForVisitorAnchored`);
+ * version <= 8, missing/undefined, or non-numeric version keeps the existing packed
+ * cumulative walk unchanged (built by `_buildPackedBuckets`, data-manager.ts:556, and
+ * resolved via `BucketingManager.getBucketForVisitor`). AC1 asserts the gate actually
+ * branches by exploiting a real packed-vs-anchored disagreement on the same fixture (see
+ * below). AC4 asserts stops only zero their own width under the anchored path and never
+ * move neighboring arms' anchors. AC8/AC9 protect existing behavior that runs entirely
+ * before/independently of the gate: the stored-decision guard (data-manager.ts:658-665)
+ * short-circuits before the version check is ever reached, and the returned
+ * BucketedVariation shape is unchanged across versions.
  *
  * Fixture derivation methodology: every raw bucket VALUE used below (e.g. 4957, 9807, 102)
  * is a real MurmurHash3 output from BucketingManager.getValueVisitorBased -- the same,
  * already-implemented, already-unit-tested hash oracle the packed and anchored paths both
- * call unmodified (packages/bucketing/src/bucketing-manager.ts:95-108; see
+ * call unmodified (packages/bucketing/src/bucketing-manager.ts:91-112; see
  * packages/bucketing/tests/bucketing-manager.tests.ts for its own tests). Values were
  * derived once (for the fixed (visitorId, experienceId) string pairs used below, with the
  * default hash seed) via that exact method, then frozen as literal numbers so every
  * packed/anchored expectation in this file is independently re-derivable by hand from the
  * spec's normative formulas (anchor = (cumWeight / totalWeight) * 10000; width = active ?
  * allocation * 100 : 0) against the fixed traffic_allocation values declared alongside them,
- * without needing to re-run any tool. This is the same class of technique BUCK-2 used to
- * freeze its THIRDS_15/THIRDS_25 expected ranges from the spec's own pseudocode, applied one
- * level up (the raw hash value is looked up from the hash oracle instead of hand-computed,
- * since MurmurHash3 output cannot reasonably be hand-derived; everything downstream of that
- * single looked-up number -- which bucket it falls into under each layout -- is plain
- * arithmetic against the fixed weights, independently checkable inline in each fixture's
- * comment).
+ * without needing to re-run any tool. This is the same class of technique used in
+ * bucketing-manager-anchored.tests.ts to freeze its THIRDS_15/THIRDS_25 expected ranges
+ * from the spec's own pseudocode, applied one level up (the raw hash value is looked up
+ * from the hash oracle instead of hand-computed, since MurmurHash3 output cannot reasonably
+ * be hand-derived; everything downstream of that single looked-up number -- which bucket it
+ * falls into under each layout -- is plain arithmetic against the fixed weights,
+ * independently checkable inline in each fixture's comment).
  */
 import 'mocha';
 import {expect} from 'chai';