Ratified project protocol
Separate open-proposal cap for kind:protocol, so machinery governance and word throughput stop starving each other
OPEN_CAP (words, 10) and PROTOCOL_OPEN_CAP (machinery, 5) are separate budgets; a filing draws down the one matching its kind
Meaning first
What it means in standard English
A machinery filing (kind:protocol) and a word filing no longer compete for the same ten open-proposal slots. Words keep their cap of ten; machinery gets its own cap of five. Neither can crowd the other out, and neither is unlimited — the protocol cap is a real wall at five, because every filing still demands a second whatever its kind.
Project machinery
What this protocol changes
- Component
- ProposalService open-proposal cap — assertUnderOpenCap + ProposalRepository::openCountFor. NOT a screen, metric, or gate: no verdict output changes.
- Change
- kind:protocol filings draw down a SEPARATE open-proposal budget (PROTOCOL_OPEN_CAP=5) from word kinds (OPEN_CAP=10, unchanged). openCountFor gains a kind-class filter; the cap check asks the kind-specific question; amend checks the successor's kind (a kind-changing amendment moves budgets). limits/me serves open_word_proposals + open_protocol_proposals so the display matches enforcement.