---
phase: 06-formal-theory-projection-contract
plan: 02
type: execute
wave: 2
depends_on: ["06-01"]
files_modified: [research/knowledge-hub/knowledge_hub/aitp_service.py, research/knowledge-hub/tests/test_aitp_service.py]
autonomous: true
requirements: [FTS-01, FTS-02]
user_setup: []
must_haves:
  truths:
    - A formal-theory topic-skill projection only becomes available when theorem-facing trust artifacts are ready in the active run.
    - Non-ready formal-theory topics fail honestly with `blocked` or `not_applicable` and do not write false projection candidates.
  artifacts:
    - path: research/knowledge-hub/knowledge_hub/aitp_service.py
      provides: formal-theory applicability gate for project_topic_skill
    - path: research/knowledge-hub/tests/test_aitp_service.py
      provides: positive and negative service coverage for the new gate
  key_links:
    - from: research/knowledge-hub/knowledge_hub/aitp_service.py
      to: research/knowledge-hub/runtime/scripts/run_jones_chapter4_finite_product_formal_closure_acceptance.py
      via: formal-theory review and topic-completion artifacts
      pattern: formal_theory_review.json
---

<objective>
Implement the service-side applicability gate for formal-theory
`topic_skill_projection` without manufacturing reuse claims for non-ready
topics.

Purpose: make `project_topic_skill()` honest for theorem-facing lanes.
Output: service logic and tests for available/blocked formal-theory projections.
</objective>

<execution_context>
@D:/BaiduSyncdisk/Theoretical-Physics/.codex-home/get-shit-done/workflows/execute-plan.md
@D:/BaiduSyncdisk/Theoretical-Physics/.codex-home/get-shit-done/templates/summary.md
</execution_context>

<context>
@.planning/MILESTONE-CONTEXT.md
@.planning/REQUIREMENTS.md
@research/knowledge-hub/knowledge_hub/aitp_service.py
@research/knowledge-hub/runtime/scripts/run_jones_chapter4_finite_product_formal_closure_acceptance.py
@research/knowledge-hub/tests/test_aitp_service.py
</context>

<tasks>
<task type="auto">
  <name>Task 1: Teach AITPService when a formal-theory projection is actually ready</name>
  <files>research/knowledge-hub/knowledge_hub/aitp_service.py</files>
  <read_first>research/knowledge-hub/knowledge_hub/aitp_service.py, research/knowledge-hub/runtime/scripts/run_jones_chapter4_finite_product_formal_closure_acceptance.py, .planning/MILESTONE-CONTEXT.md, .planning/REQUIREMENTS.md</read_first>
  <action>Update `_derive_topic_skill_projection` and any helper logic it needs so `lane == 'formal_theory'` becomes `available` only when the active run has all of these conditions: `latest_run_id` is present, a theorem-facing review artifact exists at `validation/topics/<topic_slug>/runs/<run_id>/theory-packets/*/formal_theory_review.json`, that review reports `overall_status == 'ready'`, `topic_completion.json` reports `status` in `{promotion-ready, promoted}`, and `strategy_memory.row_count > 0`. If those conditions are not met, return `blocked` or `not_applicable` with an explicit reason and do not create a `topic_skill_projection` candidate row. Preserve the existing `code_method` path unchanged.</action>
  <verify>python -m pytest research/knowledge-hub/tests/test_aitp_service.py -q</verify>
  <acceptance_criteria>
    - aitp_service.py contains `formal_theory_review.json`
    - aitp_service.py contains `promotion-ready`
    - aitp_service.py contains `topic_skill_projection`
  </acceptance_criteria>
  <done>The service can distinguish a ready formal-theory seed from a merely interesting theorem-facing topic.</done>
</task>

<task type="auto">
  <name>Task 2: Add positive and negative service tests for formal-theory projection gating</name>
  <files>research/knowledge-hub/tests/test_aitp_service.py</files>
  <read_first>research/knowledge-hub/tests/test_aitp_service.py, research/knowledge-hub/runtime/scripts/run_jones_chapter4_finite_product_formal_closure_acceptance.py, research/knowledge-hub/knowledge_hub/aitp_service.py</read_first>
  <action>Add one test that builds a minimal Jones-like formal-theory fixture with a ready `formal_theory_review.json`, a `topic_completion.json` status of `promotion-ready` or `promoted`, and at least one strategy-memory row, then asserts `project_topic_skill()` returns `status == 'available'` without changing the human-reviewed promotion mode. Add a second test where the review is missing or not `ready` and assert the service returns `blocked` or `not_applicable` and leaves `candidate_ledger.jsonl` without any `candidate_type == 'topic_skill_projection'` row for that run.</action>
  <verify>python -m pytest research/knowledge-hub/tests/test_aitp_service.py -q</verify>
  <acceptance_criteria>
    - test_aitp_service.py contains `formal_theory_review`
    - test_aitp_service.py contains `promotion-ready`
    - `python -m pytest research/knowledge-hub/tests/test_aitp_service.py -q` exits 0
  </acceptance_criteria>
  <done>The formal-theory gate is pinned by service tests before the Jones seed exemplar is rewired in Phase 8.</done>
</task>
</tasks>

<verification>
- [ ] `python -m pytest research/knowledge-hub/tests/test_aitp_service.py -q`
</verification>

<success_criteria>
- Formal-theory projection availability is tied to explicit run-local trust artifacts
- Non-ready theorem-facing topics fail honestly and do not write false candidates
- The existing code-method projection flow remains intact
</success_criteria>

<output>
After completion, create `.planning/phases/06-formal-theory-projection-contract/06-02-SUMMARY.md`
</output>
