- 04 Jun, 2026 5 commits
-
-
cnb.bofCdSsphPA authored
-
Constraint: The startup handoff must reflect the new Phase-1 encoder-only and PostgreSQL v2 decisions without carrying stale timeline noise Rejected: Keep appending runtime logs to session-handoff.md | It obscures the current start point for the next session Confidence: high Scope-risk: narrow Directive: Keep session-handoff.md focused on where to resume next, and move detailed chronology into changelog/history docs Tested: git diff --check -- docs/session-handoff.md docs/CHANGELOG.md Not-tested: No link checker or markdown linter was run
cnb.bofCdSsphPA authored -
Constraint: The architecture and schema docs were already in place, but teams still lacked a concrete implementation checklist and registry bootstrap contract for encoder-only rollout Rejected: leaving execution guidance implicit in architecture prose | would slow Phase-1 delivery and cause inconsistent model/feature initialization Confidence: high Scope-risk: narrow Directive: treat Phase-1 implementation sequencing and model/feature/reference-set bootstrap as first-class docs that evolve with the schema Tested: git diff --check on changed docs; Python document sanity check; README/CHANGELOG link coverage verified with rg Not-tested: no runtime behavior changed; no database apply executed
cnb.bofCdSsphPA authored -
Constraint: The documentation refactor was already pushed and only needed a formatting-only hygiene follow-up Rejected: leaving known markdown whitespace debt in the freshly introduced guide | would add avoidable noise to future reviews Confidence: high Scope-risk: narrow Directive: keep the new role-oriented architecture docs diff-clean so future schema/model edits stay reviewable Tested: git diff --check on docs/acr-architecture.md Not-tested: content semantics unchanged; no runtime effects
cnb.bofCdSsphPA authored -
Constraint: Phase-1 must support encoder-only open-source backbones without destabilizing future schema evolution Rejected: extending the old flat song_id + fixed-vector schema | would couple model swaps to schema rewrites and weaken copyright lineage Confidence: high Scope-risk: moderate Directive: treat canonical_song/work/recording/recording_asset/audio_window plus model/feature registries as the stable contract; evolve models and indexes around them Tested: git diff --check on changed files; Python content/structure sanity check; architect review APPROVED; README link coverage and DDL object presence verified Not-tested: live PostgreSQL apply not run because psql is unavailable in this environment
cnb.bofCdSsphPA authored
-
- 03 Jun, 2026 15 commits
-
-
Constraint: we need a song-level evaluation path that matches the future pgvector production shape before moving off the local FAISS proving lane Rejected: jumping straight to a live pgvector-only implementation | we still need a reproducible repo-local evaluation harness and artifact trail first Confidence: high Scope-risk: moderate Directive: keep future pgvector work song_id-first and measure each query type separately before aggregating product claims Tested: /usr/local/miniconda3/bin/python -m unittest discover -s acr-engine/tests -v; /usr/local/miniconda3/bin/python acr-engine/scripts/export_workspace_music20_embeddings_jsonl.py --downloads-dir /workspace/downloads --song-limit 20 --out-dir acr-engine/data/pgvector_eval/music20; /usr/local/miniconda3/bin/python acr-engine/scripts/evaluate_songid_pgvector_path.py --reference-embeddings-jsonl acr-engine/data/pgvector_eval/music20/reference_embeddings.jsonl --query-embeddings-jsonl acr-engine/data/pgvector_eval/music20/query_embeddings.jsonl --output acr-engine/data/pgvector_eval/music20/songid_eval_report.json Not-tested: live PostgreSQL/pgvector online retrieval path
cnb.bofCdSsphPA authored -
Constraint: we need a complete hard-query picture before claiming the workspace_music20 voice lane is usable or deciding where pgvector work should start Rejected: extrapolating from type_7 alone | the type_8 and type_16 lanes can fail differently and need their own measured baselines Confidence: high Scope-risk: narrow Directive: keep all future business-corpus voice evaluations split by query type so we can see exactly which hard lanes fail and why Tested: /usr/local/miniconda3/bin/python -m unittest discover -s acr-engine/tests -v; generated voice_workspace20_type8_eval.json (top1=0.0, top3=0.0) and voice_workspace20_type16_eval.json (top1=0.0, top3=0.0) Not-tested: improved business-corpus voice correctness after moving to embedding/pgvector retrieval
cnb.bofCdSsphPA authored -
Constraint: the repo needs to distinguish runtime success from business-level song_id correctness before any production claim Rejected: treating the workspace_music20 smoke as good enough | the current type_7 batch result is top1=0.0 and top3=0.05, which is far below a usable threshold Confidence: high Scope-risk: narrow Directive: keep all future business-corpus voice evaluations written to local_eval artifacts and mirrored into changelog/checklist/handoff before push Tested: /usr/local/miniconda3/bin/python -m unittest discover -s acr-engine/tests -v; generated acr-engine/data/local_eval/voice_workspace20_type7_eval.json with num_queries=20, top1=0.0, top3=0.05 Not-tested: improved business-corpus correctness after further retrieval tuning
cnb.bofCdSsphPA authored -
Constraint: external voice uploads now need a business-sample-backed path before any pgvector production cutover, while still staying lightweight enough for CPU smoke tests Rejected: waiting for full pgvector service integration before proving a business-corpus path | would leave the external voice interface unvalidated against real sample references Confidence: medium Scope-risk: moderate Directive: treat workspace_music20 as a proving lane only; validate business top1 correctness before promoting its defaults or claiming production readiness Tested: /usr/local/miniconda3/bin/python -m unittest discover -s acr-engine/tests -v; /usr/local/miniconda3/bin/python acr-engine/scripts/service_voice_smoke.py -> status ok, corpus=workspace_music20, chunk_count=1, top_song_id=109, has_context=true Not-tested: pgvector-backed /recognize/voice production retrieval path
cnb.bofCdSsphPA authored -
Constraint: the voice service must return a payload under the current CPU environment before we can iterate on business-corpus correctness Rejected: keeping the previous multi-chunk defaults | they caused smoke-timeout regressions and blocked basic endpoint validation Confidence: high Scope-risk: moderate Directive: treat the current result as transport/runtime proof only until the service is switched from synthetic defaults to the /workspace business reference corpus Tested: /usr/local/miniconda3/bin/python -m unittest discover -s acr-engine/tests -v; /usr/local/miniconda3/bin/python acr-engine/scripts/service_voice_smoke.py -> status ok, chunk_count=1, top_song_id=song_0022, has_context=false Not-tested: business-corpus song_id correctness for /recognize/voice under /workspace reference data
cnb.bofCdSsphPA authored -
Constraint: every documented progress step in this lane must update changelog, checklist, and handoff together before pushing Rejected: leaving the handoff refresh isolated | it would break the repo's own continuity ritual and make the next session diff harder to trust Confidence: high Scope-risk: narrow Directive: when the voice service state changes, mirror it across changelog, checklist, and handoff in the same push Tested: /usr/local/miniconda3/bin/python -m unittest discover -s acr-engine/tests -v Not-tested: successful end-to-end /recognize/voice payload within timeout
cnb.bofCdSsphPA authored -
Constraint: the handoff must reflect the real runtime state: health endpoints work, CPU torch is installed, but end-to-end voice smoke still times out Rejected: keeping the older dependency-missing note | it no longer matches the current environment and would mislead the next session Confidence: high Scope-risk: narrow Directive: keep handoff notes focused on the shortest next debugging path for /recognize/voice timeout reduction Tested: /usr/local/miniconda3/bin/python -m unittest discover -s acr-engine/tests -v; /health endpoint returns ok under uvicorn with CPU torch installed Not-tested: successful end-to-end /recognize/voice payload within timeout
cnb.bofCdSsphPA authored -
Constraint: the docs must reflect the real runtime state after installing CPU torch: health is up, but end-to-end voice recognition still times out Rejected: declaring the voice API complete | the current smoke still does not return a final recognition payload within the timeout window Confidence: medium Scope-risk: narrow Directive: keep status docs synchronized with actual smoke results, especially partial readiness states Tested: /usr/local/miniconda3/bin/python -m unittest discover -s acr-engine/tests -v; /health endpoint returns ok under uvicorn; direct /recognize/voice smoke currently times out after CPU torch install Not-tested: successful end-to-end /recognize/voice result payload within timeout
cnb.bofCdSsphPA authored -
Constraint: the checklist should reflect the real current state: health endpoint is up, but full voice inference remains blocked by missing torch Rejected: marking service smoke fully passed | /recognize/voice still cannot execute end-to-end inference in this environment Confidence: high Scope-risk: narrow Directive: keep the release checklist brutally explicit about partial vs full service readiness Tested: /usr/local/miniconda3/bin/python -m unittest discover -s acr-engine/tests -v; /health endpoint reachable under uvicorn Not-tested: successful /recognize/voice inference until torch is installed
cnb.bofCdSsphPA authored -
Constraint: the handoff should reflect the current FAISS-first local workflow and the partially wired voice service without claiming end-to-end inference is ready Rejected: waiting for full torch-backed service completion before documenting progress | would hide the current repo state and block clean session handoff Confidence: high Scope-risk: narrow Directive: keep future handoff updates focused on what is runnable now, what is blocked, and the next shortest path to unblock it Tested: /usr/local/miniconda3/bin/python -m unittest discover -s acr-engine/tests -v; /usr/local/miniconda3/bin/python -m uvicorn src.service.app:app --host 127.0.0.1 --port 8000 with successful /health response Not-tested: successful /recognize/voice inference until torch is installed
cnb.bofCdSsphPA authored -
Constraint: service health and config endpoints should stay reachable even when training-time dependencies like torch are not installed Rejected: importing retrieval engines at module load | it makes the whole API crash before reporting dependency gaps clearly Confidence: high Scope-risk: narrow Directive: keep runtime dependency checks inside request-time engine loading so infra can health-check the service independently of model installation state Tested: /usr/local/miniconda3/bin/python -m unittest discover -s acr-engine/tests -v; /usr/local/miniconda3/bin/python -m uvicorn src.service.app:app --host 127.0.0.1 --port 8000 with successful /health response; POST /recognize/voice currently returns a clear 500 dependency error when torch is missing Not-tested: successful end-to-end /recognize/voice inference without torch installed
cnb.bofCdSsphPA authored -
Constraint: keep humming/recording query support lightweight and compatible with the existing FAISS-first local workflow while production retrieval remains pgvector-oriented Rejected: delaying service-path scaffolding until full production retrieval is ready | would block validation of voice-to-chunk and context export behavior Confidence: high Scope-risk: moderate Directive: keep semantics song_id-first and treat resource paths only as supporting evidence/context artifacts Tested: /usr/local/miniconda3/bin/python -m unittest discover -s acr-engine/tests -v Not-tested: live FastAPI smoke until uvicorn is available in the current interpreter environment
cnb.bofCdSsphPA authored -
Constraint: local validation should stay lightweight and use /workspace sample files while production retrieval remains pgvector-backed Rejected: making ChromaDB the default local backend | chromadb is not installed in the current environment and FAISS is already available Confidence: high Scope-risk: narrow Directive: keep local dev workflows explicitly separated from production pgvector flows in docs and scripts Tested: /usr/local/miniconda3/bin/python -m unittest discover -s acr-engine/tests -v; /usr/local/miniconda3/bin/python acr-engine/scripts/local_music20_acr.py --downloads-dir /workspace/downloads --song-limit 20 --backend faiss --output acr-engine/data/local_eval/music20_summary.json Not-tested: chromadb backend execution without installation; live pgvector database execution path
cnb.bofCdSsphPA authored -
cnb.bofCdSsphPA authored
-
Document the production decision to stabilize the embedding space before onboarding a 300k-song catalog, and record the migration rules for future encoder upgrades. Constraint: 300k-song production rollout makes embedding churn expensive and risky Rejected: keep iterating encoder before defining a production embedding version | would force repeated full-vector rebuilds and unstable rollout criteria Confidence: high Scope-risk: narrow Directive: Treat encoder changes as versioned index migrations, not in-place model swaps Tested: reviewed rendered markdown content, docs index link, changelog entry, and git diff for the three touched docs Not-tested: git push / remote sync outcome depends on repository remote state
cnb.bofCdSsphPA authored
-
- 02 Jun, 2026 20 commits
-
-
Capture the latest sweep evidence so the next session can resume cleanly. Constraint: docs only; keep large data and checkpoints out of git Rejected: leaving hum_guard unrecorded | would lose the newest verification evidence Confidence: high Scope-risk: narrow Directive: continue the next search from hum_focus Tested: reviewed the eval.json evidence and diff Not-tested: no code or model changes in this commit
cnb.bofCdSsphPA authored -
Keep the current optimization state resumable and concise. Constraint: docs only; avoid raw data, checkpoints, and __pycache__ Rejected: continuing implementation now | user requested a fast delivery package first Confidence: high Scope-risk: narrow Directive: resume from the handoff docs on the next session Tested: reviewed diff and confirmed only four docs changed Not-tested: no code or training pipeline changes in this commit
cnb.bofCdSsphPA authored -
…doff restart-safe and avoid staging temporary sweep artifacts\nRejected: Switch back to v6 or continue blind search | Fresh evidence shows hum_focus is the current best candidate and the right anchor for finer tuning\nConfidence: high\nScope-risk: narrow\nDirective: Use hum_focus as the baseline for the next micro-search, preserving humming_like gains while keeping confused at 0.25\nTested: Verified hum_focus versus hum_balanced with fresh eval results and updated docs accordingly\nNot-tested: Whether a further micro-tuned variant beats hum_focus
cnb.bofCdSsphPA authored -
…f must record the fresh dual-axis metric outcome without staging temporary smoke artifacts\nRejected: Keep tuning weights before checkpointing | The first end-to-end dual-axis result is already a meaningful evidence point and restart-safe boundary\nConfidence: high\nScope-risk: narrow\nDirective: Continue with finer-grained dual-axis weight search, targeting humming_like recovery while preserving confused gains\nTested: Verified dual-axis smoke completed train, build-index, and evaluate with top1 0.5 / topk 0.9 and updated handoff/changelog docs\nNot-tested: Improved dual-axis weight combinations beyond this first balanced trial
cnb.bofCdSsphPA authored -
…t: Keep the training pipeline behavior stable while exposing humming_like and confused controls through config only\nRejected: Add a brand-new sampler framework first | The smallest useful step is config-driven control on the existing dataset weighting path\nConfidence: high\nScope-risk: narrow\nDirective: Run weight-search experiments through training.sample_type_weights and training.pair_type_weights before attempting broader training-stack refactors\nTested: py_compile passed, train.py dry-run on synthetic_v2 passed, and custom SongPairDataset weighting instantiation produced expected hard_weight output\nNot-tested: End-to-end retraining and metric improvements from new dual-axis weight combinations
cnb.bofCdSsphPA authored -
… handoff must convert baseline metrics into an actionable causal explanation without staging report artifacts\nRejected: Start a new weighting experiment immediately | Source-backed explanation of the existing split is cheaper and reduces blind iteration risk\nConfidence: high\nScope-risk: narrow\nDirective: Treat dual-axis hard-case weighting as the next design lane, using v6 as the base and v5 as the humming_like reference\nTested: Verified source-backed v5/v6 definitions from changelog and smoke-v6 config artifacts, then updated handoff/changelog docs\nNot-tested: A new merged weighting strategy or its downstream metric impact
cnb.bofCdSsphPA authored -
… Handoff must encode the new baseline decision without staging temporary sweep artifacts\nRejected: Jump straight into retraining without baseline comparison | Fresh sweep evidence now makes a targeted v6-vs-v5 optimization path cheaper and safer\nConfidence: high\nScope-risk: narrow\nDirective: Use v6 as the overall baseline and treat v5 as the humming_like comparison target before changing training or segmentation logic\nTested: Ran a synthetic_v2 hard-case sweep across v3-v6, verified summary metrics, and updated handoff/changelog docs with the baseline decision\nNot-tested: Whether a merged v6-plus-v5 strategy improves real open-data derived hard cases
cnb.bofCdSsphPA authored -
…off must distinguish clean real-path evidence from hard-case evidence without staging temporary evaluation artifacts\nRejected: Keep scaling clean-only FMA smoke first | Fresh evidence shows the next highest-yield work is hard-case top1 improvement\nConfidence: high\nScope-risk: narrow\nDirective: Treat humming_like and confused as the primary optimization targets before investing more cycles in larger clean-only smoke runs\nTested: Audited manifest type coverage, verified synthetic_v2 hard-case evaluate results, and updated handoff/changelog docs with the gap analysis\nNot-tested: Post-optimization hard-case improvements on real open-data derived hard cases
cnb.bofCdSsphPA authored -
…ate must reflect fresh evaluate evidence without staging temporary eval assets\nRejected: Wait for larger-scale or hard-case metrics | The first explicit evaluate closure is already a meaningful milestone and restart-safe handoff point\nConfidence: high\nScope-risk: narrow\nDirective: Reuse /tmp/fma_realpath_small_rerun_index2 and /tmp/fma_realpath_small_rerun_eval as the next validation baseline before scaling up\nTested: Verified eval_top50.json at num_queries 35 with top1 0.8571 and topk 1.0, confirmed query-count explanation, and updated handoff/changelog docs\nNot-tested: Larger query caps, hard-case buckets, and full-scale FMA evaluate runs
cnb.bofCdSsphPA authored -
…livery docs must reflect fresh post-fix completion evidence and exclude data/index artifacts\nRejected: Delay until evaluate evidence exists | Completed reference index is already a distinct stage milestone the user asked us to checkpoint\nConfidence: high\nScope-risk: narrow\nDirective: Use /tmp/fma_realpath_small_rerun_index2 as the primary handoff artifact and validate evaluate or identify next before expanding sample size\nTested: Verified reference_progress.json complete at 200/200, reference_embs.npy and reference_ids.npy present, embedding_shape [2068, 192], and handoff/changelog docs updated\nNot-tested: Automatic evaluate chaining and retrieval quality on the completed 200-ref index
cnb.bofCdSsphPA authored -
… must reflect fresh observable evidence before restart and avoid staging data artifacts\nRejected: Wait for full reference completion | User asked for immediate delivery package and current checkpoint is already a meaningful stage transition\nConfidence: high\nScope-risk: narrow\nDirective: Treat session 19709 and /tmp/fma_realpath_small_rerun_index2 as the primary continuation path until final reference artifacts or a new traceback appear\nTested: Verified chromaprint 200/200 complete, reference_progress.json 25/200 checkpoint, partial reference numpy artifacts, and updated handoff/changelog files\nNot-tested: Full reference completion and downstream evaluate stage on the active rerun
cnb.bofCdSsphPA authored -
Constraint: Real-path investigation exposed decode failures from mpg123/librosa on some MP3s during long index runs Rejected: Abort the entire job on first decode error | it turns one bad asset into total index failure Confidence: high Scope-risk: narrow Directive: Keep per-file skip logging and skipped_refs accounting while continuing the real-path root-cause run Tested: Verified /tmp/chroma_skip_repro with 1 good MP3 + 1 bad MP3 completes RC=0, logs skip decode failure, writes reference outputs, and records skipped_refs=1 Not-tested: Full real-path FMA rerun after tolerance change is still pending
cnb.bofCdSsphPA authored -
Constraint: The live build-index investigation was blocked by stdout/stderr buffering that left log files at 0 bytes during long runs Rejected: Keep diagnosing from progress files alone | they do not preserve traceback or stage-transition context Confidence: high Scope-risk: narrow Directive: Preserve flush-on-progress behavior while chasing the remaining real-path build-index root cause Tested: Verified tiny repro /tmp/chroma_repro_tiny12 writes live logs and traceback with RC=1 after flush=True change Not-tested: No final fix for the real-path build-index exit yet
cnb.bofCdSsphPA authored -
Constraint: Both observable and legacy build-index jobs exited without producing reference_* or evaluate artifacts Rejected: Keep treating the run as slow linear progress | no longer matches the fresh ps/pgrep evidence Confidence: high Scope-risk: narrow Directive: Start the next cycle with build-index exit-path diagnosis before launching more long runs Tested: Verified ps/pgrep show no active build/evaluate process; verified observable directory still only has chromaprint progress/cache files; reviewed updated handoff docs Not-tested: No root-cause reproduction or fix yet
cnb.bofCdSsphPA authored -
Constraint: Long-running CPU-only chromaprint indexing has not reached evaluate yet Rejected: Keep appending linear refs_done updates | produces noise without a stage transition Confidence: high Scope-risk: narrow Directive: Do not create the next handoff commit until chromaprint completes, reference_* appears, evaluate starts, or the process fails Tested: Verified /tmp/chroma_index_observable_smoke progress snapshot; reviewed updated handoff/changelog files Not-tested: No new model/evaluation result because build-index has not reached the next stage
cnb.bofCdSsphPA authored -
Constraint: the live 8000-reference FMA run is already in flight, so observability had to be added as forward-safe progress and partial-cache outputs for future runs instead of altering the active process Rejected: keep waiting on blind build-index runs | hides whether chromaprint is advancing and blocks operational debugging Confidence: high Scope-risk: narrow Directive: Prefer progress JSON plus partial cache evidence for future large-index investigations before assuming a stall Tested: py_compile on chromaprint_matcher.py and run_demo.py, verified chromaprint_progress.json and chromaprint.pkl appear in /tmp/chroma_index_observable_smoke at refs_done=50 Not-tested: end-to-end completion of the new observable build-index flow has not finished yet
cnb.bofCdSsphPA authored -
Constraint: the live FMA smoke is still running, so the optimization had to preserve existing hash semantics rather than adopt the faster non-equivalent peak picker Rejected: maximum_filter-based peak picking | changed peak/hash outputs despite much larger speedup Confidence: high Scope-risk: narrow Directive: Keep future chromaprint optimizations hash-equivalent unless evaluation baselines are intentionally regenerated Tested: compared old vs new peaks and hashes on fma_00000.mp3, measured 2.02x speedup, py_compile passed, rechecked live FMA smoke still in build-index Not-tested: full build-index completion on the live 8000-reference FMA run has not finished yet
cnb.bofCdSsphPA authored -
Constraint: CPU-only real FMA smoke is still running, so delivery must emphasize resumable evidence instead of final metrics Rejected: wait for evaluate completion | would block handoff and delay resumable delivery with no new guaranteed result Confidence: high Scope-risk: narrow Directive: Keep future commits limited to explicit doc files unless index/evaluate artifacts are intentionally being reported Tested: verified running PIDs, checked best_model.pt and song_to_idx.json existence, revalidated manifests with validate-splits Not-tested: final index artifact emission and evaluate metrics are not available yet
cnb.bofCdSsphPA authored -
Capture the newest verified downstream state so restart docs show that the real FMA smoke still remains in build-index at 13:34 UTC with no evaluate stage or emitted index artifacts yet. Constraint: Downstream completion evidence is still unavailable because build-index has not produced artifacts or switched to evaluate Rejected: Leave the 13:34 observation only in chat | would break restart continuity and phase-by-phase commit discipline Confidence: high Scope-risk: narrow Directive: Next capture either the first index artifact file or the transition into evaluate before changing the downstream status summary again Tested: process scan showing build-index and no evaluate; presence of /tmp/fma_real_smoke_stopcheck/fma_index_smoke directory; validate-splits on /tmp/fma_real_smoke_stopcheck/fma/manifests Not-tested: Completed build-index output, evaluate, final metrics/report generation
cnb.bofCdSsphPA authored -
Capture the newest verified downstream state so restart docs show that the real FMA smoke still remains in build-index at 13:28 UTC with no evaluate stage or emitted index artifacts yet. Constraint: Downstream completion evidence is still unavailable because build-index has not produced artifacts or switched to evaluate Rejected: Leave the 13:28 observation only in chat | would break restart continuity and phase-by-phase commit discipline Confidence: high Scope-risk: narrow Directive: Next capture either the first index artifact file or the transition into evaluate before changing the downstream status summary again Tested: process scan showing build-index and no evaluate; presence of /tmp/fma_real_smoke_stopcheck/fma_index_smoke directory; validate-splits on /tmp/fma_real_smoke_stopcheck/fma/manifests Not-tested: Completed build-index output, evaluate, final metrics/report generation
cnb.bofCdSsphPA authored
-
