Shape Capability

Shape Tianheng Capability

Turn a demonstrated observation gap into a bounded upstream capability candidate. Preserve the adopter's intent as evidence; do not grant the missing reaction imaginary teeth.

Load References Deliberately

• Read gap-classification.md before declaring a capability gap.
• Read observation-contract.md when shaping the measure and reaction.
• Read feasibility-and-risk.md before recommending upstream work.
• Read upstream-handoff.md before persisting or routing the candidate.

These references target Tianheng 0.5.x. Inspect the adopter's resolved version and Tianheng's actual public surface before concluding that an observation is absent.

Phase 0: Gate Capability Pressure

Require:

• a discovered Cargo workspace;
• existing Tianheng use or an explicit adoption effort;
• an exact project-authorized structural claim;
• the contradiction that should react; and
• evidence that a supported Tianheng recipe was considered and rejected honestly.

In a mixed-language repository, narrow the claim to its Rust-observable portion. A constraint whose meaning depends on non-Rust code is not automatically a Tianheng capability gap.

Do not write adopter Constitution code, placeholder modules, baselines, or generated projection during this workflow.

Phase 1: Prove The Gap Is Real

Use gap-classification.md.

1. Resolve the adopter's Tianheng version from Cargo metadata or lockfile.
2. Inspect that version's public boundary surface, docs, recipe index, and relevant source.
3. Restate the claim as one contradicted structural fact.
4. Test whether an existing static, semantic, runtime, or composed observation already sees it.
5. Record why the nearest recipes fail without overstating their non-observations.

Classify:

• EXISTING_RECIPE: route back to forge-law;
• COMPATIBILITY_UNKNOWN: investigate the resolved/newer Tianheng line first;
• NON_STRUCTURAL: keep the claim in process, judgment, history, or API prose;
• CROSS_LANGUAGE: narrow to Rust or route to another governance system;
• TRUE_GAP: continue.

Do not name a new boundary merely because no remembered recipe comes to mind.

Phase 2: Preserve Intent Authority

Cite the exact direct instruction or durable project claim. Separate:

• the adopter's authority to state its architectural intent;
• evidence that current Tianheng cannot observe it; and
• upstream Tianheng authority to accept a new public capability.

The first two justify capability pressure, not upstream acceptance. Generic best practice and repository shape remain insufficient.

Phase 3: Design The Observation Contract

Use observation-contract.md. Produce:

## Observation Contract

**Intent authority**: <source>
**Governed target**: <crate, module, type seam, or runtime seam>
**Contradicting fact**: <one concrete fact>
**Observation source**: <Cargo metadata | Rust source tokens | syn AST | runtime probe>
**Observation owner**: <static | semantic | runtime | shared core>
**Scan perimeter**: <anchor and depth>
**Finding identity**: <stable target, rule key, structured fact>
**Actionable location**: <derivable file or faithful null>
**Repair polarity**: <deny_breach | allowlist_gap | null>
**Reason perimeter**: <what a future reason may honestly claim>
**Non-observations**: <important exclusions>

One pressure candidate describes one observation family. Split claims that require unrelated sources or repair directions.

Phase 4: Pressure-Test Feasibility

Use feasibility-and-risk.md. Determine:

• whether the source is available without executing arbitrary project code;
• whether facts can be canonicalized across formatting and aliases;
• whether target/rule/fact identity remains stable across diagnostic wording changes;
• whether an actionable file is a faithful byproduct rather than guessed;
• false-positive and false-negative boundaries;
• macro, conditional compilation, workspace, and platform limits;
• likely scan cost and cacheability; and
• whether the capability belongs in an existing dimension.

No concrete source or no honest precision boundary means DEFER_OBSERVATION, not a speculative API. Do not pre-create a crate or dimension to hold a future idea.

Phase 5: Specify The Reaction Proof

Design upstream-ready scenarios before API shape:

• one positive fixture containing the exact contradicting fact;
• one clean adjacent fixture that must not react;
• target/depth edge cases;
• identity stability under presentation-only changes;
• severity, baseline, and composed exit behavior;
• JSON projection fields including file/polarity when applicable; and
• constitution/scan error directions for invalid targets or unsupported source states.

State expected exit 0, 1, or 2 explicitly. A possible parser implementation is not evidence that the reaction contract is coherent.

Phase 6: Form The Capability Pressure

Return:

## Tianheng Capability Pressure

**Gap verdict**: TRUE_GAP
**Adopter evidence**: <claim and affected code>
**Nearest existing capability**: <recipe and exact mismatch>
**Observation contract**: <bounded measure>
**Reaction contract**: <target, rule, identity, severity, baseline, projection>
**Fixture matrix**: <positive, precision, error, composition>
**Feasibility**: <source, cost, limitations>
**Compatibility effect**: <public API / projection / baseline implications>
**Upstream owner**: Tianheng maintainers; candidate not accepted or implemented.

If the classification stops earlier, report ROUTE_FORGE, COMPATIBILITY_REQUIRED, DOCUMENT_ONLY, CROSS_LANGUAGE, DEFER_OBSERVATION, or DEFER_FEASIBILITY.

Phase 7: Hand Off Upstream Deliberately

Follow upstream-handoff.md. By default, leave the pressure as a reviewable report. When the user explicitly asks to persist it in a Tianheng checkout, follow that repository's current governance and proposal workflow. Do not implement the capability, edit Tianheng law, open a remote issue, or publish anything unless separately requested and authorized.

Hard Stops

• Do not declare a gap without inspecting the resolved supported Tianheng surface.
• Do not turn non-structural or cross-language intent into a Rust observation.
• Do not invent policy authority from code shape or best practice.
• Do not name a target, rule, boundary, or dimension without a concrete observation source.
• Do not claim precision without a clean adjacent fixture.
• Do not copy Tianheng's cookbook or pre-design an entire public API.
• Do not write a no-op adopter boundary, warning-only substitute, or permanent baseline.
• Do not implement or submit upstream changes as part of capability shaping.