Current source, releases, build paths, tests, defects, TODOs and recent change velocity.
ADAPTIVE REPOSITORY INTELLIGENCE · 2 AUGUST 2026
Read the repository.
Then read what it refused to become.
ForkSense turns commits, issues, review decisions, forks, contributor trajectories and adjacent public discourse into an evidence graph for safer and more strategically intelligent software integration.
SPECIFIEDREFERENCE WORKFLOWLOCAL GRAPH PILOT NEXT
Closed proposals, declined pull requests, abandoned branches and the reasons maintainers gave.
Active divergences, unique patches, upstream lag, adoption, maintenance quality and strategic intent.
Public contribution history, adjacent repositories, technical interests and collaboration patterns.
The workflow learns while it researches.
ForkSense does not apply one fixed checklist to every repository. It begins with a provisional research strategy, records why each source is being examined, and revises the strategy whenever the evidence reveals a better route.
1 · ORIENTMap architecture, known problems, TODOs, outstanding issues, release state and recent commits.
2 · DIVERGETrace denied proposals, unresolved disagreements, active forks and alternative implementations.
3 · CONTEXTUALIZEStudy contributors, adjacent repositories, public interests and external discussion only where relevant.
4 · REVISEChange categories, priorities and search routes; preserve the old strategy as provenance.
Evidence is typed, current and revisable.
| Object | Question answered | Failure avoided |
|---|---|---|
| RepoSnapshot | What is actually current? | Integrating against stale documentation. |
| IssueOpportunity | Which known problems align with our needs? | Rebuilding what maintainers already understand. |
| RejectionSignal | What future was declined, and on what stated grounds? | Treating maintainer scope as technical impossibility. |
| ForkDivergence | Where did that future continue? | Ignoring working alternatives outside upstream. |
| ContributorContext | Who understands this seam deeply? | Evaluating patches without their technical lineage. |
| StrategyRevision | Why did the research plan change? | Opaque LLM wandering and hindsight rationalization. |
| IntegrationCandidate | What should Superfluid adopt, wrap, fork or reject? | Choosing by popularity or code volume alone. |
A denied proposal is not automatically a good idea.
ForkSense classifies rejection evidence instead of romanticizing it. Technical unsoundness, poor tests, security risk, duplication, timing, product scope, governance conflict and explicit maintainer strategy are distinct causes. Motive is never asserted where the record only supports inference.
LIVE EXAMPLE · GEMINI CLI
A provider-agnostic backend proposal was closed as a low-priority backlog item. A later 31-commit multi-provider pull request was also closed after implementing Google, Anthropic and OpenAI-compatible providers; its author explicitly stated that a separate fork would remain if upstream declined the change.
ForkSense records this as: demonstrated demand + implemented alternative + upstream strategy mismatch + fork opportunity, not merely “closed issue.”
LOCAL INTELLIGENCE GRAPH
Fast enough to become cumulative memory.
The reference architecture keeps raw API responses and cloned Git objects content-addressed, stores normalized evidence in a local graph, and exports portable snapshots. The first provider target is cozo-local/1; the contract permits Kuzu, SQLite-derived or remote graph providers later.
Repository ──HAS_COMMIT────▶ Commit Repository ──HAS_ISSUE─────▶ Issue Issue ───────PROPOSES──────▶ Capability Decision ───REJECTS────────▶ Proposal Fork ───────IMPLEMENTS─────▶ Proposal Contributor ─AUTHORED──────▶ Commit Contributor ─MAINTAINS─────▶ Repository Discourse ──DISCUSSES──────▶ Issue Strategy ───REVISED_BY─────▶ Evidence
How ForkSense changes Superfluid development.
Use upstream directly when current maintenance, interfaces and governance already satisfy the capability contract.
Preserve upstream while adding a provider adapter when the missing behavior belongs above implementation identity.
Continue a rejected but viable direction when evidence shows persistent demand, competent maintainers and sustainable divergence.
Lift one proven seam or patch instead of inheriting an entire repository and its governance constraints.
Contact contributors or fork maintainers whose public work demonstrates ownership of the exact technical boundary.
Reject attractive code when freshness, tests, licensing, security or maintenance evidence is insufficient.
Torsionfield integration boundary.
ForkSense supplies evidence to the existing Prompt Commit, capability-promotion, verification and release gates. It does not gain authority to merge code, rank people, infer private beliefs or convert social popularity into technical truth.
cap.repo.intelligence.build({
target: "owner/repository",
question: "Should Superfluid adopt, wrap, fork, extract or reject?",
freshness: "current",
fanoutBudget: { repositories: 40, people: 20, externalSources: 30 },
requiredEvidence: ["commits", "issues", "pulls", "forks", "releases"],
output: "IntegrationIntelligencePacket/1"
})Minimum vertical slice.
- Ingest one target repository, its current issues, pull requests, releases and recent commit graph.
- Detect one declined proposal and identify active forks or successor repositories implementing it.
- Build a public-work graph for the directly relevant contributors only.
- Generate two competing integration strategies and their evidence dependencies.
- Run a clean-room build or bounded test against the leading candidate.
- Emit a signed Integration Intelligence Packet with freshness, uncertainty and rollback guidance.
Human boundary.
Public profile and collaboration data may guide where to look next. It must not be used to infer sensitive traits, assign reputation scores, or treat friendships, follows or stars as proof of competence. Every person-level observation remains source-linked, purpose-limited and removable from the local graph.