C.22.1:7 - Solution — one adaptation signature over the C.22 anchor

• Use one shared adaptation-signature field set for this question. G.5, G.9, and later notes may cite or consume it, but they should not silently rename threshold, prior-exposure, transfer, downside, or corridor-entry terms.
• When specialization is the live adaptation question, publish one adaptation signature bound to the declared TaskFamilyRef or TaskSignature, not one generic improvement claim.
• The signature should expose at least:
  • thresholdTarget
  • timeToThreshold
  • budgetToThreshold
  • postThresholdEfficiency?
  • priorExposureDeclaration
  • transferTarget?
  • transferGain?
  • retentionWindow?
  • downsideEffect?
  • corridorEntryBaseline?
  • corridorEntryEvidence?
  • steppingStoneEvidence?
• These fields stay anchored to the same work target and work-measure threshold semantics already declared by C.22, so adaptation is typed as movement toward usable specialization rather than as an ungrounded growth story.
• C.22 continues to carry the declared task-family anchor, task typing, and baseline TaskSignature. C.22.1 narrows the adaptation-signature question to threshold timing, reuse, downside, and corridor-entry disclosure over that existing anchor.