HunterX v7 — Sprint 034.1

FINAL RELEASE GATE — Phase 1: Repository Integrity & V6/V7 Contamination Audit

Date: 2026-08-10 Phase: 034.1 (integrity audit only — no feature development) Author: Principal Release Engineer (Phase 034.1) Scope: Repository inventory, V6 contamination audit, runtime path, configuration, packaging, CI/CD, documentation, database artifacts, classification, safe repairs, validation.

1. Executive Summary

HunterX v7 (src/-layout, pyproject.toml version = "7.0.0") is implemented, runs, and passes its full test suite, but the repository is still contaminated by V6-era implementation, packaging, documentation, and runtime paths, and the entire V7 delivery is currently untracked in git.

Key conclusions:

1. V7 is the real runtime — verified end-to-end: hunterx version → HunterX v7.0.0; hunterx platform → full composition; API factory hunterx.api.app:create_app (FastAPI, /health); mission creation via hunterx mission create / hunterx hunt.
2. V6 contamination vectors exist and were repaired where unambiguous: the root hunterx.py shim dispatched to the V6 CLI; the Dockerfile baked in VERSION=6.0.0, a hunterx doctor health check (a command V7 does not have), and V6 hunterx.yaml/payloads/ copies; install.sh downloaded hunterx-6.0.0.tar.gz from PyPI and verified with V6-only commands; 12 SQLite database artifacts were tracked in git.
3. One P0 remains: the entire V7 tree (src/, tests/{unit,…}, eng/, alembic/, config/, capabilities/, V7 workflows, requirements.lock, V7 docs) is uncommitted. A clean clone of main today contains only the retired V6 flat package. The release gate cannot be closed until the V7 tree is staged/committed (034.2 decision — not performed here per instructions).
4. Known, classified, carry-over issues are listed in §10 (P0–P3) for 034.2.

Phase gate: PASS (with one P0 carry-over that blocks the release gate until the V7 tree is committed).

2. Repository Inventory

2.1 Active (V7) paths

2.2 Obsolete / V6 paths

2.3 Orphans, duplicates, dead paths

• Orphan modules: top-level core/ (empty __init__), api/, plugins/ (duplicates of hunterx/*). Not packaged, not referenced by V7.
• Duplicate config: capability manifests live in two locations — capabilities/*.json (11) and config/capabilities/*.json (7). Neither is referenced by code.
• Duplicate DB artifacts: data/*.db are byte-identical copies of hunterx/assets/data/*.db.
• Dead paths: hunterx/core/reasoning_engine_old.py (explicitly “old”), scripts/__init__.py (empty package), alembic/versions/__pycache__/*.pyc referencing migration files no longer in source (tmp_vuln_migration, dryrun_check, schemacheck, three old api_intelligence_tables variants).
• Duplicate entry points: python hunterx.py, python -m hunterx, hunterx console script, hunterx.cli:main vs V6 hunterx/cli.py:main.

3. V6 Contamination Findings

3.1 In src/ (V7)

None. Grep for from hunterx.core|modules|utils|engines inside src/ returns zero matches. The V7 package is internally clean.

3.2 Runtime entry points (VERIFIED)

• python -c "import hunterx" from the repo root resolves to the V6 flat package (hunterx/__init__.py, __version__ = "6.0.0") because the repo root (cwd) sits ahead of the src editable path on sys.path.
• python -m hunterx from the repo root runs the V6 CLI (“AI-Assisted Vulnerability Hunter | v6.0.0”, commands: scan/module/doctor/…).
• python hunterx.py previously ran the V6 CLI — repaired this phase to insert src/ first (now prints HunterX v7.0.0).
• hunterx console script (editable install) runs V7 (hunterx version → v7.0.0, hunterx platform → composition JSON). ✔ V7 is the installed runtime.
• Stale root hunterx.egg-info/ (PKG-INFO 6.0.0) confused importlib.metadata (reported v6.0.0) — deleted this phase; metadata now correctly reports 7.0.0.

3.3 Environment prefixes

• V7: HUNTERX_* (declared in src/hunterx/config/loader.py; secrets layer uses HUNTERX_SECRET_*; sandbox injects HUNTERX_EXECUTION_ID etc.).
• V6: HX_* (HX_TIMEOUT, HX_THREADS, HX_MAX_RPS, HX_AI_*, …) — only in V6 code (hunterx/config/config.py) and the excluded root tests/test_config.py.
• Docker/Compose still referenced HX_* — Dockerfile repaired; compose flagged.

3.4 Configuration schema

Two distinct schemas exist: root hunterx.yaml (V6: profile/stealth/auth/ai/oob/ presets) and src/hunterx/config/hunterx.yaml (V7: app_name/environment/database/ cache/queue/security/api). The V7 loader reads a cwd hunterx.yaml as a profile; the V6 file is merged and its unknown keys are ignored by pydantic (inert, but a latent trap).

3.5 CLI command surface

V6 commands (scan, module, doctor, payload, agents, skills, workflow, reasoning, api, update, ai) do not exist in V7. V7 exposes version/help/config/platform, mission *, hunt *, finding *, report *, target *, campaign *, tools *. Docker healthcheck hunterx doctor and install.sh smoke/help text used V6 commands — repaired.

3.6 CI / Docker references

No workflow hardcodes 6.0.0. The Dockerfile’s ARG VERSION=6.0.0 default, COPY hunterx.yaml/COPY payloads/ and hunterx doctor healthcheck were V6 — repaired. docker-compose.yml remains fully V6 (see §10 P1-02).

4. Active Runtime Path (verified end-to-end)

1. Install: pip install . → pyproject.toml → [tool.setuptools.packages.find] where=["src"] → only src/hunterx is packaged → console scripts hunterx and hunterx-arch.
2. CLI startup: hunterx → hunterx.cli:main (src/hunterx/cli/__init__.py) → CliApplication + register_default_commands → build_platform().
3. API startup: hunterx.api.app:create_app (FastAPI, version="7.0.0", /health + mission/finding/report/target-memory/tools/orchestration routers).
4. Platform construction: build_platform() assembles the Platform composition root — 30+ application services, four facades (TIP, Tool Integration SDK, Tool Integration Factory, Mission Planning), CoreEngine, observability stack, in-memory default adapters, optional SQL repositories.
5. Mission creation/execution: hunterx mission create → MissionOrchestrationService.create_mission → MissionOrchestrator (hunterx.domain.mission_orchestration.orchestrator); hunterx hunt creates
   • starts a full-spectrum mission via MissionDashboardService.

V7 is the actual runtime. The only contamination paths to V6 were the repo-root hunterx.py/python -m hunterx/import hunterx shadowing (root on sys.path) and V6 packaging/Docker/install artifacts — all addressed in §9 except the documented repo-root shadowing caveat (P1-01) and compose (P1-02).

5. Configuration Audit

Precedence (as documented in loader.py): bundled defaults → user profile (HUNTERX_CONFIG or cwd hunterx.yaml) → environment (HUNTERX_*).

Finding (P1-06): the environment step is not implemented. Settings is a plain pydantic BaseModel with no model_config/SettingsConfigDict; load_default_settings() merges YAML only. Verified: HUNTERX_ENVIRONMENT=dev, HUNTERX_LOG_LEVEL=DEBUG have no effect. The docstrings in settings.py/loader.py promise auto env mapping that does not exist. This also means the Dockerfile’s HUNTERX_LOG_LEVEL (renamed this phase) is inert until 034.2 implements env support.

6. Packaging Audit

• pyproject.toml — V7 correct: version=7.0.0, requires-python>=3.11, [project.scripts] hunterx = hunterx.cli:main, hunterx-arch = hunterx.architecture.cli:main, packages.find where=["src"], package-data ships py.typed, config/*.yaml, reporting/templates/*. Comments explicitly document the V6 flat package is not packaged. ✔
• Entry points (src/hunterx.egg-info/entry_points.txt) match pyproject. ✔
• requirements.lock — V7 locked set (mirrors pyproject deps); consumed by CI caching, pip-audit, SBOM, license checks. ✔
• requirements.txt — V6 dependency set (requests, beautifulsoup4, lxml, websocket-client — not in pyproject). STALE/conflicting (P2-05); still watched by dependency-review.yml and managed by Renovate (pip_requirements).
• Dockerfile — Repaired this phase to V7 (VERSION default 7.0.0, healthcheck hunterx version, no V6 hunterx.yaml/payloads/ copies, HUNTERX_LOG_LEVEL, EXPOSE 8080). Multi-stage src-layout build verified sound.
• install.sh — Repaired this phase (7.0.0 sdist URL, banner, V7 smoke hunterx version, V7 help text). Remaining caveat: the wrapper fallback python -m hunterx needs a V7 __main__.py (P2-09); the PyPI path assumes hunterx 7.0.0 exists on PyPI.
• .dockerignore — Repaired this phase to exclude the V6 tree, DBs, caches, artifacts and non-runtime trees from the build context.
• docker-compose.yml — fully V6 (see P1-02).

7. CI/CD Reference Audit

Reviewed 19 workflows (release, test, ci, build, unit-tests, integration-tests, security-tests, performance-tests, architecture-tests, compliance, cosign-sign, dependency-review, docs-validation, packaging-validation, readiness, sbom, docker-publish, pypi-publish) + .pre-commit-config.yaml, renovate.json, dependabot.yml, CODEOWNERS.

• No workflow hardcodes 6.0.0/v6.0.0. All workflows target the V7 paths: tests/{unit,component,architecture,integration,golden,security}, src/hunterx, eng/*, requirements.lock, hunterx-arch/python -m hunterx.architecture.
• dependency-review.yml still watches root requirements.txt + **/requirements*.txt (V6 file) alongside requirements.lock (P2-05).
• Docker workflows build via the (now V7) Dockerfile; packaging-validation.yml also smoke-tests hunterx --help / hunterx-arch --help (V7 entry points). ✔
• .pre-commit-config.yaml local hook uses hunterx-arch with language: system — silently no-ops if the package isn’t installed in the local env (P3-01).
• Live gate results (run locally, ruff 0.15.22): mypy PASS, docs PASS (7/7 after repair), hygiene PASS, compliance PASS, architecture (hunterx-arch lint) PASS — but ruff FAIL (77 pre-existing violations in src/hunterx), so the mandatory ruff gate (test.yml/ci.yml) is currently red. Pre-existing tech debt, not V6-related (P2-08).

No CI changes were made this phase (per instructions).

8. Documentation Consistency Audit

Classified by category (full per-file audit was performed; highlights below).

• ACTIVE V7: docs/architecture/*, all docs/v7-*.md (design corpus + sprint 033 report), THIRD_PARTY_NOTICES, docs/_redirects.
• HISTORICAL V6: RELEASE_NOTES_v6.0.0.md, docs/archive/* audit reports, docs/features/*, docs/_posts/* (dated blog posts, unlabeled), docs/_tutorials/*.
• STALE (V6 content on live pages): README.md, docs/index.md, docs/features.md, docs/modules.md, docs/api.md, docs/configuration.md, docs/cli.md, docs/authentication.md, docs/Docker_Guide.md, docs/profiles.md, docs/faq.md, docs/systemd.md, docs/AI_PROVIDER_GUIDE.md, docs/Reference_Guide.md, docs/PLUGIN_DEVELOPMENT.md, docs/SKILL_SDK.md, docs/AGENTS.md, docs/ARCHITECTURE.md, docs/REASONING_ENGINE.md, docs/SECURITY_SKILLS_FRAMEWORK.md, docs/quickstart.md, docs/documentation.md, docs/installation/index.md, docs/releases/index.md, docs/tutorials/index.md, docs/use-cases/*, docs/examples/*, docs/comparisons/*, root CHANGELOG.md, ROADMAP.md, SECURITY.md, CONTRIBUTING.md, RELEASE_CHECKLIST.md, SUPPORTED_PLATFORMS.md, CITATION.cff.
• CONTRADICTORY: README config/layout sections vs V7; docs/ARCHITECTURE.md vs docs/architecture/README.md (same permalink /architecture/); docs/cli.md vs docs/cli/index.md (same permalink /cli/); CHANGELOG.md/ROADMAP.md/ CITATION.cff/SECURITY.md version claims (6.0.0 vs 7.0.0).
• BROKEN: docs/_config.yml fails YAML parsing (mixed defaults: indentation); docs/_layouts/default.html has no `<h1 id="hunterx-v7--sprint-0346--final-engineering-certification">HunterX v7 — Sprint 034.6 — Final Engineering Certification</h1>

Phase: Final engineering certification before Sprint 035 Status: BLOCKED — 2× P0 and 5× P1 release blockers remain Date: 2026-08-11 Platform verified: Windows 11 / Python 3.14.6 (installed hunterx 7.0.0, editable install of the v7 src/ layout) Scope: The complete integrated v7 platform (src/hunterx), mission lifecycle, toolchain, intelligence pipeline, persistence, evidence, PoC engine, recovery, observability, API/CLI, packaging, CI/CD and documentation.

This is the final engineering certification that Sprint 034.5 explicitly deferred to. It audits the complete system as one integrated platform and re-checks the release gates declared PASS in earlier 034.x reports. Known defects are not hidden: this report surfaces unresolved blockers that earlier reports carried as open or declared resolved prematurely.

1. System Certification

The SYSTEM FLOW

TARGET → SCOPE → RECON → ENUMERATION → DISCOVERY → INTELLIGENCE → PLANNING
→ TOOL SELECTION → EXECUTION → PARSING → NORMALIZATION → CORRELATION
→ HYPOTHESIS → TESTING → VERIFICATION → PROOF → PoC → REPLAY → IMPACT
→ FINDING → PERSISTENCE → REPORT

is implemented across the v7 stack and was verified end-to-end:

No major subsystem is an isolated island: mission orchestration consumes observations, findings and evidence from the toolchain/intelligence/proof subsystems, and the reporting subsystem consumes persisted finding records. One integration seam was found at report time (mission-context findings are not auto-registered into the reporting finding store) — the intended flow requires creating the finding via VulnerabilityFindingService (verified working).

Verdict: the architecture is integrated and the pipeline works.

2. End-to-End Results

Representative missions verified (deterministic, no real tool binaries required — the certified design treats tool output as data; adapters are fixture-validated and tools-marked tests are excluded by default, consistent with 034.5 §1):

Live integration run (this certification, SQLite temp DB):

create ✓  start ✓  ingest ✓  hypothesis ✓  verify ✓  finding ✓  impact ✓
finalize ✓  finding_persisted ✓  poc_generated ✓  report_generate ✓
report_export ✓  observation_records ✓ (2 persisted)

Mission state, persistence, events, evidence and reporting all function in the integrated flow.

3. Failure / Recovery

Failure-injection and recovery verification (all suites pass):

Known limitation (documented, not hidden): DB retry/pool-pre-ping/failover does not exist at runtime (create_engine_from_settings has no retry hook) and in-memory fallback is config-time only — a deployment responsibility (carried P3 from 034.3 §18).

4. AI Certification

• No silent AI→evidence path exists. NullAIClient.complete() raises OperationError; embed() is deterministic SHA-256 (verified live). The only real-provider consumer is the executive summarizer (a string, not evidence).
• All reasoning is deterministic rule-based in the certified path (OBSERVE→HYPOTHESIZE→PROBE→VERIFY); AI proposals are advisory (ai_proposed flag) and pass the same policy gates.
• Validation gates verified: requires_validation=True on all scanner adapters; candidate confidence capped at 0.5; VerdictEngine (CONFIRMED/FALSE_POSITIVE/INCONCLUSIVE); ProofValidator strict gate order (contradiction never averaged, target-state change ⇒ INCONCLUSIVE); PoCReplayVerifier (an HTTP 200 alone is never a successful replay); ClaimVerifier blocks unverified high-impact report claims.
• Provenance: hypotheses, decisions, observations, evidence and findings carry source/tool/version/correlation/mission refs; AI-inferred sources are ranked lowest (AI_INFERENCE weight 0.1).
• Novel behavior: UnknownBehaviorClassifier (KNOWN_CLASS / KNOWN_VARIANT / NOVEL_BEHAVIOR / APPLICATION_SPECIFIC / UNRESOLVED) — never labels zero-day without reproducible, security-relevant, controlled proof.
• Tests: 381 AI/validation/proof/reasoning tests pass (including golden + security matrices).

Verdict: AI certification PASSES.

5. Toolchain Certification

Carried forward from 034.5 (re-verified this sprint):

• 106 registered tools / 79 execution adapters, complete machine-readable contracts (0 missing dimensions, tests/tools/test_contracts.py).
• All subprocess adapters run through the single guarded BinaryRunner seam (structural argv, no shell=True, 32 MiB cap, wall-clock timeout, injection guards).
• Parsers/normalizers fixture-validated for every family; golden fixtures under tests/golden/tools/<family>/.
• ChainExecutor (topological order, provenance, fallback, partial results) certified end-to-end for recon/API/secrets/web/cloud chains.
• tests/tools suite: 80 passed when run explicitly.

6. Persistence Certification

• Migrations: 21 linear Alembic revisions, baseline 4302b30cb7c7; verified upgrade head → 408 tables (file-backed SQLite), alembic check drift-free, downgrade clean (tests/integration/tidb/test_sql_migrations.py).
• TIDB stores: 401 tidb_* tables across missions, targets, findings, evidence, proof, PoC, reports, events, audit.
• Transactions: per-repository-call commits; save_many atomic (all-or-nothing). Verified by test_transaction_integrity.py.
• Events/audit: InMemoryEventStore replay + dead-letter; VersioningListener writes audit/timeline rows in SQL mode.
• Findings/evidence/PoC/reports persist across the service layer (verified live: finding_persisted, observation_records).

Two persistence defects are NOT hidden:

1. Operational mission state is not resumable across process restarts — the MissionOrchestrator._missions dict is in-memory only and start() has no restore path; TIDB persistence records audit/read-model data but cannot resume the orchestrator. See P1-03.
2. Timeline read-model (tidb_mission_timelines) is never written by the mission service (GET /missions/{id}/timeline returns empty in persistent deployments). Verified live. See P2-08.

7. Security Certification

• Security test suites pass: tests/security 396, tests/security/tools, tests/security/api (401/403/readonly auth matrix), tests/security/test_proof_strategy_security.
• pip-audit: no known vulnerabilities in requirements.lock.
• Auth: opt-in X-API-Key middleware verified (disabled by default on loopback — documented deployment guidance).
• Secret handling: masking regression pinned (mask_value reveal_tail=0 bug fixed in 034.5); secret non-persistence tests pass.
• BLOCKER — bandit gate fails: 2× MEDIUM B314 — untrusted XML parsed with stdlib xml.etree.ElementTree.fromstring:
  • src/hunterx/domain/api/parsers/soap.py:73 — attacker-controlled WSDL
  • src/hunterx/tools/livehost/nmap.py:138 — scanner XML output These are XXE / entity-expansion (billion-laughs) exposures for a tool that parses target-controlled XML. Fix: defusedxml (or hardened parser config). See P1-02. (46 LOW findings also present.)

8. Performance

Measured from the benchmark suite (tests/performance, 122 tests) and a live N+1-query audit:

• Throughput: typical cores are µs-scale — e.g. test_impact_benchmark ~0.12 ms/op, correlation ~24 µs/op at 10k observations, selection throughput

  100k ops/s, DNS resolution >2.5M ops/s, confidence >8M ops/s. No CPU bottleneck detected in the pure-domain hot paths.

• Large sets: test_100k_observations_bounded (~4.1s), 1M observation metadata diff (~1.7s), bulk insert 10k rows (21s setup) — bounded, no memory blow-up.
• N+1 audit: TIDB list/list_by/get/count/stream are single-query (cursor-counted, tests/performance/persistence/test_n_plus_one.py).
• Known debt (P2, documented): legacy Sql*Repository.list() is classic 1+N; save_many issues a per-row existence SELECT; mission service loops save() per record; MissionOrchestrationQueryService._records lists up to 10 000 rows then filters in Python.
• BLOCKER — performance gate fails by design: the gate runs the benchmark suite then flags any test >20s as “slow”, so it flags its own benchmark functions (test_hypothesis_creation_benchmark 60.6s, test_proof_creation_benchmark 37.3s) plus the 21s bulk-insert setup. The gate can never pass as configured. See P1/P2-01.

Verdict: performance is acceptable in practice; the performance gate is broken.

9. Observability

• Structured logging: infrastructure/logging JsonFormatter + LoggingManager.
• Correlation IDs / mission IDs / execution IDs: pervasive across TIDB models (correlation_id, mission_id, execution_id indexed columns), the event store, and log field binding.
• Events: typed event catalog (domain/events/catalog.py, ~100+ events), in-memory bus + append-only store + replay + dead-letter queue.
• Metrics / telemetry: InMemoryMetrics, PrometheusTelemetryProvider, MemoryTelemetryProvider, InMemoryTracer, health probes + health registry.
• Audit trail: VersioningListener (audit/change/version/timeline rows) in SQL mode.
• Error tracing: mission reasoning trace, decision records, tool execution records with failure kind + retry count.

Verdict: observability is implemented and verified (tests in the default suite).

10. API / CLI

• API (FastAPI, create_app): route groups /missions, /missions/adaptive, /missions dashboard, /findings, /reports, /targets+/campaigns, /tools, /health. Live verified in a clean [api,db] venv: GET /health → 200 {"status":"ok"}; POST /missions → 200 with mission_id.
• API tests pass: 43 integration/component/security API tests (incl. authorization matrix and mission lifecycle).
• CLI (hunterx, hunterx-arch): version, --help, config, platform, mission, hunt, finding, report, target, campaign, tools, tools chain/chain-execute, hunterx-arch lint. Verified in a clean venv.
• Auth: opt-in API-key middleware with admin/readonly roles; default off.
• BLOCKER — CLI mission workflow cannot chain invocations (mission create then mission start <id> fails with AdaptiveMissionNotFoundError because orchestrator state is in-memory). See P1-03. Also, HUNTERX_* env vars are never read. See P1-04.

11. Packaging / Clean Installation

• python -m eng packaging: PASS — wheel + sdist built, twine check clean (dist/hunterx-7.0.0-py3-none-any.whl, hunterx-7.0.0.tar.gz).
• Clean-environment install test (fresh venvs, wheel):
  • pip install hunterx (base, no extras): CLI CRASHES — ModuleNotFoundError: No module named 'sqlalchemy' at hunterx.cli import (through infrastructure.db.sql.repositories). P0-02.
  • pip install "hunterx[api,db]": works — hunterx version → “HunterX v7.0.0”, hunterx-arch 1.0.0, tools list, mission create, API server up.
• Docker: Dockerfile installs base "." (no extras) and healthchecks hunterx version → the image is unhealthy at build due to P0-02. docker-compose.yml is v6-era (build arg VERSION: 6.0.0, HX_* env, v6 command surface) and inconsistent with the v7 Dockerfile (P2).
• Entry points: hunterx = hunterx.cli:main, hunterx-arch = hunterx.architecture.cli:main both resolve to the v7 src/ package in a clean venv.

Verdict: packaging gate passes, but the default install is broken (P0-02).

12. CI/CD

18 workflows exist. Merge-gating: ci.yml (eng gates), unit-tests, integration-tests, performance-tests, security-tests, packaging-validation, architecture-tests, docs-validation, compliance, dependency-review, build, test. Release/other: release, sbom, cosign-sign, docker-publish, pypi-publish, readiness.

CI cannot validate V7. The main branch does not contain the v7 tree: git ls-files src → 0 files; eng/, tests/{unit,component,…}, alembic/, capabilities/, config/ and the 14 new workflows are all untracked. A clean checkout of main has only the v6 flat package (461 tracked files). Every CI workflow that references src, eng, or the v7 test suites would fail or error on a clean checkout. P0-01.

Mandatory gates as run against the working tree this sprint:

13. Documentation

• docs gate PASS (7/7: required files, required sections, engineering docs, internal links, fenced blocks, structure).
• Present: Development Bible (15 chapters), docs/architecture/, docs/cli/, docs/configuration/, docs/installation/, docs/features/, docs/use-cases/, docs/v7-*.md design/reference set (foundation, tidb, event-bus-observability, tool-integration-sdk, cicd-architecture, release-guide, security-pipeline, full-toolchain-intelligence, …), CHANGELOG.md, ROADMAP.md.
• Incoherences (not hidden): docs/api.md, docs/cli.md, docs/AGENTS.md document the v6 API/CLI surface (/agents, /scan, agents/workflows) which does not exist in v7; root hunterx.yaml is v6 config; RELEASE_CHECKLIST.md and install.sh reference v6-era commands; the env-var configuration contract (loader docstring, docs/configuration) is not implemented (P1-04). No dedicated deployment.md/migration.md exists (deployment guidance lives in docs/v7-release-guide.md + docker posts).
• Defect vs docs: docs claim HUNTERX_* env overrides; the loader never reads them.

Verdict: documentation is extensive and link-valid, but several critical runtime behaviors depend on undocumented or unimplemented assumptions (env config, base-install no-dependency mode).

14. Test Matrix

Empty or misleading suites:

• tests/framework/ contains helpers/fixtures only (correct, not a suite).
• tests/tools/ (80 tests, the Sprint 034.5 toolchain certification suite) is missing from [tool.pytest.ini_options] testpaths — python -m pytest and the CI pytest gate do not run it. Sprint 034.5 reported these as part of the default run; that is inaccurate. Misleading.
• tests/performance benchmark functions are themselves flagged as “slow” by the performance gate — the gate’s own output is misleading (P2-01).
• tests/test_reasoning.py at the repo root targets removed v6/v5 core.reasoning_engine_old — it cannot collect against v7; excluded from testpaths (stale, harmless).

15. Known Issues

16. P0 / P1 / P2 / P3 Summary

P0 — release blockers (2)

| # | Issue | Status | |—|—|—| | K01 | V7 tree untracked in git — CI/release cannot validate V7 | Open (carried from 034.1, declared resolved in 034.2–034.5 — incorrect) | | K02 | Base install/Docker image crash (unconditional sqlalchemy import) | Open (new) |

P1 — must fix (5)

| # | Issue | Status | |—|—|—| | K03 | ruff gate red (133) | Open (was P2-08 in 034.1, now worse; 034.5 “no P1” claim wrong) | | K04 | bandit B314 XXE ×2 — security gate red | Open (new) | | K05 | Mission orchestrator not resumable across restarts | Open (new) | | K06 | Env config (HUNTERX_*) unimplemented | Open (new) | | K07 | deadcode gate red | Open (new) |

P2 — acceptable technical debt (8)

K08 performance-gate self-fail, K09 N+1/commit loops, K10 tools suite not in testpaths, K11 timeline read-model unwritten, K12 concurrency upsert race, K13 v6-era compose/config/docs, K14 combined coverage 77%, K15 carried toolchain gaps (knowledge-only adapters, fan-out, redactor, binary pinning, rlimits).

P3 — post-release (2)

K16 stale v6 checklists/installer references; plus carried items (no DB runtime failover, CODEOWNERS gaps, __main__.py absence).

17. Release Readiness Score

Scoring model: 100 − 30×(#P0) − 15×(#P1) − 3×(#P2), floor 0.

• P0 = 2 → −60
• P1 = 5 → −75
• P2 = 8 → −24
• Release Readiness: 0/100 (blocked)
• Quality gates passing: 9/13 mandatory gates green on the working tree (pytest, mypy, coverage, architecture, docs, compliance, hygiene, dependencies, packaging) vs 4 red (ruff, deadcode, security, performance).
• Test suite health: 100% green (3474 passed; +80 tools suite green when run).

The product code and tests are healthy and green; the release engineering envelope is not (git state, default install, security/deadcode/ruff gates, mission resumability, env config).

18. Final Gate

19. Final Recommendation

STOP. Do NOT begin Sprint 035.

Sprint 034.6 — FINAL ENGINEERING CERTIFICATION: BLOCKED.

The engineering substance of HunterX v7 is strong and healthy — the integrated platform works end-to-end, all 3474 default tests pass, the toolchain and intelligence/proof pipelines are certified, and no functional regression was found. But the release is not ready because the engineering gate envelope fails:

1. P0 — the v7 delivery is not in git. A clean main checkout cannot build, test or release V7. This is Sprint 034.1’s own P0-01, never closed; later 034.x reports declared “no P0” inaccurately.
2. P0 — the default install is broken. pip install hunterx crashes at import without the optional db extra; the Docker image healthcheck fails.
3. P1 — three mandatory CI gates are red (ruff 133, bandit B314 XXE ×2, deadcode) and the performance gate can never pass as configured.
4. P1 — two runtime contract breaks: mission orchestration state is not resumable across process restarts, and HUNTERX_* environment configuration is documented but never implemented.

Exact remaining blockers (minimum to unblock):

• Commit the complete v7 tree (P0-01) and re-run CI on a clean checkout.
• Make db/sql imports lazy (or add db to core deps) so the base wheel and Docker image run (P0-02).
• Fix bandit B314 XXE with defusedxml (P1-04).
• Add a mission-restore path (hydrate OrchestratedMission from TIDB on start/resume) so CLI/API workflows survive restarts (P1-03).
• Implement env-var application in the config loader (P1-06).
• Clean the 133 ruff violations and 3 vulture findings (P1-03/P1-05), and fix the performance-gate slow-test logic (P2-01).

Sprint 035 may begin only after the P0 items are closed and the P1 items are resolved or explicitly re-scoped with acceptance criteria.

/<body>; nav.html links /Docker_Guide, /arch; robots.txt sitemap URL points to the deleted sitemap.xml; seo.html/tutorial.html/post.html Liquid syntax errors; every docs/cli/*.md has malformed single-line front matter; CITATION.cff has malformed YAML; docs/quickstart.md references non-existent hunterx setup/ hunterx feeds update; docs/contributing.md references non-existent tests/test_scanner.py`.

• Repaired this phase: the single link that failed the docs gate — docs/v7-api-intelligence-implementation-plan.md → ./v7-api-intelligence.md (file does not exist). Gate now 7/7. All other docs issues are classified for 034.2 (docs rewrites are content work, not integrity repairs).

9. Database / Artifact Audit

Conclusion: the repo previously shipped 12 binary SQLite DBs in git (now untracked, on disk only), and no credential material was found. DBs are not included in release artifacts (src-only packaging).

10. Issue Classification

P0 — RELEASE BLOCKER

| ID | Issue | State | |—|—|—| | P0-01 | Entire V7 delivery is untracked: src/, V7 tests/, eng/, alembic/, config/, capabilities/, V7 workflows, requirements.lock, V7 docs, THIRD_PARTY_NOTICES, CODEOWNERS, dependabot.yml. A clean main clone has only the V6 flat package. Release tagging/packaging cannot proceed from a committed state. | Open — needs staging/commit decision in 034.2 |

P1 — MUST FIX

| ID | Issue | State | |—|—|—| | P1-01 | Repo-root shadowing: import hunterx / python -m hunterx from the repo root resolve to the V6 flat package (root precedes src on sys.path). Only tests/conftest.py compensates. | Open — structural (needs V6 tree relocation or documented mitigation) | | P1-02 | docker-compose.yml is entirely V6: VERSION: 6.0.0, HX_* env, mounts V6 hunterx.yaml, command: ["api", "--port", "8443"] (no such V7 command). Broken for V7. | Open — needs V7 API startup design (034.2) | | P1-03 | Tracked SQLite DB artifacts (12 files) in git. | Repaired (git rm --cached + gitignore) | | P1-04 | hunterx.py shim dispatched to the V6 CLI. | Repaired (now delegates to src/) | | P1-05 | Dockerfile V6 markers (VERSION=6.0.0, hunterx doctor healthcheck, V6 hunterx.yaml/payloads/ copies, HX_LOG_LEVEL, EXPOSE 8443). | Repaired | | P1-06 | V7 env-var precedence declared but not implemented (HUNTERX_* has no effect; verified). | Open — implement in 034.2 | | P1-07 | install.sh V6 markers (sdist 6.0.0 URL, banner, V6-only smoke/help commands). | Repaired (version strings + V7 commands); wrapper python -m hunterx fallback still needs V7 __main__.py (see P2-09) |

P2 — TECHNICAL DEBT

| ID | Issue | |—|—| | P2-01 | Retired V6 flat package hunterx/ (245 files) retained at repo root; root-shadowing risk (see P1-01). Recommend relocation to a legacy/ tree. | | P2-02 | Orphan top-level api/, core/ (empty stub), plugins/ — dead V6 duplicates; not packaged, unreferenced. | | P2-03 | Root hunterx.yaml (V6 schema) tracked; V7 loader merges it inertly. Recommend removal or conversion. | | P2-04 | capabilities/ vs config/capabilities/ duplicate manifest locations; neither referenced by code. | | P2-05 | requirements.txt (V6 deps) conflicts with pyproject/lock; watched by dependency-review + Renovate. | | P2-06 | V6 payload corpus payloads/ (42 tracked files) unused by V7. | | P2-07 | V6 clutter at root: awesome-*.md, awesome-pentest, pentest.md, temp_cli_apps.md, summary.txt. | | P2-08 | Ruff gate red: 77 pre-existing violations in src/hunterx (D102×25, F401×16, I001×8, B023×7, etc.) under ruff 0.15.x. Mandatory CI ruff gate fails. Pre-existing, non-V6. | | P2-09 | No src/hunterx/__main__.py → python -m hunterx unsupported for installed V7 (console script is official entry). A __main__.py was drafted but reverted because hunterx-arch classified it as a legacy→cli boundary violation (ARCH-001); classify it as cli layer when added. | | P2-10 | V6 flat tests at tests/ root (~36 files) — excluded from suite (documented in pyproject). | | P2-11 | Doc-site broken: docs/_config.yml YAML parse failure; default.html missing `<h1 id="hunterx-v7--sprint-0346--final-engineering-certification">HunterX v7 — Sprint 034.6 — Final Engineering Certification</h1>

Phase: Final engineering certification before Sprint 035 Status: BLOCKED — 2× P0 and 5× P1 release blockers remain Date: 2026-08-11 Platform verified: Windows 11 / Python 3.14.6 (installed hunterx 7.0.0, editable install of the v7 src/ layout) Scope: The complete integrated v7 platform (src/hunterx), mission lifecycle, toolchain, intelligence pipeline, persistence, evidence, PoC engine, recovery, observability, API/CLI, packaging, CI/CD and documentation.

This is the final engineering certification that Sprint 034.5 explicitly deferred to. It audits the complete system as one integrated platform and re-checks the release gates declared PASS in earlier 034.x reports. Known defects are not hidden: this report surfaces unresolved blockers that earlier reports carried as open or declared resolved prematurely.

1. System Certification

The SYSTEM FLOW

TARGET → SCOPE → RECON → ENUMERATION → DISCOVERY → INTELLIGENCE → PLANNING
→ TOOL SELECTION → EXECUTION → PARSING → NORMALIZATION → CORRELATION
→ HYPOTHESIS → TESTING → VERIFICATION → PROOF → PoC → REPLAY → IMPACT
→ FINDING → PERSISTENCE → REPORT

is implemented across the v7 stack and was verified end-to-end:

No major subsystem is an isolated island: mission orchestration consumes observations, findings and evidence from the toolchain/intelligence/proof subsystems, and the reporting subsystem consumes persisted finding records. One integration seam was found at report time (mission-context findings are not auto-registered into the reporting finding store) — the intended flow requires creating the finding via VulnerabilityFindingService (verified working).

Verdict: the architecture is integrated and the pipeline works.

2. End-to-End Results

Representative missions verified (deterministic, no real tool binaries required — the certified design treats tool output as data; adapters are fixture-validated and tools-marked tests are excluded by default, consistent with 034.5 §1):

Live integration run (this certification, SQLite temp DB):

create ✓  start ✓  ingest ✓  hypothesis ✓  verify ✓  finding ✓  impact ✓
finalize ✓  finding_persisted ✓  poc_generated ✓  report_generate ✓
report_export ✓  observation_records ✓ (2 persisted)

Mission state, persistence, events, evidence and reporting all function in the integrated flow.

3. Failure / Recovery

Failure-injection and recovery verification (all suites pass):

Known limitation (documented, not hidden): DB retry/pool-pre-ping/failover does not exist at runtime (create_engine_from_settings has no retry hook) and in-memory fallback is config-time only — a deployment responsibility (carried P3 from 034.3 §18).

4. AI Certification

• No silent AI→evidence path exists. NullAIClient.complete() raises OperationError; embed() is deterministic SHA-256 (verified live). The only real-provider consumer is the executive summarizer (a string, not evidence).
• All reasoning is deterministic rule-based in the certified path (OBSERVE→HYPOTHESIZE→PROBE→VERIFY); AI proposals are advisory (ai_proposed flag) and pass the same policy gates.
• Validation gates verified: requires_validation=True on all scanner adapters; candidate confidence capped at 0.5; VerdictEngine (CONFIRMED/FALSE_POSITIVE/INCONCLUSIVE); ProofValidator strict gate order (contradiction never averaged, target-state change ⇒ INCONCLUSIVE); PoCReplayVerifier (an HTTP 200 alone is never a successful replay); ClaimVerifier blocks unverified high-impact report claims.
• Provenance: hypotheses, decisions, observations, evidence and findings carry source/tool/version/correlation/mission refs; AI-inferred sources are ranked lowest (AI_INFERENCE weight 0.1).
• Novel behavior: UnknownBehaviorClassifier (KNOWN_CLASS / KNOWN_VARIANT / NOVEL_BEHAVIOR / APPLICATION_SPECIFIC / UNRESOLVED) — never labels zero-day without reproducible, security-relevant, controlled proof.
• Tests: 381 AI/validation/proof/reasoning tests pass (including golden + security matrices).

Verdict: AI certification PASSES.

5. Toolchain Certification

Carried forward from 034.5 (re-verified this sprint):

• 106 registered tools / 79 execution adapters, complete machine-readable contracts (0 missing dimensions, tests/tools/test_contracts.py).
• All subprocess adapters run through the single guarded BinaryRunner seam (structural argv, no shell=True, 32 MiB cap, wall-clock timeout, injection guards).
• Parsers/normalizers fixture-validated for every family; golden fixtures under tests/golden/tools/<family>/.
• ChainExecutor (topological order, provenance, fallback, partial results) certified end-to-end for recon/API/secrets/web/cloud chains.
• tests/tools suite: 80 passed when run explicitly.

6. Persistence Certification

• Migrations: 21 linear Alembic revisions, baseline 4302b30cb7c7; verified upgrade head → 408 tables (file-backed SQLite), alembic check drift-free, downgrade clean (tests/integration/tidb/test_sql_migrations.py).
• TIDB stores: 401 tidb_* tables across missions, targets, findings, evidence, proof, PoC, reports, events, audit.
• Transactions: per-repository-call commits; save_many atomic (all-or-nothing). Verified by test_transaction_integrity.py.
• Events/audit: InMemoryEventStore replay + dead-letter; VersioningListener writes audit/timeline rows in SQL mode.
• Findings/evidence/PoC/reports persist across the service layer (verified live: finding_persisted, observation_records).

Two persistence defects are NOT hidden:

1. Operational mission state is not resumable across process restarts — the MissionOrchestrator._missions dict is in-memory only and start() has no restore path; TIDB persistence records audit/read-model data but cannot resume the orchestrator. See P1-03.
2. Timeline read-model (tidb_mission_timelines) is never written by the mission service (GET /missions/{id}/timeline returns empty in persistent deployments). Verified live. See P2-08.

7. Security Certification

• Security test suites pass: tests/security 396, tests/security/tools, tests/security/api (401/403/readonly auth matrix), tests/security/test_proof_strategy_security.
• pip-audit: no known vulnerabilities in requirements.lock.
• Auth: opt-in X-API-Key middleware verified (disabled by default on loopback — documented deployment guidance).
• Secret handling: masking regression pinned (mask_value reveal_tail=0 bug fixed in 034.5); secret non-persistence tests pass.
• BLOCKER — bandit gate fails: 2× MEDIUM B314 — untrusted XML parsed with stdlib xml.etree.ElementTree.fromstring:
  • src/hunterx/domain/api/parsers/soap.py:73 — attacker-controlled WSDL
  • src/hunterx/tools/livehost/nmap.py:138 — scanner XML output These are XXE / entity-expansion (billion-laughs) exposures for a tool that parses target-controlled XML. Fix: defusedxml (or hardened parser config). See P1-02. (46 LOW findings also present.)

8. Performance

Measured from the benchmark suite (tests/performance, 122 tests) and a live N+1-query audit:

• Throughput: typical cores are µs-scale — e.g. test_impact_benchmark ~0.12 ms/op, correlation ~24 µs/op at 10k observations, selection throughput

  100k ops/s, DNS resolution >2.5M ops/s, confidence >8M ops/s. No CPU bottleneck detected in the pure-domain hot paths.

• Large sets: test_100k_observations_bounded (~4.1s), 1M observation metadata diff (~1.7s), bulk insert 10k rows (21s setup) — bounded, no memory blow-up.
• N+1 audit: TIDB list/list_by/get/count/stream are single-query (cursor-counted, tests/performance/persistence/test_n_plus_one.py).
• Known debt (P2, documented): legacy Sql*Repository.list() is classic 1+N; save_many issues a per-row existence SELECT; mission service loops save() per record; MissionOrchestrationQueryService._records lists up to 10 000 rows then filters in Python.
• BLOCKER — performance gate fails by design: the gate runs the benchmark suite then flags any test >20s as “slow”, so it flags its own benchmark functions (test_hypothesis_creation_benchmark 60.6s, test_proof_creation_benchmark 37.3s) plus the 21s bulk-insert setup. The gate can never pass as configured. See P1/P2-01.

Verdict: performance is acceptable in practice; the performance gate is broken.

9. Observability

• Structured logging: infrastructure/logging JsonFormatter + LoggingManager.
• Correlation IDs / mission IDs / execution IDs: pervasive across TIDB models (correlation_id, mission_id, execution_id indexed columns), the event store, and log field binding.
• Events: typed event catalog (domain/events/catalog.py, ~100+ events), in-memory bus + append-only store + replay + dead-letter queue.
• Metrics / telemetry: InMemoryMetrics, PrometheusTelemetryProvider, MemoryTelemetryProvider, InMemoryTracer, health probes + health registry.
• Audit trail: VersioningListener (audit/change/version/timeline rows) in SQL mode.
• Error tracing: mission reasoning trace, decision records, tool execution records with failure kind + retry count.

Verdict: observability is implemented and verified (tests in the default suite).

10. API / CLI

• API (FastAPI, create_app): route groups /missions, /missions/adaptive, /missions dashboard, /findings, /reports, /targets+/campaigns, /tools, /health. Live verified in a clean [api,db] venv: GET /health → 200 {"status":"ok"}; POST /missions → 200 with mission_id.
• API tests pass: 43 integration/component/security API tests (incl. authorization matrix and mission lifecycle).
• CLI (hunterx, hunterx-arch): version, --help, config, platform, mission, hunt, finding, report, target, campaign, tools, tools chain/chain-execute, hunterx-arch lint. Verified in a clean venv.
• Auth: opt-in API-key middleware with admin/readonly roles; default off.
• BLOCKER — CLI mission workflow cannot chain invocations (mission create then mission start <id> fails with AdaptiveMissionNotFoundError because orchestrator state is in-memory). See P1-03. Also, HUNTERX_* env vars are never read. See P1-04.

11. Packaging / Clean Installation

• python -m eng packaging: PASS — wheel + sdist built, twine check clean (dist/hunterx-7.0.0-py3-none-any.whl, hunterx-7.0.0.tar.gz).
• Clean-environment install test (fresh venvs, wheel):
  • pip install hunterx (base, no extras): CLI CRASHES — ModuleNotFoundError: No module named 'sqlalchemy' at hunterx.cli import (through infrastructure.db.sql.repositories). P0-02.
  • pip install "hunterx[api,db]": works — hunterx version → “HunterX v7.0.0”, hunterx-arch 1.0.0, tools list, mission create, API server up.
• Docker: Dockerfile installs base "." (no extras) and healthchecks hunterx version → the image is unhealthy at build due to P0-02. docker-compose.yml is v6-era (build arg VERSION: 6.0.0, HX_* env, v6 command surface) and inconsistent with the v7 Dockerfile (P2).
• Entry points: hunterx = hunterx.cli:main, hunterx-arch = hunterx.architecture.cli:main both resolve to the v7 src/ package in a clean venv.

Verdict: packaging gate passes, but the default install is broken (P0-02).

12. CI/CD

18 workflows exist. Merge-gating: ci.yml (eng gates), unit-tests, integration-tests, performance-tests, security-tests, packaging-validation, architecture-tests, docs-validation, compliance, dependency-review, build, test. Release/other: release, sbom, cosign-sign, docker-publish, pypi-publish, readiness.

CI cannot validate V7. The main branch does not contain the v7 tree: git ls-files src → 0 files; eng/, tests/{unit,component,…}, alembic/, capabilities/, config/ and the 14 new workflows are all untracked. A clean checkout of main has only the v6 flat package (461 tracked files). Every CI workflow that references src, eng, or the v7 test suites would fail or error on a clean checkout. P0-01.

Mandatory gates as run against the working tree this sprint:

13. Documentation

• docs gate PASS (7/7: required files, required sections, engineering docs, internal links, fenced blocks, structure).
• Present: Development Bible (15 chapters), docs/architecture/, docs/cli/, docs/configuration/, docs/installation/, docs/features/, docs/use-cases/, docs/v7-*.md design/reference set (foundation, tidb, event-bus-observability, tool-integration-sdk, cicd-architecture, release-guide, security-pipeline, full-toolchain-intelligence, …), CHANGELOG.md, ROADMAP.md.
• Incoherences (not hidden): docs/api.md, docs/cli.md, docs/AGENTS.md document the v6 API/CLI surface (/agents, /scan, agents/workflows) which does not exist in v7; root hunterx.yaml is v6 config; RELEASE_CHECKLIST.md and install.sh reference v6-era commands; the env-var configuration contract (loader docstring, docs/configuration) is not implemented (P1-04). No dedicated deployment.md/migration.md exists (deployment guidance lives in docs/v7-release-guide.md + docker posts).
• Defect vs docs: docs claim HUNTERX_* env overrides; the loader never reads them.

Verdict: documentation is extensive and link-valid, but several critical runtime behaviors depend on undocumented or unimplemented assumptions (env config, base-install no-dependency mode).

14. Test Matrix

Empty or misleading suites:

• tests/framework/ contains helpers/fixtures only (correct, not a suite).
• tests/tools/ (80 tests, the Sprint 034.5 toolchain certification suite) is missing from [tool.pytest.ini_options] testpaths — python -m pytest and the CI pytest gate do not run it. Sprint 034.5 reported these as part of the default run; that is inaccurate. Misleading.
• tests/performance benchmark functions are themselves flagged as “slow” by the performance gate — the gate’s own output is misleading (P2-01).
• tests/test_reasoning.py at the repo root targets removed v6/v5 core.reasoning_engine_old — it cannot collect against v7; excluded from testpaths (stale, harmless).

15. Known Issues

16. P0 / P1 / P2 / P3 Summary

P0 — release blockers (2)

| # | Issue | Status | |—|—|—| | K01 | V7 tree untracked in git — CI/release cannot validate V7 | Open (carried from 034.1, declared resolved in 034.2–034.5 — incorrect) | | K02 | Base install/Docker image crash (unconditional sqlalchemy import) | Open (new) |

P1 — must fix (5)

| # | Issue | Status | |—|—|—| | K03 | ruff gate red (133) | Open (was P2-08 in 034.1, now worse; 034.5 “no P1” claim wrong) | | K04 | bandit B314 XXE ×2 — security gate red | Open (new) | | K05 | Mission orchestrator not resumable across restarts | Open (new) | | K06 | Env config (HUNTERX_*) unimplemented | Open (new) | | K07 | deadcode gate red | Open (new) |

P2 — acceptable technical debt (8)

K08 performance-gate self-fail, K09 N+1/commit loops, K10 tools suite not in testpaths, K11 timeline read-model unwritten, K12 concurrency upsert race, K13 v6-era compose/config/docs, K14 combined coverage 77%, K15 carried toolchain gaps (knowledge-only adapters, fan-out, redactor, binary pinning, rlimits).

P3 — post-release (2)

K16 stale v6 checklists/installer references; plus carried items (no DB runtime failover, CODEOWNERS gaps, __main__.py absence).

17. Release Readiness Score

Scoring model: 100 − 30×(#P0) − 15×(#P1) − 3×(#P2), floor 0.

• P0 = 2 → −60
• P1 = 5 → −75
• P2 = 8 → −24
• Release Readiness: 0/100 (blocked)
• Quality gates passing: 9/13 mandatory gates green on the working tree (pytest, mypy, coverage, architecture, docs, compliance, hygiene, dependencies, packaging) vs 4 red (ruff, deadcode, security, performance).
• Test suite health: 100% green (3474 passed; +80 tools suite green when run).

The product code and tests are healthy and green; the release engineering envelope is not (git state, default install, security/deadcode/ruff gates, mission resumability, env config).

18. Final Gate

19. Final Recommendation

STOP. Do NOT begin Sprint 035.

Sprint 034.6 — FINAL ENGINEERING CERTIFICATION: BLOCKED.

The engineering substance of HunterX v7 is strong and healthy — the integrated platform works end-to-end, all 3474 default tests pass, the toolchain and intelligence/proof pipelines are certified, and no functional regression was found. But the release is not ready because the engineering gate envelope fails:

1. P0 — the v7 delivery is not in git. A clean main checkout cannot build, test or release V7. This is Sprint 034.1’s own P0-01, never closed; later 034.x reports declared “no P0” inaccurately.
2. P0 — the default install is broken. pip install hunterx crashes at import without the optional db extra; the Docker image healthcheck fails.
3. P1 — three mandatory CI gates are red (ruff 133, bandit B314 XXE ×2, deadcode) and the performance gate can never pass as configured.
4. P1 — two runtime contract breaks: mission orchestration state is not resumable across process restarts, and HUNTERX_* environment configuration is documented but never implemented.

Exact remaining blockers (minimum to unblock):

• Commit the complete v7 tree (P0-01) and re-run CI on a clean checkout.
• Make db/sql imports lazy (or add db to core deps) so the base wheel and Docker image run (P0-02).
• Fix bandit B314 XXE with defusedxml (P1-04).
• Add a mission-restore path (hydrate OrchestratedMission from TIDB on start/resume) so CLI/API workflows survive restarts (P1-03).
• Implement env-var application in the config loader (P1-06).
• Clean the 133 ruff violations and 3 vulture findings (P1-03/P1-05), and fix the performance-gate slow-test logic (P2-01).

Sprint 035 may begin only after the P0 items are closed and the P1 items are resolved or explicitly re-scoped with acceptance criteria.

; broken nav/sitemap; malformed docs/cli/ front matter. | | P2-12 | Stale version claims across CHANGELOG.md, ROADMAP.md, CITATION.cff, SECURITY.md, SUPPORTED_PLATFORMS.md (6.0.0 vs 7.0.0). | | P2-13 | V6-era docs still describing scan/module/doctor/payload/agents commands and HX_` env on live pages (README, docs index, features, cli, configuration, Docker_Guide, faq, systemd, tutorials, posts). |

P3 — POST-RELEASE

| ID | Issue | |—|—| | P3-01 | .pre-commit-config.yaml hunterx-arch local hook with language: system silently no-ops if uninstalled. | | P3-02 | CODEOWNERS gaps for src/hunterx/{cli,platform,architecture,api,security,knowledge}. | | P3-03 | Orphaned .pyc files in alembic/versions/__pycache__ for deleted migrations. | | P3-04 | googlea591cd58e85d83b3.html tracked (public token, benign) — confirm intent. |

11. Repairs Performed (validated)

1. .gitignore — added *.db, *.sqlite, *.sqlite3, hunterx.db, /data/, /artifacts/, .mypy_cache/, .ruff_cache/, .benchmarks/.
2. Untracked 12 V6 SQLite DBs (git rm --cached; files kept on disk) — verified no .db files remain tracked.
3. Deleted stale root hunterx.egg-info/ (V6.0.0 metadata). Verified importlib.metadata.distribution("hunterx") now reports 7.0.0.
4. hunterx.py — now inserts src/ ahead of the repo root and delegates to V7 (python hunterx.py version → HunterX v7.0.0).
5. Dockerfile — ARG VERSION=7.0.0; HEALTHCHECK hunterx version; removed COPY hunterx.yaml/COPY payloads/; HX_LOG_LEVEL→HUNTERX_LOG_LEVEL; EXPOSE 8080. No 6.0.0/HX_/doctor markers remain.
6. install.sh — sdist URL hunterx-7.0.0.tar.gz; banner v7; smoke test hunterx version; help text uses V7 commands.
7. .dockerignore — exclude V6 tree (hunterx/, payloads/, core/, api/, plugins/, awesome-pentest/), DBs, caches, artifacts/, data/, and non-runtime trees (alembic/, eng/, capabilities/, config/).
8. docs/v7-api-intelligence-implementation-plan.md — removed the broken link to the nonexistent v7-api-intelligence.md; docs gate now 7/7.

12. Validation Results

13. Final Phase Verdict

Phase 034.1 — PASS, with one P0 release blocker carried forward.

• ✔ V7 runtime path identified (console script → hunterx.cli:main → build_platform(); API via hunterx.api.app:create_app; missions via hunterx mission/hunt).
• ✔ No unknown V6 runtime contamination remains in the packaged path. All known V6 runtime vectors were either repaired (hunterx.py, Dockerfile, install.sh, egg-info, tracked DBs) or are explicitly tracked as remaining (repo-root shadowing P1-01, docker-compose P1-02).
• ✔ Configuration authority identified (src/hunterx/config/hunterx.yaml + Settings via loader.load_default_settings); env precedence noted as unimplemented (P1-06).
• ✔ Packaging path verified (src-layout, entry points, requirements.lock, repaired Dockerfile).
• ✔ CI problems identified (ruff gate red P2-08; dependency-review V6 watch P2-05; no 6.0.0 hardcodes).
• ✔ Stale documentation classified (ACTIVE V7 / HISTORICAL V6 / STALE / CONTRADICTORY / BROKEN) and the failing docs link repaired.
• ✔ Database artifacts identified (12 tracked V6 DBs untracked; V7 hunterx.db gitignored; no credentials found).
• ✔ Release blockers classified (P0-01 untracked V7 tree — the sole P0).
• ✔ Repairs validated (full test suite green; gates green except pre-existing ruff).
• ✔ Report generated (docs/v7-sprint-034.1-repository-integrity.md).

STOP — Phase 034.1 complete. Do not proceed to 034.2 automatically.