import type { ResolverFn } from './types';

/** Shared criteria only: the caller owns scope, output, and permission to act. */
export const generateSharedLibsRubric: ResolverFn = () => `### Shared-code evaluation rubric

- **Prove the callers.** Require at least two verified, first-party authored source
  locations, with functions and lines. Actual added or uncommitted source qualifies.
  Only an engineering-plan review may use proposed callers; label those assumptions
  and distinguish them from existing source. Similar names or formatting alone do
  not establish equivalent behavior. Generated and third-party copies cannot qualify
  as callers or contribute savings. Follow generated copies back to authored
  templates/resolvers. Existing dependencies remain valid reuse targets.
- **Reuse before extracting.** Inspect existing libraries and helpers first. Compare
  behavior, inputs, outputs, error handling, side effects, security requirements,
  dependencies, and deployment/runtime boundaries. Preserve differences callers need;
  do not bridge languages or isolated deployments without a practical shared contract.
- **Keep the helper small.** Name its destination and contract, the callers to migrate,
  and the smallest adoption sequence. Avoid option-heavy helpers and coupling unrelated
  components. Point to existing tests or established use, specify shared-contract and
  caller-integration coverage, and describe the blast radius of a shared failure.
- **Account for the whole change.** Name removed blocks and their replacements. Show
  estimated implementation lines removed, added, and saved separately from total lines
  removed, added, and saved including tests and integration. Savings = removed - added.
  Count moved code on both sides, exclude generated/vendor lines, use ranges when
  uncertain, and do not count overlapping removals twice across opportunities. State
  when tests or integration may make the total change grow.
- **Rank useful changes.** Favor reliability gains and total net savings, then low
  adoption and testing risk. Prefer proven code used by several callers. Use recent
  activity to break ties between comparable benefits, not as evidence by itself.
  Explain choices centered on older code. Reject similarities with incompatible
  contracts and opportunities whose benefits do not justify the abstraction.`;