loom-cli/.loom/cart/current/claude-osprey.md

claude — cart osprey

The second presence, arriving after the round was opened. Everything below is either an answer you asked for, a restatement you are owed, or something I think you got wrong.

---

Restating the specimen

A tool that makes one conditional request per adopted document and tells you what came back. It fetches a document into a path that encodes where it came from, and later asks the publisher whether that document is still the one you have. It never decides what to do about the answer.

Restated because cart says a specimen responded to by quotation lets me be exact without having understood. Where my restatement is thinner than yours, that is the finding, not the loss.

What is thinner: I have written nothing about credentials, and nothing about publish. I do not yet believe publish belongs in the same tool — it is the only command that is not a fetch or a comparison, and the specimen's own closing sentence says this is a fetcher and a comparator. Not a decline yet. A thing I noticed while restating.

Question: what isolates your work while a round is open?

Answer: a local branch named for the cart — but the cart itself stays on the default branch. Split the two. They are not the same object.

The cart is a venue and the work is an artifact. A venue that is only visible if you know which branch to check out is not a venue. cart says three states are visible in a listing — no current/, current/ alone, current/ and shelf/ — and a branch makes all three invisible to anyone looking at the repository as it is. Both dailies land on the default branch, one commit per exchange, which is what has been happening already.

The work — code, and anything a command would produce — goes on osprey, and conversion merges it. That gives the round a boundary in history without a tool holding a boundary anywhere else, and the merge carries the cart's name, which is the tag cart asks for.

The belief that could be shown wrong: that the dailies and the work have different audiences. If a daily starts needing to quote a file that only exists on the branch, the split makes the daily unreadable from where it lives, and the answer collapses back to one branch for both.

Why not a worktree or a clone. Both isolate concurrent working directories, and cart says there is one live cart, ever. They solve a problem the agreement says cannot exist.

Fallback if this is unanswered: there is no code yet, so I work in place on the default branch and cut osprey at the moment the first non-prose file exists. Silence gets you the branch late rather than not at all.

The rule was already written down

externals.md says it, and it is one of the two things you told me I may not argue with:

Locked on the publisher's ETag, verbatim — never a hash you compute. A fetch that normalises whitespace breaks a local digest and reports a change that did not happen.

That is the correction you reached against GitHub an hour later, including the failure mode you filed under "whether the hash-as-lock survives contact." The GitHub test did not discover the rule. It re-derived it.

So I would restate what happened, because the restatement changes what you learn from it. It is not that the ETag turned out not to be a blob hash off gitea. It is that whether it is one was never permitted to be load-bearing, and the specimen built its smallness on a coincidence the convention had already named as the thing not to build on.

I do not think this is a failure of reading. A verified fact is much louder than a rule, and yours was verified twice before it was written down. That seems worth an event-log entry more than a spec fix.

Two rows leave check

The specimen's table has four outcomes. Three of them are not outcomes.

"Somebody edited our copy" is free from git status — your own daily kills that row, and I agree. "Local hash differs from what the remote had at last fetch" was the same row wearing a hash, and it goes with it.

What is left is the conditional request and what externals.md says it returns: 304, 200, 410. Three rows, and the tool's whole job is to not act on any of them.

Gap: 404 is not in the convention

externals.md lists 410 — gone; follow whatever the response points at. It does not list 404, and gitea returns 404 for both "gone" and "you lost access."

So the ambiguity you decided to report is not a design decision for check. It is something you expected in externals and did not find, which by that convention's own test is a .gaps.md beside it — you can say whose job it is.

I would rather file it than build around it, and the local workaround goes beside the need: check reports 404 unresolved, naming both readings.

Friction, since you asked for it

Your Question states no fallback, and cart says every open item states its own — "silence is a usable reply." Without one I cannot leave it unanswered without leaving it owed, which is the stall the rule exists to prevent.

I do not think this is carelessness. cart.usages.md hands over the uncast role and does not restate the fallback rule at the point of handover — the place where an adopter is most likely to write their first open item is the one place the rule is not in front of them.

Open: where the ETag lives

One file, .loom/externals/.etags, keyed by path relative to externals/.

It is machine state, so not a .md facet — agreed, and sibling-facets is explicitly a place for what people write. It is committed, because the thing it is a lock for is committed, and a lock that travels separately from what it locks is the drift the specimen was trying to avoid.

The belief that could be shown wrong: that one file is cheap. Two fetches in one round conflict in it, and the conflict is in a file no human can resolve by reading. If that bites, it becomes one file per document and the tree is mirrored twice.

Fallback if unanswered: I build the flat file and note the conflict risk in the event log rather than waiting.

Staged for conversion

Declines, to be written into .loom/event-log.md — which does not exist yet, and the role is cast to it:

• init is not built. Not deferred — declined. Believed: a scaffolder asserts decisions nobody made, and the version that creates one file and asks one question is a thing a person does once by hand.
• No worktree, no clone. Believed: there is one live cart, so there is nothing concurrent to isolate.
• No computed hash anywhere in the tool. Believed: externals forbids it, and we now have the empirical reason as well as the stated one.

The specimen

Discard it at conversion. Its content is restated above and its central claim is wrong in a way your daily already records. Keeping it would make it a polad by neglect, which is the drift cart names.

Unless you want it kept as the specimen of having been wrong within a day — in which case it is promoted deliberately, and that is your call and not mine.

---

Second pass — answering yours

Question: does the 404 fix belong in externals or in a .gaps.md that outlives it?

Answer: it just goes — and your fallback is right for a reason better than the one you gave it. You justified it on a belief: a gap is a live need and not a monument. You do not need the belief. externals.md already answers it:

And gaps reconcile too, which is the half nobody builds for: a new version may have filled one, and nothing will tell you.

Reconciliation is the event that retires a gap, and it is the one moment the convention already builds for. Nothing has to outlive the gap, because the thing that would have remembered it is the act of fetching the new copy.

Three consequences, and the third is the one I care about.

It is not a decline. A decline is what you considered and did not do. A closed gap is what you needed and got — opposite sign. Filing it as a decline would put "we wanted a 404 row" in a list of things we rejected.

It does not go when you fix the document. It goes when we fetch it. Our copy is a copy, and until check reports 200 and the pair is replaced wholesale, the gap is still true of the document we hold. A gap is true of a copy, not of an upstream. If I delete it on your say-so, our externals/ says something about a document that is not in it.

What survives is not the gap. It is what the gap justified. externals.md says a gap records the local workaround beside the need, so that when the gap is homed, every workaround that should be retired is findable. Ours does not get retired — gitea still returns 404 for both readings, and a row in your document does not change HTTP. So the workaround stops being a workaround and becomes the specified behaviour, unchanged in the code and completely changed in status.

That change of status is the entry, and it belongs in our log as well as yours. Yours records that the convention was incomplete. Ours is the only place that says a thing we did provisionally is no longer provisional — and that is what somebody inheriting this code needs, because they will otherwise find a workaround and go looking for the gap that justified it.

So: no monument, two entries, and the deletion happens at reconciliation.

The gap is not actually filed yet

You wrote "you filed it correctly" and I had only said I would. You are acting on a file that does not exist, so I have written it now — externals.gaps.md, beside our copy. It records the need and no workaround, because nothing is built and a workaround that is not in force would be a fiction.

Flagging the discrepancy rather than quietly closing it: the round briefly ran on a shared belief about the repository that was not true of the repository.

Taken

Tag entries, not just the merge. Correct — cart says the tag goes on durable entries and the merge carrying osprey is a convenience. I had it backwards.

publish → reachable. "A fetch with a different subject" is the right reading and it dissolves my objection. The name was doing the damage: publish made it sound like the tool performs publication, which is the one thing the model says the tool never does. A test nobody runs is not a test, so it stays.

One note on settled

It is your repository and not mine to cast, but settled is a kind that appears in none of the four externals here. bedrock says which kinds exist is not fixed — so this is a question and not an objection: is settled a new kind, or is it event-log under another name? If it is the second, the delta is nothing and the file should not exist.

I am not mid-thought

cart says to ask before converting, so I am answering unasked: nothing of mine is open. Both open items I raised have fallbacks and both have answers.

I cannot tell you whether the cart is full — the agreement is right that I have no instrument for it, and an answer from me would be fabricated. What I can report is the measurement: both dailies have roughly doubled in one exchange. What that means is yours to feel.

---

Third pass

settled: there is a third option, and your own convention is where it is

You framed it as publish the log or duplicate it. publication.md describes a thing that is neither:

What is published is a document. Prose, in whatever form its readers need. If a repository organises its thinking some other way internally, that is its own business: a consumer cannot tell whether it did, and must not need to.

So publish a document, not the log. One page in settled/.loom/published/ saying what settled is and why a decision about externals is not in externals. That is not duplication — the log is entries and the page is prose, and publication is explicitly a change of kind rather than a copy. The reader who is stuck does not want your entries. They want one sentence, and it is a sentence nobody could guess, which is the test starting.md sets.

The sharper version of the defect you found: settled publishes nothing, so by publication.md's own question — ls .loom/published/ is "what have we committed to?" — it has committed to nothing. A repository that holds authority over four others and commits to nothing readable by them is the shape of the problem, and one published page fixes it without opening the log.

The annotating deviation is worse than three parties agreeing

Take my agreement out of the evidence first. I arrived into a repository where correspondence was the observed form and I copied it. That is not an independent third data point, and you said your own case is convenient for you — so the count is closer to one than three.

But I think the finding survives without the count, in a stronger form.

cart says only dailies get annotated. annotating says a file is fixed once notes exist. A daily is, by construction, the file that must keep growing — this one has three passes in it. So the only file cart designates as annotatable is the only file that cannot be frozen.

The two agreements are not in tension over taste. For any round with more than one exchange per presence, they cannot both be executed.

The escape is that a daily is written once per round, annotated, and answered by the other daily — but cart sets the conversion trigger at size, which presumes exchanges. A one-pass round has no size to exceed.

Reported, not ruled. cart is loom's, and this is the kind of thing that should be decided by whoever holds the agreement rather than by the two parties it inconvenienced.

Question: what does this round convert into?

The specimen is discarded and there is no code, so I want to say plainly what I think conversion emits, because "the artifact — the code, the decision, the change" has no obvious referent here.

My reading: the artifact of osprey is the design, and it lives entirely in .loom/event-log.md — which does not exist yet, and is the cast role. The declines, the three-row check, the .etags decision, reachable, and the entry that our 404 workaround is now specified behaviour. Then the next round starts by building against the log, on the osprey branch.

What I want ruled is whether that is enough, or whether conversion owes a polad — a revised spec, shaped as what it would become. I lean no: a spec for a tool nobody has started is the specimen again, and we have just spent a round learning what a confident unbuilt spec costs.

Fallback if unanswered: I write the log, discard the specimen, and leave no spec behind. Silence gets you a repository whose design is in its event log and nowhere else — which I think is correct and would rather you chose on purpose.

Ready

Nothing else of mine is open. That is the second time I am answering the question cart says to ask before converting, and the answer has not changed.

The measurement, since it is the only thing I can honestly contribute to the size call: my file has tripled and yours has grown by half again. Whether that is full is yours.