shared-libs.ts
35 lines · scripts/resolvers/shared-libs.ts at 3f79d81
1import type { ResolverFn } from './types';
2import { getHostConfig } from '../../hosts/index';
4/** The installed read-only Git helper. Always the trusted global runtime, never a repo-local root. */
5export const generateSafeGitPath: ResolverFn = (ctx) => `~/${getHostConfig(ctx.host).globalRoot}/bin/gstack-safe-git`;
7/** Shared criteria only: the caller owns scope, output, and permission to act. */
8export const generateSharedLibsRubric: ResolverFn = () => `### Shared-code evaluation rubric
10- **Prove the callers.** Require at least two verified, first-party authored source
11 locations, with functions and lines. Actual added or uncommitted source qualifies.
12 Only an engineering-plan review may use proposed callers; label those assumptions
13 and distinguish them from existing source. Similar names or formatting alone do
14 not establish equivalent behavior. Generated and third-party copies cannot qualify
15 as callers or contribute savings. Follow generated copies back to authored
16 templates/resolvers. Existing dependencies remain valid reuse targets.
17- **Reuse before extracting.** Inspect existing libraries and helpers first. Compare
18 behavior, inputs, outputs, error handling, side effects, security requirements,
19 dependencies, and deployment/runtime boundaries. Preserve differences callers need;
20 do not bridge languages or isolated deployments without a practical shared contract.
21- **Keep the helper small.** Name its destination and contract, the callers to migrate,
22 and the smallest adoption sequence. Avoid option-heavy helpers and coupling unrelated
23 components. Point to existing tests or established use, specify shared-contract and
24 caller-integration coverage, and describe the blast radius of a shared failure.
25- **Account for the whole change.** Name removed blocks and their replacements. Show
26 estimated implementation lines removed, added, and saved separately from total lines
27 removed, added, and saved including tests and integration. Savings = removed - added.
28 Count moved code on both sides, exclude generated/vendor lines, use ranges when
29 uncertain, and do not count overlapping removals twice across opportunities. State
30 when tests or integration may make the total change grow.
31- **Rank useful changes.** Favor reliability gains and total net savings, then low
32 adoption and testing risk. Prefer proven code used by several callers. Use recent
33 activity to break ties between comparable benefits, not as evidence by itself.
34 Explain choices centered on older code. Reject similarities with incompatible
35 contracts and opportunities whose benefits do not justify the abstraction.`;