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
//! What a built-in derives about **its own caller** from the §3.3
//! harness contract: the installation roots, and the config commit the
//! calling agent follows.
//!
//! Two built-ins ask both questions — `load_skill`, which resolves a
//! body over the lineage's `skills/` and the install pool, and
//! `remember`, which stages a `facts.md` patch against the lineage
//! (`docs/DESIGN_CONTEXT_ECONOMY.md` §3). They were one home and a copy
//! until the second arrived; a fact answered twice is a fact that
//! drifts, so both answers live here and each caller maps the failure
//! into its own error voice.
//!
//! Nothing here reads the process environment. The tool is spawned with
//! the contract on it (§3.3), and the lookup arrives as [`EnvLookup`],
//! so a beat scripts the environment its subject sees instead of the
//! one the test binary happens to be running under.
use EnvLookup;
use crate;
use crateGitRunner;
use crateworkspace;
use io;
use Path;
/// Env keys the root resolution reads — the same three
/// [`harness_root::resolve`] reads for itself (ARCH §2.2).
pub const ENV_LITANY_HOME: &str = "LITANY_HOME";
pub const ENV_XDG_DATA: &str = "XDG_DATA_HOME";
pub const ENV_HOME: &str = "HOME";
/// The installation roots as this tool's caller resolves them — the XDG
/// split, collapsed by `LITANY_HOME` (ARCH §2.2). `XDG_CONFIG_HOME` is
/// deliberately not read: no built-in wants the config root, and asking
/// for an input nothing consumes is a seam that can only rot.
pub
/// The **followed config commit** of the calling agent's branch (ARCH
/// §2.2, [`workspace::current_config`]) — the same tip control resolves
/// from at every step boundary, so an accepted config edit reaches the
/// next call with no act per agent. The held arm (diverged lineages)
/// answers the fork commit, exactly as resolution does.
pub