# Task Contract

Create `task-config.json` before substantial distillation or deliverable work. Infer fields already established by the user or sources and ask only for consequential missing choices.

## Required fields

```json
{
  "version": 1,
  "input_data": ["path/to/file-or-folder"],
  "knowledge_package": "knowledge/manifest.json",
  "objective": "What the work must enable",
  "audience": "Who will use the deliverables",
  "deliverables": [
    {
      "id": "architecture-demo",
      "type": "system-demo",
      "output_path": "deliverables/architecture-demo.html",
      "requirements": {
        "claims": [],
        "functions": [],
        "observable_effects": []
      },
      "evaluation": {
        "skill": "evaluate-web-deliverable",
        "profile": "system-demo-v1",
        "rules": []
      }
    }
  ]
}
```

Every deliverable needs a unique ID and output path, one implementation skill, and one evaluation profile. A request for multiple deliverables creates multiple entries; never merge their scores.

## Optional preparation settings

```json
{
  "preparation": {
    "strategy": "auto",
    "graphify": "detect",
    "semantic_retrieval": "auto"
  },
  "iteration": {
    "use_user_feedback": true,
    "max_rounds": 3
  }
}
```

`graphify` accepts `detect`, `off`, or `required`. The default is `detect`: use it only when installed and helpful, never install it automatically. `semantic_retrieval` accepts `auto`, `off`, or `required` and describes retrieval over the distilled package, not graph construction.

## Decision-Frontier Elicitation ("Grilling") for Contracts

When resolving missing contract fields, follow the Decision-Frontier principle:

1. **Investigate Environment Facts Autonomously:**
   - Detect input paths, file existence, repo topology, paper format, and line counts directly via tools. Never ask the user questions that code can answer.
2. **Walk the Contract Frontier ($F_t$):**
   - Resolve **Objective & Audience** (Prerequisite) before asking for deliverable specifics.
   - Resolve **Deliverable Type** before asking for required functions or evaluation profiles.
   - Never ask premature questions about fine-grained CSS styles, thresholds, or interactive effects until the deliverable contract is grounded.
3. **Cost-Aware Clarification:**
   - Infer sane defaults from [`reference/deliverable-registry.json`](deliverable-registry.json). Only prompt the user for consequential missing choices.

## Production and evolution use

- Production: create the smallest sufficient contract, build, evaluate, collect user feedback, and iterate within the agreed limit.
- Skill evolution: use the Guarded Skill Evolution (GSE) change contract schema specified in [`reference/guarded-skill-evolution.md`](guarded-skill-evolution.md). Freeze the task config and evaluator versions before comparing candidates. The baseline and candidate must receive the same input, deliverable contract, evaluator profile, model conditions, and budget.

For controlled evolution, also record reproducibility conditions:

```json
{
  "input_fingerprint": "sha256 generated by task_contract.py",
  "comparison": {
    "model": "model identifier",
    "tools": ["allowed-tool"],
    "token_budget": 20000,
    "time_budget_seconds": 900,
    "retry_budget": 1
  }
}
```

The resolver fingerprints available input files automatically. A result without an input fingerprint and comparison conditions can guide a production iteration but cannot promote a skill.

User feedback may add or clarify evaluation rules for the next iteration. Do not retroactively change a completed comparison's rules; create a new contract revision.