Branch analysis

Inputs

• Repository identity (owner/repo).
• Branch, base, and head refs.
• Changed-file metadata — paths, sizes, line counts.
• Labels and linked issues.
• Commit messages.
• Validation summaries (lint/test outcomes, not logs).
• Optional local scorer output.
• User-supplied scenario assumptions.

Outputs

• Lane context (maintainer / contributor / hybrid).
• Role context for your account.
• Scoreability scenarios (see Scoreability).
• Branch blockers and account/queue blockers.
• Maintainer-fit notes.
• Public-safe PR packet preview.
• Ranked next actions.

Example invocation

POST /v1/local/branch-analysis
Authorization: Bearer ••••••••
Content-Type: application/json

{
  "login": "your-github-login",
  "repoFullName": "entrius/gittensor",
  "baseRef": "main",
  "headRef": "feat/scorer-cleanup",
  "changedFiles": [
    { "path": "src/scorer.ts", "additions": 42, "deletions": 8, "status": "modified" }
  ],
  "labels": ["scorer", "ready-for-review"],
  "linkedIssues": [421],
  "commitMessages": ["refactor scorer gating", "fix linked-issue projection"],
  "validation": [
    { "command": "npm run typecheck", "status": "passed" }
  ]
}

The request body is a strict schema — every field must match a known key exactly (repoFullName not a nested repo object, changedFiles with additions/deletions, linkedIssues not linked_issues) and unknown keys are rejected rather than ignored.