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.