Record the AI usage disclosure in the contributions sheet #108

Overview

The contributions sheet records every community pull request, but not what the contributor said
about their use of AI. Reviewers are reading that out of each pull request by hand.

Add a column that records the disclosure, and a second one a maintainer can use to mark a
disclosure they do not believe.

Complexity: Low
Target branch: main

Context

scripts/update-pr-spreadsheet.js runs daily in this repo since #101, and upserts every public
contributor pull request in the org updated in the last two days.

COLUMNS covers A to H, and toRow produces those eight values: state or merge date, url, author,
title, repo, created date, requested reviewers, assignees.

Two details decide how much work this is:

• updates are written cell by cell, and the loop only covers the eight values from toRow
• appends use the range A:H

So the automation never writes past column H, and it matches existing rows by the pull request url
in column B. A column to the right of H survives every run untouched.

The pull request template already requires an ## AI usage section, and #102 fails a run when that
section is absent, empty, or still the … placeholder. So the disclosure is enforced at the source,
and this sheet only has to record it.

The Change

Column I, written by the automation. Read the ## AI usage section from the pull request body
and record whether it holds a real disclosure. #102 parses the same section, so the two must share
one implementation rather than each growing their own.

Extend COLUMNS to I, add the value to toRow, and change the append range to A:I.

Column J, written by hand. A maintainer marks a disclosure they do not believe, for example
work that reads as generated under a statement that no AI was used. The automation leaves this
column alone, because it writes nothing past the values toRow produces.

Update docs/automation.md with both columns and who fills each.

Why not have rtibblesbot judge it

Detection of generated text is unreliable, and its errors fall hardest on people writing English as
a second language, who are a large share of our contributors. A wrong mark in a sheet the
contributor cannot see is one they can never correct.

If this is revisited, the judgment belongs on the pull request as a label, where it is visible,
contestable and reversible, and where the cron can read it from pulls.get with no new call. That
is a separate decision, and it waits on evidence that false declarations actually happen.

Out of Scope

• Detecting generated text automatically.
• Making the Check that pull requests follow the pull request template #102 check required in branch protection, which is the lever that makes disclosure
  genuinely mandatory. That is a repo setting.
• Changing which pull requests appear in the sheet.

Acceptance Criteria

• Column I records whether the pull request discloses AI usage, filled by the daily run.
• The parsing is shared with Check that pull requests follow the pull request template #102 rather than duplicated.
• Column J is left untouched by the daily run, on both updated and appended rows.
• The append range covers the new automated column.
• Tests cover a filled section, an empty section, and a missing section.
• docs/automation.md describes both columns and who fills each.

Testing

1. Put a value in column J on an existing row in the test sheet.
2. Run Update community pull requests spreadsheet against the test sheet. Expect column I to
   update, column J to survive, and the other columns to behave as before.
3. Make sure that a newly appended row fills A to I and leaves J empty.

References

• Check that pull requests follow the pull request template #102 enforces the pull request template, including the ## AI usage section. The parsing belongs
  there, and this issue consumes it.
• Group automation jobs by event and move the PR spreadsheet to a daily cron #101 moved the spreadsheet to a daily cron in this repo.

AI usage

I used Claude Code to check how the spreadsheet writer handles columns, which showed that a hand
filled column needs no code change, and to find the overlap with #102. I decided the split between
the recorded disclosure and the maintainer's own mark.