From 5b9cf667751b3da3c5c665df5c7c82f3f1f91d8b782ac034602200fc2194642a Mon Sep 17 00:00:00 2001 From: dkp Date: Wed, 26 Aug 2026 05:14:55 -0400 Subject: [PATCH] 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 --- 2026-08-26-dkp-a-structure-proposal.md | 129 +++++++++++++++++++++++++ 1 file changed, 129 insertions(+) create mode 100644 2026-08-26-dkp-a-structure-proposal.md diff --git a/2026-08-26-dkp-a-structure-proposal.md b/2026-08-26-dkp-a-structure-proposal.md new file mode 100644 index 0000000..ab3c930 --- /dev/null +++ b/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--.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.