ForkSense · Specification §38

Study the repository before inheriting its assumptions.

ForkSense examines current code, maintenance, known problems, rejected proposals, active forks, contributor work, and executable evidence before Torsionfield adopts, wraps, extracts, forks, or declines external software.

STAGED TARGETDOES NOT BLOCK DIRECT WORK
Current code

Default branch, releases, recent commits, tests, issues, TODOs, and actual operational use.

Rejected proposals

Distinguish technical failure, scope mismatch, timing, duplication, security, licensing, and unknown reasons.

Fork ecology

Trace ancestry, unique patches, maintenance, tests, adoption, and upstream synchronization burden.

Executable decision

Build or test the leading candidate instead of choosing by stars, prose, or popularity.

Minimum experiment

One repository, two real candidates.

  1. Ingest current branches, releases, issues, pull requests, reviews, and recent commits.
  2. Find one rejected or deferred proposal and one active fork or successor.
  3. Revise the research route once in response to evidence.
  4. Produce two competing integration candidates.
  5. Run a bounded build or code-level test.
  6. Return a current recommendation with freshness, uncertainty, exit, and rollback.
DECISION OUTPUT
ADOPT   upstream already fits
WRAP    preserve upstream + add contract
EXTRACT reuse one bounded seam or patch
FORK    sustainable evidenced divergence
ALLY    cooperate with exact maintainers
DECLINE evidence or fit is insufficient

No social authority score.

Public contributor context may route research toward relevant technical work. Stars, follows, affiliations, popularity, or inferred personal traits do not establish competence, authority, trust, or governance power.