1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
//! Assemble the model-facing wire history from the branch's worktree
//! (ARCH §2.3, §5).
//!
//! Context assembly has exactly one input: the read-state commit's tree
//! (§5.1), materialized as the branch's worktree. [`assemble`] composes
//! the §5.5 parts that ride the message array, in order:
//!
//! 1. **Head and body** ([`body`], §5.2): the manifest role's `pinned`
//! extras and `order` categories, budgeted, as path-framed user-side
//! text blocks. (The pinned files with structural wire homes —
//! `goal.md`, `name` and `soul.md` in the system slot, §2.3; tool
//! schemas and
//! the skill descriptions their tools claim in the tools array,
//! §3.3 — compose through those homes, not here; the standalone
//! skill descriptions no tool claims compose as head blocks.)
//! 2. **Transcript tail** (§2.3): `messages/` sorted by the filename's
//! `NNN` prefix — order lives in the name, no git-log walk and no
//! index — each entry composed by its origin token:
//! - `NNN-<sender>.md` — a delivered message (§2.11): user-role text.
//! - `NNN-<model-id>.json` — one step's model output: the canonical
//! [`Content`] blocks verbatim, as an assistant-role message. The
//! origin token names the model that authored the entry (§2.3,
//! §4.3); any token but the reserved `tool` composes
//! assistant-side.
//! - `NNN-tool.json` — one tool call's `tool_result` block(s):
//! user-role content in the following wire message.
//!
//! Consecutive same-side entries group into one alternating wire
//! message, so every `tool_use` block is matched by a `tool_result` in
//! the immediately following user message *by construction* (§2.3, §2.5
//! pairing). Running, retry, and replay all call this one function
//! against one input — a commit's tree — so "replay" is not a mode
//! (§2.3 *Crash and recovery*). [`transcript`] composes part 2 alone —
//! the §6 warrant derivation reads the transcript tail and must not see
//! body material (and must stay config-free for lazy resolution).
use entry;
use crateRoleRules;
use crateError;
use ;
use ;
/// Branch-scoped transcript directory (ARCH §2.3 — `messages/NNN-…`).
const MESSAGES_DIR: &str = "messages";
/// The one reserved `.json` origin token (§2.3): a `tool` entry composes
/// tool-side as `tool_result` content — canonical [`Role::Tool`], which
/// each brazen protocol projects into its own dialect (the anthropic
/// projection folds it into a `"user"` message; ollama/openai fan it out
/// to `role:"tool"` messages). Every other `.json` token is a model id
/// and composes assistant-side; every `.md` sender composes user-side.
const TOOL_ORIGIN: &str = "tool";
/// Which wire side an entry composes onto (§2.3). Grouping is by side,
/// not by [`Role`], so the enum can derive `PartialEq` without leaning
/// on brazen's type.
/// Assemble the full §5.2/§5.5 wire message history: the manifest
/// role's head-and-body blocks ([`body`]), then the transcript tail.
/// `rules` is the role's manifest entry from the governing config
/// commit (§2.2); a role the manifest does not list assembles
/// transcript-only — the general path with empty inputs, not a special
/// case.
pub
/// Assemble the transcript tail alone (§2.3): the §6 warrant derivation
/// reads only the tail's wire side, before any config is resolved, so
/// head/body material must not lead the history it inspects.
pub
/// Append the wire messages of the transcript under
/// `<worktree>/messages/` (ARCH §2.3, §5). An absent or empty directory
/// appends nothing — the general path with empty inputs, not a
/// bootstrap special case.
/// The `NNN` counter of a `messages/NNN-<origin>.<ext>` path (the prefix
/// before the first `-`). A non-conforming name contributes no entry.
/// Compose one transcript entry into its wire `(side, content)`
/// (ARCH §2.3 *Origins and wire framing*). Role framing is derived from
/// the path — the extension and origin token — never from frontmatter.
/// A `.json` entry composes tool-side (a `tool_result`) iff its origin
/// token is the reserved `tool` (§2.3); every other token is a model id
/// (the entry's author) and composes assistant-side as model output. The
/// origin token is the stem past its `NNN-` counter prefix — model ids
/// carry hyphens (`claude-fable-5`), so the split keeps everything after
/// the first.
/// Append `content` to the trailing message when it is the same side,
/// else start a new message (ARCH §2.3 — consecutive same-side entries
/// group into one alternating wire message).