@ascenda-one/github-collector

The collaboration signal family (consolidated report §4.2): review load and pull-request activity, collected from a code forge.

What it emits

| Event | Meaning | Workload leg | |---|---|---| | review_requested_of_me | someone asked you to review | supervision | | review_given | you submitted a review | supervision | | pull_request_opened | you opened a pull request | creation | | pull_request_closed | a pull request you opened was closed without merging | neutral | | pull_request_merged | a pull request you opened was merged, by anyone | neutral |

The two review events are the report's verification overload concern — the checking burden that concentrates on senior engineers as a team adopts AI.

The rule that shapes the whole package

Only your own activity is ever emitted. An event is produced when the payload says you did the thing or you were asked; a payload about two other people produces nothing at all. ASCENDA_FORGE_LOGIN is required and the collector refuses to run without it, because falling back to the payload's actor would silently start recording colleagues.

This is not squeamishness. "Who reviews for whom" is a map of a team, and a wellbeing rail that assembles one has become a management tool. Concentration of checking load is still answerable — it shows up in your own supervision share, and in cohort aggregates the org rail already suppresses below its minimum cohort size.

What never travels

No repository name, PR title, branch name, PR number, review body, or any other person's login. The repository is reduced to an 8-character hash so that "is it always the same repository" stays answerable without naming it, and the head branch to a 16-character one (see below). There is no field on the emitted metadata that a title or a body could be placed in, and a test asserts each of those strings is absent from what gets sent.

Matching a pull request to a coding session

Your pull request events, review events included, carry repoKey (the repository) and branchKey (the head branch), plus prCreatedAt, and prClosedAt and prMergedAt once it's done. The Claude Code collector puts the same two keys on each event of a session, so a session and a pull request on the same repository and branch carry the same pair. Match on the keys and on the session overlapping the PR's open window, from prCreatedAt to prClosedAt or prMergedAt: a branch called fix gets reused, and the window says which pull request a session was working on.

• A pull request from a fork also carries headRepoKey. A clone of the fork has the fork as its origin, so match its sessions against headRepoKey, and against repoKey when there isn't one. The branch key is taken over the fork's name for the same reason. If the fork has been deleted, there's no branch key at all, since the name the clone hashed is gone.
• There's no branchKey when the head branch is its repository's default branch. The hooks leave it off there too, so those match on repoKey and the window alone.
• One session can span several branches. Each of its events carries the branch it was on, so a session can match more than one pull request.

Only github.com repositories get keys.

The trade-off. Neither key is salted, because this step runs in CI where no salt exists. Anyone holding one can check a guess at a repository or branch name, and for a public repository those names are public. The repository digest already made that trade; the branch digest adds a name to it. Turn the keys off with --no-repo-keys on the command, or ASCENDA_REPO_KEYS=off in the step's environment. The 8-character projectHash and the times stay.

Withdrawal is not derivable, deliberately

There is no "did not review" event and there must never be one. Reviewing less is exactly the signal the report says must never be machine-interpreted — a quiet week has too many innocent explanations. Nothing here counts absence.

Consent

Collaboration events ride workflow_telemetry, not ide_telemetry, and the collector has its own tool type (github_collector). Both are deliberate: a pull request is not an IDE event, and someone may be willing to share how they work in their editor and not how they work with their team. The two are separately revocable.

Use in GitHub Actions

Ready to copy: examples/workflow.yml. Each person pairs a collector identity of their own, npx -y @ascenda-one/claude-code-hooks pair --tool-type github_collector, which prints the installation id and names the token file to read. Those go into repository secrets with that person's suffix, along with their GitHub login.

name: ascenda-collaboration
on:
  pull_request:
    types: [opened, closed, review_requested]
  pull_request_review:
    types: [submitted]

jobs:
  collect:
    runs-on: ubuntu-latest
    steps:
      - name: ascenda (octocat)
        run: npx @ascenda-one/github-collector
        env:
          ASCENDA_TOOL_INSTALLATION_ID: ${{ secrets.ASCENDA_TOOL_INSTALLATION_ID_OCTOCAT }}
          ASCENDA_EVENT_WRITE_TOKEN: ${{ secrets.ASCENDA_EVENT_WRITE_TOKEN_OCTOCAT }}
          ASCENDA_FORGE_LOGIN: ${{ secrets.ASCENDA_FORGE_LOGIN_OCTOCAT }}

ASCENDA_FORGE_LOGIN is configured, never derived

Set it to the paired person's own login, once, when you store their secrets. Don't use ${{ github.actor }}. The actor is whoever triggered the run, and the installation secrets belong to one person:

• When a colleague opens a pull request or submits a review, they're the actor and the author, so the event matches and lands under your installation. That records a colleague.
• On review_requested the actor is the person asking. Your request would only match if you'd asked yourself, so review_requested_of_me never fires.

The collector can't tell a typed login from one wired to the actor, so this rule lives in your workflow file.

One step per participant

A step carries one person's installation, so a repository shared by several people who've paired needs one step each, every one with its own suffixed secrets. Each step reads the same payload and emits only its own person's activity; the others exit with nothing to send. A matrix over the suffixes works too, with secrets[format('ASCENDA_FORGE_LOGIN_{0}', matrix.who)] and the same for the other two. Bear in mind that anyone who can edit the workflow can read every participant's write token in a run.

The step exits 0 on every path that is not a configuration error, including "nothing to emit". A telemetry step must never be the reason a build goes red.

Locally, pipe a payload instead:

cat examples/sample-review-submitted.json | ascenda-forge-collect pull_request_review