[Dependency] verify and hash-lock immutable fast-mlsirm Judge artifact for Task 7

[seonghobae]

Current dependency truth

The original blocker is obsolete: Task 7 no longer waits for the Judge symbols to exist in an immutable fast-mlsirm source release.

Fresh immutable evidence shows:

• latest immutable GitHub release: fast-mlsirm v0.9.1, published 2026-08-26;
• exact tag source commit: 09f762ded35786dd1078222a4577ff09d649816f;
• tagged public package exports ContextualOrchestratorJudge, JudgeCriterion, JudgeFormatError, LLMJudgeResult, and validate_irt_response_matrix;
• tagged metadata declares fast-mlsirm==0.9.1 and Python >=3.12;
• the immutable GitHub release remains assetless: no attached wheel/sdist exists whose consumed bytes can be integrity-pinned;
• owner requirement is ContextualWisdomLab/fast-mlsirm#1691; current implementation/publication repair is fast-mlsirm#1692@401a23765cc7e9686927f32f5a4ad268ff1b26af. Neither mutable owner head is a Naruon production dependency.

Current Naruon email-writing ancestry

Fresh task-owned heads after the latest non-force repair/restack are:

• design root docs(adr): design Inkspan-based LLM email writing guidance #1322 9f1836d09e6b4db97855d701d8220268e9fb4d87;
• strict contracts feat(email-writing): define strict review contracts #1327 ab74a345e4d03680da32a7eac2cc1fca3005cfb3;
• privacy evidence feat(email-writing): persist privacy-minimized review evidence #1328 ea61b9de9cd26a26209da36e858510a31486531a;
• authorized thread context feat(email-writing): build authorized thread context #1329 64d1f746723616b0111eb40b130d6f07ed413a86;
• contextual-orchestrator boundary feat(email-writing): add hardened contextual-orchestrator boundary #1356 beb28466573b2163df97b027a6d3ac3776773869;
• Candidate feat(email-writing): parse contextual review candidates #1375 6a37753c86959ae07e6257496658ea4ae17f513c;
• independent Judge feat(email-writing): restack independent Judge on current candidate #1524 ad888235577ba87f32d96e06fab1cfb9992d84a9;
• policy feat(email-writing): add versioned Judge admission policy #1530 32c7e33c304d1b500ddc230044e2877edcf411c8;
• review service feat(email-writing): compose bounded judged review service #1535 c958b9964f925b6dca99e4c2c4db671934511a40;
• review API feat(email-writing): expose bounded advisory review API #1536 4c14771acddd150f59b5ce0888d15bae49686b0c.

External Cursor #1402 remains read-only at 3d6b3341c5dd15512d5d60cd5f8d95a1bbc6d846. It is not writable ancestry and no external/predecessor checks, reviews, approvals or source snapshots transfer into the task-owned stack.

Latest Task-7/Task-5 execution RCA

Task-7 predecessor head a2c07ea13f5503b1877461ff0477e6e5f0528a59 eventually acquired a Python 3.14 runner in Email Writing Judge TDD run 33576580196. The run produced a real source-backed failure during collection: importing EmailWritingOrchestratorPort runtime-imported the concrete contextual-orchestrator client, which transitively materialized core.config.settings and required DATABASE_URL merely to import the Task-5 port.

This was correctly classified as a Task-5 dependency-direction/import-side-effect defect, not a Task-7 test or infrastructure defect. Naruon repaired it test-first at #1356:

• RED a08ef0b7f3dc95f69af4bb21a742de92eea587b4 requires port import to work without DATABASE_URL and without materializing the concrete adapter or core.config;
• causal fix/current Task-5 head beb28466573b2163df97b027a6d3ac3776773869 moves concrete adapter/type imports behind TYPE_CHECKING, keeping the domain-facing port config-free at runtime;
• no DATABASE_URL, PYTHONPATH=., conftest, or workflow bootstrap workaround was restored.

The repaired Task-5 head was then propagated through Tasks 6–10 by ordinary non-force descendant merges. All predecessor execution/review evidence is stale after those head changes.

Current Task-5 jobs 100235583025 / run 33626560905 and 100235582463 / run 33626560809 are queued before steps. Current Task-7 job 100236245382 / run 33626766944 is likewise queued before steps; same-head sibling 100236226066 was cancelled pre-execution. These are non-passing control-plane states already advanced to .github#712, not evidence that the repaired source failed.

Remaining immutable artifact gate

A source tag/release is not sufficient production dependency evidence. Before Naruon imports the released Judge at runtime, one approved immutable distributable/package source must bind together:

1. exact package version;
2. exact consumed wheel/sdist integrity hash;
3. exact source-commit provenance to the immutable release;
4. Python 3.14 install/import/execution compatibility for that artifact;
5. canonical Naruon hash-lock entry and clean --require-hashes installation evidence;
6. dependency-contract tests rejecting mutable branch/Git URL/source-copy/local-stub/workspace-path forms;
7. direct tests against the released Judge symbols after installation;
8. separately dependency-injected judge_package_unavailable tests that do not assume ambient package absence.

Until that evidence exists, production consumption fails closed. Do not vendor source, consume a mutable branch, create a local compatibility stub, or substitute Candidate confidence for independent Judge evidence.

Owner-side publication RCA and live repair path

Owner-side Publish Package run 32966867962 reached a hosted runner, but provenance verification failed before package build/publication because the publication control-plane identity changed after release verification. The run was dispatched with CONTROL_PLANE_COMMIT=47e7ba08bddfa063d2aaf883b027acb929b28859 while the publication workflow executed from main@99eb70913ef9e7749333c2f0059ea11a4be0fb4d. The workflow correctly failed closed with publication control plane moved after release verification; downstream sdist/wheel/Python-version/release-asset/PyPI jobs were skipped.

fast-mlsirm#1692@401a23765cc7e9686927f32f5a4ad268ff1b26af adds builder-local sdist/wheel provenance attestations, exact-source SPDX JSON SBOM, SBOM gating before GitHub/PyPI publication, and release-asset attachment while preserving the token-based PyPI contract. Naruon does not merge, rewrite, or consume that mutable owner head.

After #1692 or a verified successor lands, the owner must publish through a freshly verified control-plane identity while preserving exact release-source identity. If policy forbids retroactive asset completion for immutable v0.9.1, the acceptable path is the next immutable patch release exposing the same required Judge public surface and passing the provenance/package/Python-3.14 gates. Naruon consumes only the resulting immutable externally available artifact.

Measurement/admission boundary

The dependency artifact gate does not authorize user-facing diagnostics. Candidate and Judge remain separate roles/calls. Same-model Candidate/Judge use requires an explicitly published compatible calibration policy; otherwise adjudicate or abstain. User-facing publication remains gated on preregistered calibration/admission protocol, sealed locked holdout, human/adjudicated reference evidence, and publish_decision=publish.

Inkspan sibling dependency

Inkspan remains independently gated. Fresh verification still shows immutable release v0.3.1 with no released writing-diagnostics public package surface. Naruon must not consume open/Draft Inkspan writing-diagnostics branches. Editor integration waits for a future immutable released package surface with integrity, source provenance, and the required revision-bound diagnostic contract.

Done

Close this issue only after an approved immutable distributable Judge artifact is consumed through Naruon's canonical hash-locked dependency path, Python 3.14 compatibility and source/artifact provenance are verified, current-stack Task 7 exercises the released symbols while retaining fail-closed dependency-injection coverage, and exact-head CI/security/review evidence passes. Predecessor/local/model-only evidence is non-passing.

[seonghobae]

Fresh immutable-dependency refetch (2026-09-02): fast-mlsirm latest immutable GitHub release is still v0.9.1; the release remains immutable=true and still has assets=[], so there is still no wheel/sdist byte artifact Naruon can hash-lock. The owner publication repair fast-mlsirm#1692 is still open/mergeable but its live exact head has advanced to 873f4bb5fdb5a215d43273c46868ff545bfaf09e; the issue body's remembered 401a2376… implementation head is therefore historical and must not be consumed. Inkspan latest immutable release also remains v0.3.1 with assets=[] and no writing-diagnostics release surface. Keep Task 7 production consumption fail-closed: no mutable head/Git URL/source copy/local stub substitution. Next Naruon action remains triggered only by a newly published immutable fast-mlsirm distributable with exact version/hash/source provenance and Python 3.14 install/runtime evidence; then pin and exercise the released symbols on the current Task-7 lineage.