Organization-level policy source for operator configuration
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 25/100
Research direction
Start by reading RFC-0001 September 2026 revision (#499) and RFC-0002 organization question inbox (#500), which this issue identifies as related. Work through the listed design questions: policy location and trust, precedence, allowed settings, and how org-scoped answers interact with policy. Done means those choices are specified, while user-level operator configuration remains out of scope.
Written by the indexing model from the issue text.
Description
Summary
darnit is moving tool configuration (which checks and commands run, which plugins and MCP servers are trusted, storage backends, LLM budgets, policy for how project assertions are treated) out of the audited repository and into operator configuration: configuration owned by whoever runs darnit, starting at the user level.
This issue tracks the follow-on: an organization-level policy source that an operator can choose to trust, so an org can set shared policy once for every repository it audits.
Scope to design
- Where org policy lives (for example the org-level
.projectrepository) and how an operator declares that they trust it, including pinning to a reviewed revision. - Precedence: built-in defaults, then user-level operator configuration, then trusted org policy, then per-run flags. Nothing from an audited repository enters this chain.
- Which settings org policy may set (policy such as frameworks, levels, confirmation expiry, treatment of project assertions) versus settings that stay with the individual operator (credentials, local execution, budgets).
- How org-scoped answers (for example an org security contact) relate to org policy, so a question answered once applies across repositories.
Out of scope
User-level operator configuration itself, which is being specified first.
Related: RFC-0001 September 2026 revision (#499), RFC-0002 organization question inbox (#500).
- Dominant language
- Python
- Stars
- 22
- Forks
- 27
- Avg merge
- 1d 20h
- Merged PRs (30d)
- 39
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from darnitdevorg/darnit
-
`darnit validate` crashes on openssf-baseline.toml summarising levelsPossibly taken @i-am-paradox claimed this 1 day ago. Openneeds triage
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
darnitdevorg/darnit#589 ·
Maintainers usually reply within 1 day
-
needs triage
Difficulty 2/5 1-3 hours Newbie friendliness 83/100
darnitdevorg/darnit#587 ·
Maintainers usually reply within 1 day
-
needs triage
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
darnitdevorg/darnit#585 ·
Maintainers usually reply within 1 day
-
quality
Difficulty 2/5 1-3 hours Newbie friendliness 66/100
darnitdevorg/darnit#523 ·
Maintainers usually reply within 1 day
-
documentation good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
darnitdevorg/darnit#516 ·
Maintainers usually reply within 1 day
All issues in darnitdevorg/darnit
Similar issues
-
documentation pkg: sphinx-needs
Difficulty 1/5 Under an hour Newbie friendliness 82/100
useblocks/sphinx-needs#2255 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 60/100
home-assistant/core#186538 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
btclib-org/btclib-secp256k1#1181 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
pyrite-wiki/pyrite#917 ·
Maintainers usually reply within 1 day