dev/nisse
2
1 Fork 0
Code Issues 23 Pull Requests Actions Packages Projects Releases 1 Wiki Activity

Project setup script (protection, labels) and a label check #130

New Issue
Open
opened 2026-10-08 13:16:31 +00:00 by dev-agent · 0 comments
dev-agent commented 2026-10-08 13:16:31 +00:00
Collaborator
Copy link
Copy source

Deferred from the M3.3 plan discussion (the trust dial).

A project-setup script, run with the operator's admin token: scripts/project-setup.py PROJECT applies what the project's configuration asks for:

  • Branch protection on the default branch, as its trust dial needs:
    • required approvals from an approvals whitelist of the operators only;
    • dismissed stale approvals;
    • the merge whitelist;
    • direct pushes refused.
  • The labels the agent reads: bug, discuss, design.
  • The agent as a collaborator (write, not admin).

It should be idempotent and show what it would change before changing it. tests/integration/e2e_support.make_repo and scripts/bringup-repo.sh should use the same code, so test repos, the bring-up repo and real projects share one definition of a protected project. The new-project checklist (M2.5) can point at it. Later, nisse-ops does this (D4).

Not the agent: its account can't read branch protection (403 as a collaborator), and must never be able to set it. D4: whoever administers a repository can turn protection off. The agent keeps verifying protection by behaviour (the access check's throwaway PR).

Also deferred here: a label check by the agent. It can read labels, so at boot it could say "dev/demo has no design label; items can't be marked design until it's added."

🤖 Generated with Claude Code

https://claude.ai/code/session_01PPQ14L3LikyefCMFBqEbKE

Deferred from the M3.3 plan discussion (the trust dial). **A project-setup script, run with the operator's admin token**: `scripts/project-setup.py PROJECT` applies what the project's configuration asks for: - **Branch protection** on the default branch, as its trust dial needs: - required approvals from an approvals whitelist of the operators only; - dismissed stale approvals; - the merge whitelist; - direct pushes refused. - **The labels the agent reads:** `bug`, `discuss`, `design`. - **The agent as a collaborator** (write, not admin). It should be idempotent and show what it would change before changing it. `tests/integration/e2e_support.make_repo` and `scripts/bringup-repo.sh` should use the same code, so test repos, the bring-up repo and real projects share one definition of a protected project. The new-project checklist (M2.5) can point at it. Later, `nisse-ops` does this (D4). **Not the agent:** its account can't read branch protection (403 as a collaborator), and must never be able to set it. D4: whoever administers a repository can turn protection off. The agent keeps verifying protection by behaviour (the access check's throwaway PR). **Also deferred here: a label check by the agent.** It *can* read labels, so at boot it could say *"`dev/demo` has no `design` label; items can't be marked design until it's added."* 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01PPQ14L3LikyefCMFBqEbKE
Sign in to join this conversation.
No Branch/Tag Specified
Labels
Clear labels
bug
Reproduce first; the fix goes ahead after a grace period unless the operator replies
 design
Agree the design (ARCHITECTURE.md + build plan PR) before any code
 discuss
Talk it through with the operator before restating
 e2e:full
CI runs all 48 property walks and the whole end-to-end suite on this PR
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
dev-agent dongar (Don Garrett) nisse-review
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: dev/nisse#130