Skip to content

Require posture on strand creation #544

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
flyingrobots wants to merge 7 commits into from
Closed

Require posture on strand creation #544

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
7 commits
Select commit Hold shift + click to select a range
1eacd38
Fix: require posture on strand creation
flyingrobots Jun 13, 2026
03a8f01
Fix: reject non-shared strand settlement
flyingrobots Jun 14, 2026
2164cc4
Fix: bind session posture derivation
flyingrobots Jun 14, 2026
dea5381
Fix: preserve settlement shell posture
flyingrobots Jun 14, 2026
334648c
Fix: update warp-wasm posture test fixtures
flyingrobots Jun 14, 2026
0c7ca74
Fix: map non-shared settlement ABI errors
flyingrobots Jun 14, 2026
a5c45a7
Fix: clarify settlement compare posture
flyingrobots Jun 14, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
18 changes: 18 additions & 0 deletions CHANGELOG.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -7,6 +7,12 @@

### Added

- `warp-core` strand creation now carries explicit `RetentionPosture` through
`ForkStrandRequest`, `ForkStrandReceipt`, and `Strand`. Session-default and
debugger fork constructors choose posture policy explicitly, session-default
work always records `PostureDerivation::SessionDefault`, debugger forks never
silently become `Shared`, and `StrandRegistry` rejects incoherent retained
posture such as `Shared` without an admission scope.
- `warp-core` import admission receipts now bind local source-shared import
admission to an explicit imported artifact identity. A receipt minted for one
imported artifact cannot admit another import into a local shared admission
Expand Down Expand Up @@ -545,6 +551,15 @@ Applied, Rejected, Obstructed}` with receipt evidence and typed contract

### Changed

- `warp-core` settlement planning now rejects non-`Shared` strands before
producing import candidates. Author-only/debugger strand suffixes can remain
real causal work, but they cannot enter base shared history without an
explicit shared admission posture. Settlement compare remains local
revelation/inspection only: it can inspect a locally held strand suffix
without promoting, planning, admitting, or settling it.
Comment on lines +554 to +559

@coderabbitai coderabbitai Bot Jun 14, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Tighten the compare boundary to local authority.

“Locally held strand suffix” is broader than the finalized compare doctrine and can be read as any locally present strand being inspectable. Say “held under local authority” so this entry doesn’t drift from the compare-vs-plan/settle split.

Suggested wording 
-  revelation/inspection only: it can inspect a locally held strand suffix
+  revelation/inspection only: it can inspect a strand suffix held under local authority
   without promoting, planning, admitting, or settling it.
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
- `warp-core` settlement planning now rejects non-`Shared` strands before
producing import candidates. Author-only/debugger strand suffixes can remain
real causal work, but they cannot enter base shared history without an
explicit shared admission posture. Settlement compare remains local
revelation/inspection only: it can inspect a locally held strand suffix
without promoting, planning, admitting, or settling it.
- `warp-core` settlement planning now rejects non-`Shared` strands before
producing import candidates. Author-only/debugger strand suffixes can remain
real causal work, but they cannot enter base shared history without an
explicit shared admission posture. Settlement compare remains local
revelation/inspection only: it can inspect a strand suffix held under local authority
without promoting, planning, admitting, or settling it.
🤖 Prompt for AI Agents 
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@CHANGELOG.md` around lines 554 - 559, The CHANGELOG entry uses the phrase
"locally held strand suffix" which is too broad and could be misinterpreted as
referring to any locally present strand. Replace "locally held strand suffix"
with "held under local authority" to more precisely reflect the compare
doctrine's actual boundary and clarify that the compare-vs-plan/settle split is
stricter than the current wording implies.

- `warp-core` settlement plural artifacts and retained braid shells now carry
the source strand posture instead of hard-coding author-only posture for
shared settlement records.
- Local determinism tooling now fails closed around
`scripts/check-warp-core-serialization-boundaries.sh`. The serialization
boundary guard is mandatory, runs through `bash` rather than executable mode,
Expand Down Expand Up @@ -617,6 +632,9 @@ Applied, Rejected, Obstructed}` with receipt evidence and typed contract

### Fixed

- `warp-wasm` settlement publication now maps non-`Shared` strand admission
rejection to the stable `INVALID_STRAND` ABI error code instead of
collapsing the lawful posture denial into `ENGINE_ERROR`.
- `echo-file-aperture` now normalizes `HostFileSnapshot` material at the
aperture boundary so caller-forged snapshot metadata or fingerprints cannot
bind a basis, observation receipt, or materialization verification to bytes
Expand Down
57 changes: 57 additions & 0 deletions backlog/cool-ideas/CI-003-append-only-braid-membership.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,57 @@
<!-- SPDX-License-Identifier: Apache-2.0 OR LicenseRef-MIND-UCAL-1.0 -->
<!-- © James Ross Ω FLYING•ROBOTS <https://github.com/flyingrobots> -->

# CI-003 — Append-Only Braid Membership

Legend: [WARP — Causal History]

## Idea

Model braids as append-only witnessed relationships over strand intervals,
not as binary pairings and not as permanent strand merges.

A braid can begin with multiple members and later weave additional strands
into the relation without pretending those strands were present from the
beginning:

```text
t0: braid B includes s0 and s1
t1: braid B weaves in s2
```

The source of truth should be a braid event log:

```text
BraidCreated { members: [s0, s1], ... }
BraidMemberWovenIn { member: s2, ... }
```

Materialized braid views can report current membership, but historical views
must preserve membership as of the requested coordinate.

## Why

1. **Doctrine:** Braided does not mean settled. Related does not mean admitted.
2. **Causality:** Weaving in `s2` at `t1` must not rewrite `t0` membership.
3. **Scale:** Real review/conflict/proposal workflows can involve more than
two strands.
4. **Posture:** A braid may reveal a shared projection or relationship summary
while sealed member source chains remain AuthorOnly.

## Acceptance Sketch

- Create braid `B` with `s0` and `s1` at `t0`.
- Weave `s2` into `B` at `t1`.
- Current braid view after `t1` includes `s0`, `s1`, and `s2`.
- Historical braid view before `t1` excludes `s2`.
- Braid membership changes are append-only events, not mutable list rewrites.
- A shared braid projection can reveal the relationship without revealing a
sealed member source chain.
- Settlement can admit a braid projection without collapsing member strands.
- Weaving in an AuthorOnly member requires authority or records a sealed
member reference.
Comment on lines +48 to +52

@coderabbitai coderabbitai Bot Jun 14, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Separate allowed weaving from sealed audit records.

The AuthorOnly bullet is ambiguous about whether an unauthorized weave is admitted or rejected and merely recorded. Those are different contracts; spell out the rejection path explicitly so implementers don’t treat a sealed reference as membership.

Suggested wording 
-  - Weaving in an AuthorOnly member requires authority or records a sealed
-    member reference.
+  - Weaving in an AuthorOnly member requires authority.
+  - Unauthorized weave attempts are rejected; any sealed member reference is
+    audit-only and does not change membership.
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
- A shared braid projection can reveal the relationship without revealing a
sealed member source chain.
- Settlement can admit a braid projection without collapsing member strands.
- Weaving in an AuthorOnly member requires authority or records a sealed
member reference.
- A shared braid projection can reveal the relationship without revealing a
sealed member source chain.
- Settlement can admit a braid projection without collapsing member strands.
- Weaving in an AuthorOnly member requires authority.
- Unauthorized weave attempts are rejected; any sealed member reference is
audit-only and does not change membership.
🤖 Prompt for AI Agents 
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@backlog/cool-ideas/CI-003-append-only-braid-membership.md` around lines 48 -
52, The AuthorOnly bullet point is ambiguous about the contract for unauthorized
weaving attempts—it does not clarify whether an unauthorized weave is rejected
outright or admitted but recorded as a sealed reference. Rewrite the AuthorOnly
bullet to explicitly separate these two distinct paths: clearly state what
happens when weaving with authority (the allowed case) and what happens when
weaving without authority (the rejection or sealed-audit-record case), so
implementers understand these are different guarantees and do not conflate a
sealed audit record with actual membership.


## Effort

Medium-Large — requires braid event types, interval/member views, revelation
policy around sealed members, and settlement/projection integration.
Loading
Loading