From 40b72e0e0abaccc860cb5dce48c6a4333bc01d38 Mon Sep 17 00:00:00 2001 From: Cosmin Staicu Date: Tue, 22 Sep 2026 08:52:12 +0300 Subject: [PATCH] chore: move the CLA signer procedure into signatures/README.md The /cla-add-signer command carried steps written down nowhere else: the legal-confirmation stop condition, legalRef being obtained rather than guessed, the case-insensitive duplicate check, JSON validation, never committing to main, and the instruction not to paste the CLA document or personal contact details into the PR. Those reach only maintainers who drive the repository through Claude Code. They are now numbered steps in signatures/README.md, next to the schema they refer to, and the command is removed. Its pointer went with it -- that pointer already named .claude/skills/, a path that does not exist. Nothing else referenced the command, and neither the CODEOWNERS gate on signatures/ nor cla.yml reading the registry depended on it. Also ignores .claude/worktrees/: sessions place throwaway checkouts there, and `git add -A` from the repository root otherwise commits a gitlink to one. Scoped to that directory rather than .claude/, so a command committed there later is not silently ignored. Signed-off-by: Cosmin Staicu --- .claude/commands/cla-add-signer.md | 39 ------------------------------ .gitignore | 3 +++ signatures/README.md | 33 ++++++++++++++++++------- 3 files changed, 27 insertions(+), 48 deletions(-) delete mode 100644 .claude/commands/cla-add-signer.md diff --git a/.claude/commands/cla-add-signer.md b/.claude/commands/cla-add-signer.md deleted file mode 100644 index 76385f10..00000000 --- a/.claude/commands/cla-add-signer.md +++ /dev/null @@ -1,39 +0,0 @@ ---- -description: Add a contributor to the CLA registry (signatures/cla.json) after legal has confirmed a signed CLA is on file. For CODEOWNERS/maintainers only. -argument-hint: ---- - -You are helping a **CODEOWNER/maintainer** record a contributor in the CLA registry -(`signatures/cla.json`). Adding an entry is what turns a `cla-required` pull request's -`legal/cla` check green, so treat this as a legal-record write: be precise and never -invent data. - -Target signer (GitHub username), if provided: **$1** - -## Hard prerequisite — confirm before doing anything -A registry entry means "UiPath legal has a valid signed CLA on file for this person/entity." -Ask the maintainer to confirm they have **verified with legal that the signed CLA is recorded** -(this is a manual, out-of-band step). If they cannot confirm, **stop** — do not add the entry. - -## Steps - -1. **Collect the entry fields.** Use `$1` as `githubUsername` if given; otherwise ask. Then gather the rest (ask via AskUserQuestion or prompt for any missing): - - `githubUsername` — the contributor's GitHub login (verify it exists, e.g. `gh api users/`). - - `type` — `individual` or `corporate`. - - `entity` — the person's name, or the company name for a corporate CLA. - - `legalRef` — the UiPath legal record reference for the signed CLA (required; ask legal/the maintainer for it). - - `date` — date the signed CLA was recorded, today's date in `YYYY-MM-DD` unless told otherwise. - - `note` — optional free text. - -2. **Update the registry.** Read `signatures/cla.json`. If `githubUsername` (case-insensitive) is already present, stop and report it's already recorded. Otherwise append the new entry to `signatories`, keep the file valid JSON and 2-space indented, and leave existing entries untouched. Validate it parses (`python -m json.tool signatures/cla.json` or equivalent). - -3. **Open a PR — never commit to `main` directly.** The `signatures/` path is CODEOWNERS-gated so the addition gets a second pair of eyes and an audit trail: - - Create a branch: `chore/cla-signer-`. - - Commit with sign-off (`git commit -s`); message e.g. `chore(cla): record signed CLA for ()`. - - Push and open a PR to `main`. In the PR body, state the legal reference and that legal confirmation was obtained. Do **not** paste the CLA document or personal contact details beyond what the schema needs. - -4. **Tell the maintainer the follow-up.** After this PR merges, the contributor's own `cla-required` pull request must re-evaluate against the updated registry — it does not happen automatically. Instruct them to **toggle the `cla-required` label off and back on** on that PR (or have the contributor push a commit) so `cla.yml` re-runs and `legal/cla` turns green. - -## Notes -- One entry per authorized GitHub username. For a corporate CLA covering several people, add one `type: corporate` entry per username, all referencing the same `entity`/`legalRef`. -- See `signatures/README.md` for the schema and `CONTRIBUTING.md` for the full flow. diff --git a/.gitignore b/.gitignore index 05a57cc3..a94f673b 100644 --- a/.gitignore +++ b/.gitignore @@ -255,3 +255,6 @@ BenchmarkDotNet.Artifacts/ # Local-only design notes (specs/plans); never committed docs/superpowers/ + +# Agent scratch worktrees +.claude/worktrees/ diff --git a/signatures/README.md b/signatures/README.md index 9d496e0e..951de6f4 100644 --- a/signatures/README.md +++ b/signatures/README.md @@ -32,15 +32,30 @@ that company's agreement (set `type: "corporate"` and the company name in `entit ## Adding a signatory -Entries are added **only after a CODEOWNER has verified with UiPath legal that the -signed CLA is on file.** Additions go through a pull request and are gated by -[`CODEOWNERS`](../.github/CODEOWNERS) on this directory, so they require maintainer -approval and leave an audit trail. - -Maintainers: use the `cla-add-signer` skill (in `.claude/skills/`) to do this, or -edit `cla.json` by hand following the schema above. After the addition merges, -re-trigger the contributor's `legal/cla` check (toggle the `cla-required` label off -and on, or have them push) so it re-evaluates against the updated registry. +An entry means "UiPath legal has a valid signed CLA on file for this person or entity", +and it is what turns a `cla-required` pull request's `legal/cla` check green. Treat it as +a legal-record write: be precise, and never fill a field with a guess. + +**Prerequisite.** Confirm out of band that legal has recorded the signed CLA, and obtain +the `legalRef` for it. Without that confirmation, stop — do not add the entry. This is the +one step nothing in the repository can check for you. + +For maintainers, in order: + +1. **Gather the fields** from the schema above. `legalRef` comes from legal, not from you; + `date` is the date the signed CLA was recorded. Verify the GitHub login exists + (`gh api users/`), since the check matches on it. +2. **Check it is not already there.** Match `githubUsername` case-insensitively — if it is + present, the contributor is already covered and there is nothing to add. +3. **Append to `signatories`** in `cla.json`, leaving existing entries untouched, and + confirm the file still parses (`python -m json.tool signatures/cla.json`). +4. **Open a pull request — never commit to `main`.** This directory is gated by + [`CODEOWNERS`](../.github/CODEOWNERS), so the addition gets a second pair of eyes and an + audit trail. Sign off the commit (`git commit -s`). In the PR body, state the legal + reference and that legal confirmation was obtained — **do not paste the CLA document or + personal contact details beyond what the schema needs.** +5. **Re-trigger the contributor's check** once the addition merges; it does not re-evaluate + on its own. Toggle the `cla-required` label off and back on, or have them push a commit. The CLA covers a contributor's present and future contributions, so a signatory stays in this file permanently (unless they change employer — see clause 5.3 of the