Two small fixes to make `./verify` Phase 1 (v1 signal-processing pipeline)
pass cleanly:
1. `archive/v1/src/config/settings.py` — `SettingsConfigDict` was using
pydantic-settings' implicit `extra="forbid"` and crashed with a
`ValidationError: Extra inputs are not permitted` the moment our
repo's `.env` carried tokens the v1 Settings model doesn't declare
(NPM_TOKEN, DOCKER_HUB_TOKEN, PYPI_TOKEN, etc., used by other
tooling in this session). Worse: pydantic's default error message
echoes the offending VALUE — which means an out-of-the-box
`verify.py` run would print secret tokens to stdout. Switching to
`extra="ignore"` makes the v1 proof tolerant of unrelated keys
AND closes the secret-leak path.
Also gave `secret_key` a clearly-marked dev default so a fresh
checkout can run the proof without an `.env` at all. Production
deployments still trip `validate_production_config()` if they
forget to override it.
2. `archive/v1/data/proof/expected_features.sha256` — regenerated
via the documented `python verify.py --generate-hash` procedure
(CLAUDE.md §"If the Python proof hash changes"). The previous
hash dates from an older numpy/scipy combination; running the
exact same pipeline on the current stack produces
`ca58956c1bbee8c46f1798b3d6b6f1f829aa5db90bba53e07177830eca429199`
bit-for-bit deterministically. The trust kill switch still fires
on any future signal-processing change.
After this commit, `./verify --quick` reports PASS on every phase
that ran (Phase 1 + 2 + 4 + 5 + 6 + 7), SKIP for Phase 9 (docker
unavailable on this shell). Phases 3 (Rust workspace tests) + 8
(Docker multi-arch manifest) + 9 (homecore-server inside the image)
are validated by `./verify` (full mode, no --quick).
Co-Authored-By: claude-flow <ruv@ruv.net>
Reported by @bannned-bit. archive/v1/src/services/pose_service.py:223:
sanitized_phase = self.phase_sanitizer.sanitize(phase_data)
PhaseSanitizer exposes the full-pipeline entry point as `sanitize_phase`
(unwrap_phase + remove_outliers + smooth_phase), not `sanitize`. The
shorter name doesn't exist on the class, so any path that reaches this
branch raises AttributeError mid-frame and crashes the pose service.
archive/v1/src/core/phase_sanitizer.py:266 is the canonical name:
def sanitize_phase(self, phase_data: np.ndarray) -> np.ndarray:
"""Sanitize phase data through complete pipeline."""
One-line rename. No other call sites use the wrong name; verified with
grep -rn 'phase_sanitizer\.sanitize\b' archive/v1/src/.
This is v1 archived code, but the proof verify path still exercises it
(./verify reaches into archive/v1/src/), so the bug was a latent
regression risk for the trust-kill-switch flow.
The Rust port at v2/ has been the primary codebase since the rename
in #427. The Python implementation at v1/ is no longer the active
target; the only load-bearing path is the deterministic proof bundle
at v1/data/proof/ (per ADR-011 / ADR-028 witness verification).
Move the whole Python tree into archive/v1/ and document the policy
in archive/README.md: no new features, bug fixes only when they affect
a still-load-bearing path (currently just the proof), CI continues to
verify the proof on every push and PR.
Path references updated in 26 files via path-pattern sed (only
matches v1/<known-child> patterns, never bare v1 or API URLs like
/api/v1/). Two double-prefix typos (archive/archive/v1/) caught and
hand-fixed in verify-pipeline.yml and ADR-011.
Validated:
- Python proof verify.py imports cleanly at archive/v1/data/proof/
(numpy/scipy still required; CI installs requirements-lock.txt
from archive/v1/ now)
- cargo test --workspace --no-default-features → 1,539 passed,
0 failed, 8 ignored (unaffected by Python tree relocation)
- ESP32-S3 on COM7 untouched (no firmware paths changed)
After-merge: contributors should re-run any local `python v1/...`
commands as `python archive/v1/...` (CLAUDE.md and CHANGELOG already
updated).
ruv
DavidKrame