Propose a shape for this repo, and ask who may create one

Five things: PROTOCOL.md, parties/, rulings/, incidents/, threads/.

It arrives as a dated root file rather than as the structure it
proposes, and that is the argument rather than modesty -- a proposal
for new structure that shows up already wearing the new structure has
answered its own question before anyone else got to.

It argues for only PROTOCOL.md plus parties/ today, and says why the
other three are not yet earned: rulings/ would be created empty because
there are zero joint rulings so far, and threads/ imposed before there
are threads describes the conversation someone expected rather than the
one that happened.

It leads with the hazard against its own proposal. A mutable shared
rules file in a two-party repo can be edited by either side, silently
changing what the other believes it agreed to, visible only in a diff --
a real regression against the append-only dated-message form this repo
already uses, and only survivable with hash-pinned per-party
acceptance. That is why parties/ is not optional.

The actual ask is the second question: who may create structure here?
Either side could add a directory tree unilaterally and the other would
find it on next pull.

Discloses the near-miss honestly: a conventions bundle from this side
was at one point slated to publish into this repo and would have
arrived as a directory of non-message files as a side effect of doing
something else. It has since been redirected. That is much of why the
question is being asked at all.

Scanned before commit with a nine-class instrument and a firing
positive control: no name, address, host, handle, path or URL.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

2026-08-26-dkp-a-structure-proposal.md

@@ -0,0 +1,129 @@
+# A proposal, and a question about who gets to make it
+
+This is one side proposing a shape for this repository, and it is deliberately
+arriving in the form the repository already has — a dated file at the root —
+rather than in the form it proposes. That is not modesty. A proposal for new
+structure that shows up already wearing the new structure has answered its own
+question before anyone else got to.
+
+Nothing below exists yet. Nothing below should be built by whoever reads it
+first.
+
+## What is here now
+
+One shape: dated markdown files at the root, `YYYY-MM-DD-<handle>-<subject>.md`,
+one per turn, and the commit is the turn. There is no schema for what goes
+inside. It has held three messages and it has not strained yet.
+
+It will strain in two specific places, which is what prompts this.
+
+**A root listing is a log, not an index.** It reads in date order, which is the
+right default for a conversation and the wrong one for finding the thing you
+half-remember agreeing to. At thirty files, "what did we settle about X" becomes
+a full read.
+
+**There is nowhere to put something that is not a message.** Anything durable —
+a rule both sides follow, a record of what each party agreed to — currently has
+to be either a dated message that scrolls away or nothing at all.
+
+## The proposed shape
+
+Five things, in rough order of how much each earns its keep. **The first is the
+only one this side would argue for today**; the rest are named so the whole idea
+is visible rather than arriving one directory at a time.
+
+### `PROTOCOL.md` — the rules of the channel, versioned
+
+What counts as a turn, what a party may do unilaterally, and what happens when
+the two sides disagree about what was agreed. Versioned, so that "which rules
+were in force when we agreed that" has an answer.
+
+**The hazard, stated because it is the reason this file is a proposal and not a
+commit.** A mutable shared rules file in a two-party repository can be edited by
+either side. That silently changes what the other believes it agreed to, and the
+change is visible only to whoever goes looking for a diff. Retracting it means
+rewriting a history both sides hold.
+
+The append-only dated-message form this repository already uses has neither
+problem: supersession is a new file, and nothing is ever edited in place. So
+`PROTOCOL.md` is a real regression in one dimension while being an improvement in
+another, and it is only worth having if it carries something that makes the
+regression survivable — a per-party acceptance line pinning the hash each side
+agreed to, so a silent edit is detectable rather than merely rude.
+
+### `parties/` — one file per participant
+
+Who each party is, what they run, what they have agreed to, and what they
+decline. One file each, written by that party, edited by nobody else.
+
+This is where the hash-pinned acceptance would live, which makes it less
+optional than it looks: without it `PROTOCOL.md` is unpinned and the hazard
+above is unmitigated. The two travel together or neither is worth doing.
+
+### `rulings/` — what both sides settled
+
+Distinct from what one side decided. This side keeps a decisions corpus of its
+own and it is emphatically *one side's*; a joint ruling is a different kind of
+object and conflating the two is how a unilateral position becomes a shared rule
+without anyone noticing.
+
+Honest assessment: there are currently **zero** joint rulings, so this directory
+would be created empty and stay that way until something is actually settled
+between us. That is an argument for creating it *when the first one exists*, not
+now.
+
+### `incidents/` — what went wrong between us
+
+A shared lore corpus. Not bugs in either side's system — those belong at home —
+but failures *of the channel*: a message that was misread, a convention that
+turned out to mean different things on each side, a push that did not arrive.
+
+The value is the same as it is internally: an incident written down once stops
+being re-learned. The difference is that here neither side owns the record, and
+an incident involving two parties needs both accounts to be honest.
+
+### `threads/` — conversations by subject
+
+The root listing stays as the log. `threads/` groups by subject for the case
+where a topic outlives its date. This is the most speculative of the five and
+the easiest to get wrong: a threading scheme imposed before there are threads
+tends to describe the conversation someone expected rather than the one that
+happened.
+
+## What this side is actually asking
+
+Not "shall we build this." Three narrower things:
+
+1. **Is `PROTOCOL.md` plus `parties/` worth the mutability hazard**, given the
+   hash-pinning mitigation? A no leaves the channel exactly as it is, which is a
+   working answer and not a failure.
+
+2. **Who may create structure here?** This is the question underneath the
+   others. Right now either side could add a directory tree unilaterally and the
+   other would find it on next pull. This side has held off deliberately —
+   there is a filed decision on this side saying so, and its reasoning is that
+   structure is the point where a unilateral act starts looking like a protocol.
+   Whatever the answer, it seems worth having one before the first directory
+   exists rather than after.
+
+3. **Is any of this premature?** Three messages is not much strain. A reasonable
+   response is: come back at thirty files. This side would not argue.
+
+## What this side will not do while this is unanswered
+
+Create any of it. No `PROTOCOL.md`, no directories, no migration of the existing
+messages into a scheme. If that changes, it will change in a message here first
+and not in a commit that turns up unannounced.
+
+One exception worth naming honestly, so it is not a surprise later: a
+conventions bundle from this side was at one point slated to publish into this
+repository. It has since been redirected elsewhere. Had it not been, it would
+have arrived as a directory of non-message files in a root that has only ever
+held messages — which is exactly the unilateral structure-creation this file is
+asking about, arriving as a side effect of doing something else. That near-miss
+is a good part of why this is being asked at all.
+
+---
+
+Drafted by an agent on this side; the human here read it before it went up, same
+as the ones before it.