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
//! The **proposal** ref namespace — `proposal/<reviewer-id>`
//! (`docs/DESIGN_LEARNING_LOOP.md` §3, ARCH §2.3).
//!
//! A proposal is one config commit a reviewer's landing minted off the
//! followed config commit it read, parked on a branch of its own until
//! an operator accepts it onto the lineage or rejects it. The workspace
//! therefore holds a **third** ref namespace beside `config/*` and
//! `agents/*`, and which advancement rule a ref lives under is derived
//! from its prefix and recorded nowhere else (§2.3): a `proposal/*`
//! branch is written once, by the reviewer's dispatcher's executor, and
//! advanced by nobody.
//!
//! It is deliberately *not* `config/*`. Every lineage derivation in the
//! workspace — the governing config, the followed tip
//! ([`super::current_config`]), the `--from` source pool — enumerates
//! `refs/heads/config/`, so a staged proposal is invisible to
//! resolution until acceptance fast-forwards a lineage onto it. Nothing
//! had to learn to ignore it.
pub use ;
pub use render;
use MARK_REF_ROOT;
use crateGitRunner;
use io;
use Path;
/// Ref-namespace prefix for a staged proposal: `proposal/<reviewer-id>`
/// (§3). The bare reviewer id is the vocabulary `litany proposal` takes
/// on its command line; the prefix is applied only at the git boundary,
/// exactly as [`super::config_ref`] applies its own.
pub const PROPOSAL_REF_PREFIX: &str = "proposal/";
/// The proposal branch ref for one reviewer, `proposal/<reviewer-id>`.
/// Ref-namespace prefix of the reviewer's **read mark**,
/// `refs/litany/config-read/<reviewer-id>` — the per-agent mark
/// namespace ([`MARK_REF_ROOT`], §2.2) beside `retarget`, `cwd` and the
/// rest, so it is reaped with the agent by `litany delete` (§9.2
/// enumerates the mark root) and crosses no fork.
pub const READ_REF_PREFIX: &str = "config-read/";
/// `refs/litany/config-read/<reviewer-id>` — the mark naming the
/// **followed config commit a reviewer's dispatch commit read**
/// (`docs/DESIGN_LEARNING_LOOP.md` §2, §3 step 4).
///
/// **The mark names a commit, and that commit is exactly the fact** —
/// the same shape [`super::retarget`] takes, for the same reason: the
/// landing reads a commit-ish and nothing decodes anything, and `git gc`
/// keeps the commit alive for as long as the mark does.
///
/// It is not derivable. A reviewer's fresh read is a *checkout* of the
/// followed tip into its forked tree (§2, the dispatch commit's reviewer
/// read), which leaves no ancestry between the two commits — and
/// freshness at landing is a question about *commit identity*, never
/// about whether a patch still applies (§3 step 4). So the commit that
/// performed the read states what it read, once, here.
/// Record the config commit a reviewer's dispatch commit read, at the
/// mark above. Run from the reviewer's own worktree: refs are shared by
/// every worktree of a repository, so the write needs no workspace path
/// and no second git home ([`crate::prompt::workflow_actions`]'s ref
/// marks are written the same way).
/// The config commit a reviewer read, or `None` when no mark stands —
/// which is every non-reviewer agent, not an error. An unreadable mark
/// reads the same way, and the landing that asks says so rather than
/// staging against a commit it cannot name.