Re-verified all blob-shaped object literals against current code. The prior docs drifted: quick-actions.test.js was mis-counted as 16 literals (actual 5) and only 4 of 6 ambient.test.js blob-array sites were documented. Corrections (notes/bf-26ta-findings.md, bf-26ta-javascript-results.md): - Add missing ambient.test.js sites at lines 694 (lerp source) and 708 (lerp target) - Fix quick-actions.test.js count: 16 -> 5 literals (lines 208, 316, 470, 513, 678) - Fix JS totals: 25 across 7 files -> 14 across 5 files - state.js:290, websocket.js:167, replay.test.js:101 unchanged (still accurate) - TypeScript: still 0 literals (only spaxel.d.ts type defs) Co-Authored-By: Claude <noreply@anthropic.com>
11 KiB
bf-26ta: JavaScript Blob-Shaped Object Literal Search Results
Task Summary
Search all JavaScript files (.js and .jsx) for blob-shaped object literals using the pattern defined in bf-3aij.
Search Scope
- Total JavaScript files searched: 80 (.js and .jsx files)
- Files excluded: node_modules, dist, .beads directories
- Pattern matched: Object literals with blob structure (position fields, identity fields, tracking fields)
Search Results Summary
Blob-Shaped Object Literals Found: 14 instances across 5 files
Re-verified 2026-07-06: previously reported "25 across 7 files" over-counted
quick-actions.test.js(16 reported, 5 actual literals) and listed only 4 of the 6ambient.test.jssites. Corrected below.
Detailed Findings
1. dashboard/js/state.js - Core State Management
File: dashboard/js/state.js:290-295
Primary blob creation pattern in state management
// Line 290-295: Default blob initialization in updateBlob()
appState.blobs[id] = {
id: id,
personName: undefined,
assignedColor: undefined,
identityResolved: undefined
};
Context: This is the canonical blob object creation pattern in the central state management system. When a blob is first created, it's initialized with identity fields set to undefined, then populated via Object.assign() with server-provided data (position, velocity, confidence).
Pattern Type: State initialization object literal
2. dashboard/js/ambient.test.js - Ambient Renderer Tests
File: dashboard/js/ambient.test.js
Multiple blob test fixtures for 3D ambient rendering tests
// Line 124-134: Full blob with identity fields
blobs: [{
id: 1,
x: 2,
y: 2,
z: 0,
confidence: 0.8,
person: 'Alice',
personName: undefined,
assignedColor: undefined,
identityResolved: undefined
}]
// Line 276-284: Minimal blob with identity fields
blobs: [{
id: 1,
x: 2,
y: 2,
z: 0,
personName: undefined,
assignedColor: undefined,
identityResolved: undefined
}]
// Line 642-648: Position-only blob with confidence
blobs: [{
id: 1,
x: 1,
y: 1,
z: 0,
confidence: 0.8
}]
// Line 659-665: Position blob (different coordinates)
blobs: [{
id: 1,
x: 3,
y: 3,
z: 0,
confidence: 0.8
}]
- Line 694-700: Position blob at (1,1) — lerp source fixture
blobs: [{id: 1, x: 1, y: 1, z: 0, confidence: 0.8}]
- Line 708-714: Position blob at (3,3) — lerp target fixture
blobs: [{id: 1, x: 3, y: 3, z: 0, confidence: 0.8}]
Context: Test fixtures for the 3D ambient floor plan renderer. These blobs represent detected people in 2D floor space for testing the ambient visualization system.
Pattern Types:
- Full blob with position + confidence + identity
- Minimal blob with position + identity
- Position-only blob with confidence
3. dashboard/js/quick-actions.test.js - Quick Actions Tests
File: dashboard/js/quick-actions.test.js
Blob objects for testing spatial quick actions menu
// Line 208-214: SpaxelState blob assignment
window.SpaxelState.set('blobs', 123, {
id: 123,
person: 'Alice',
x: 2,
y: 0,
z: 3
});
// Line 316-322: Minimal blob for menu testing
const blob = {
id: 123,
person: 'Alice',
x: 2,
y: 0,
z: 3
};
// Line 365-373: Zone object (NOT a blob - has dimensions)
const zone = {
id: 1,
name: 'Kitchen',
x: 0,
y: 0,
z: 0,
w: 4,
d: 3,
h: 2.5
};
// Line 470-476: Blob for camera follow testing
const blob = {
id: 123,
person: 'Alice',
x: 2,
y: 0,
z: 3
};
// Line 513-519: Blob for follow indicator testing
const blob = {
id: 123,
person: 'Alice',
x: 2,
y: 0,
z: 3
};
// Line 678: Minimal inline blob (compressed format)
const blob = { id: 123, x: 2, y: 0, z: 3, personName: undefined, assignedColor: undefined, identityResolved: undefined };
Context: Test fixtures for spatial quick actions (context menu when clicking on blob elements in the UI). Tests menu items, camera follow mode, and identity assignment features.
Pattern Types:
- Minimal blob with id + position + person
- Identity field variations (personName, assignedColor, identityResolved)
- Note: Zone object included for comparison (not a blob due to dimensions w, d, h)
4. dashboard/js/replay.test.js - Session Replay Tests
File: dashboard/js/replay.test.js:101-113
Extended blob with velocity and posture fields
blobs: [
{
id: 1,
x: 2.5,
y: 1.3,
z: 0.8,
vx: 0.1, // Velocity X
vy: 0.0, // Velocity Y
vz: 0.0, // Velocity Z
weight: 0.85, // Detection confidence
posture: 'standing' // Body posture
}
]
Context: Mock API response for session replay functionality. This represents the most complete blob structure with velocity vectors and posture information for historical replay scenarios.
Pattern Type: Extended blob with velocity + posture fields
5. dashboard/js/websocket.js:167-173 - WebSocket Message Handler
Blob state capture for position extrapolation
// Line 167-173: Capture blob position and velocity
_blobStates.set(b.id, {
x: b.x,
z: b.z,
vx: b.vx || 0,
vz: b.vz || 0,
ts: Date.now()
});
Context: This captures minimal blob state (position + velocity + timestamp) for dead reckoning extrapolation when WebSocket connection is lost. The system extrapolates blob positions based on last known velocity.
Pattern Type: Derived blob state object (minimal extrapolation state)
6. dashboard/js/ambient_renderer.js:624-647 - Blob Rendering Logic
Blob field access for rendering (not object creation)
// Line 624-626: Confidence-based radius calculation
const confidence = blob.confidence || 0.5;
const radius = 10 + (confidence * 8); // 10-18px
// Line 632-633: Person name field fallback chain
const personName = blob.personName || blob.person_label || blob.person || null;
// Line 636-640: Color assignment from blob fields
if (blob.assignedColor) {
blobColor = blob.assignedColor;
} else if (personName) {
blobColor = getPersonColor(personName);
}
// Line 645-646: Identity resolution check
} else if (blob.identityResolved === false) {
displayName = '?'; // Explicitly unresolved
}
Context: These are blob field access patterns (not object creation), showing how the renderer consumes blob objects for 3D visualization.
Pattern Type: Blob field consumption (not creation)
Blob Field Usage Summary
Core Fields (Always Present)
- id - Numeric/string identifier for the blob
- x, y, z - 3D world-space position (metres)
Extended Fields (Commonly Used)
- confidence/weight - Detection confidence [0-1]
- person/personName - Associated person identity
- assignedColor - Hex color for dashboard rendering
- identityResolved - Boolean flag for identity confirmation
Velocity Fields (Optional)
- vx, vy, vz - Velocity components (m/s) for extrapolation
Posture Field (Rare)
- posture - Body posture state ('standing', 'walking', 'seated', 'lying')
Legacy/Deprecated Fields
- person_label - Superseded by personName
- personColor - Superseded by assignedColor
Blob Creation Patterns by Category
1. State Initialization (Most Common)
Location: dashboard/js/state.js:290
appState.blobs[id] = {
id: id,
personName: undefined,
assignedColor: undefined,
identityResolved: undefined
};
Purpose: Initialize new blob state entry before populating with server data
2. Test Fixtures (High Variance)
Locations: dashboard/js/ambient.test.js, dashboard/js/quick-actions.test.js
- Minimal:
{id, x, y, z} - Extended:
{id, x, y, z, confidence, person, personName, assignedColor, identityResolved} - Velocity:
{id, x, y, z, vx, vy, vz, weight, posture}
Purpose: Test data for rendering, menu interactions, and replay features
3. API Mocks
Location: dashboard/js/replay.test.js:101
{
id: 1,
x: 2.5,
y: 1.3,
z: 0.8,
vx: 0.1,
vy: 0.0,
vz: 0.0,
weight: 0.85,
posture: 'standing'
}
Purpose: Simulate server blob responses for session replay API
4. Extrapolation State (Derived)
Location: dashboard/js/websocket.js:167
{
x: b.x,
z: b.z,
vx: b.vx || 0,
vz: b.vz || 0,
ts: Date.now()
}
Purpose: Capture minimal state for dead reckoning during disconnection
Comparison with Related Structures
Zone Objects (Similar but Different)
Example from quick-actions.test.js:365:
const zone = {
id: 1,
name: 'Kitchen',
x: 0,
y: 0,
z: 0,
w: 4, // Width
d: 3, // Depth
h: 2.5 // Height
};
Distinguishing Features:
- Zones have dimensions (w, d, h) - blobs don't
- Zones have name field - blobs have person/personName
- Zones represent static spaces - blobs represent moving people
Node Objects
Pattern: Use mac instead of id for identification
Event Objects
Pattern: Include timestamp_ms, type, severity instead of position fields
Files Summary
| File | Blob Count | Pattern Type | Context |
|---|---|---|---|
dashboard/js/state.js |
1 | State initialization | Central state management |
dashboard/js/ambient.test.js |
6 | Test fixtures | 3D ambient rendering tests |
dashboard/js/quick-actions.test.js |
5 | Test fixtures | Spatial menu tests |
dashboard/js/replay.test.js |
1 | API mock | Session replay tests |
dashboard/js/websocket.js |
1 | Derived state | Position extrapolation |
| Total | 14 | Multiple patterns | 5 files |
Key Findings
Blob Creation Hotspots
- State management (
state.js:290) - Single canonical creation pattern - Test files (
ambient.test.js,quick-actions.test.js) - High variance for coverage - API mocks (
replay.test.js) - Full blob structure simulation
Field Usage Patterns
- Position fields (x, y, z) are mandatory in all blob objects
- Identity fields (person, personName, assignedColor, identityResolved) appear in ~60% of instances
- Velocity fields (vx, vy, vz) appear only in replay scenarios
- Confidence/weight appears in ~40% of instances
Architecture Insights
- Centralized creation: Blob state is managed centrally in
state.js - Test diversity: Tests cover minimal to full blob structures
- Field fallbacks: Renderers use fallback chains (personName → person_label → person)
- Extrapolation support: Minimal blob state used for dead reckoning during disconnections
Conclusion
The JavaScript codebase contains 14 blob-shaped object literals across 5 files, with patterns ranging from minimal state initialization to comprehensive test fixtures. The canonical creation pattern is in state.js:290, while test files provide diverse blob structures for comprehensive coverage of rendering, interaction, and replay functionality.
Blob detection pattern: Look for objects with {id, x, y, z} core structure, optionally extended with identity, velocity, or confidence fields.