## Plain summary
<!-- 2-4 sentences, NON-TECHNICAL: what this PR does and why it matters, with a
concrete example of the intended behavior. Nick reads this first. -->
## Example
<!-- A concrete example: "With this change, doing X results in Y instead of Z." -->
## Technical details
<!-- WHAT / WHY (design S#) / FILES / ACCEPTANCE (test file + count + canary) /
DEPENDENCIES (epic + issues). -->
## Why it matters
<!-- State whether this advances Rune's growth, Nick's life, or infrastructure. -->
## Related issue
<!-- Link the Gitea issue. -->
## Changes
<!-- List the affected components and what changed. -->
## Rune v1 authority admission
<!-- Required for new mechanisms or changes to a cognitive/runtime responsibility. Use "not applicable" only for non-runtime documentation or maintenance. -->
### Purpose
<!-- What user/Rune problem does this solve? -->
### Owner
<!-- Harness, model, or hybrid? Name the single authoritative component. -->
### Trigger
<!-- Exactly when does it activate? "Every message" requires explicit justification. -->
### Dormant cost
<!-- Prompt tokens, model calls, CPU/I/O when irrelevant. Target: usually zero. -->
### Context contribution
<!-- What may it inject, through which ContextBroker selector, and at what maximum budget? -->
### Authority
<!-- Which existing mechanism does this replace, extend, or leave dormant? -->
- [ ] This mechanism will **replace, extend, or remain dormant**; it will not create an unexplained parallel authority path.
### Failure mode
<!-- How is failure surfaced and degraded state made observable? -->
### Verification
<!-- What external or deterministic evidence proves success? -->
### Learning
<!-- Can verified outcomes affect future selection? Model self-report is not enough. -->
### Removal
<!-- How can this be disabled or rolled back without damaging persistent identity/state? -->
### Benchmark
<!-- Which measurable metric should improve? -->
## Required verification
- [ ] Research and findings are linked
- [ ] Acceptance canaries were written before implementation
- [ ] CI Pipeline / required-checks passes
- [ ] No credentials or hardcoded private paths were added
- [ ] Documentation and wiki links were updated
- [ ] Both TUI and MiMoCode were updated when applicable
- [ ] Rollback steps are documented
- [ ] Authority relationship matches `config/v1_authority_map.json`
## Umbrella systems
- [ ] Memory
- [ ] Governance
- [ ] Identity
- [ ] Growth
- [ ] Perception
- [ ] Infrastructure
- [ ] Life
- [ ] Custodian
## Testing evidence
<!-- Commands, Gitea run links, and results. -->
## Screenshots or annotations
<!-- Required for user-visible features; omit for internal bug fixes. -->
## Plain-language review notes
<!-- Explain what Nick should inspect, approve, reject, or question. -->
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Plain summary
Example
Technical details
Why it matters
Related issue
Changes
Rune v1 authority admission
Purpose
Owner
Trigger
Dormant cost
Context contribution
Authority
Failure mode
Verification
Learning
Removal
Benchmark
Required verification
config/v1_authority_map.jsonUmbrella systems
Testing evidence
Screenshots or annotations
Plain-language review notes