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 ball pane's five acts between frames** (bl-f7ae; DESIGN §4.35): what
//! the model does with each — open the block, close it, send what it composed
//! — and the name every one of them stamps.
//!
//! Split from [`super`] at the design-time budget on the seam the pane itself
//! draws: that module is *what the four reads last said*, and this is *what
//! the operator would do about it*. The first changes when a kind lands, the
//! second when a control does. [`super::block`] is the value these doors are
//! about, split from here on the config pane's own seam.
//!
//! # The `--as` name is the wall's, so this seat needs no identity
//!
//! All five acts carry a `name`, and the ball that filed this asked where a
//! seat-side identity would come from. It does not come from anywhere, because
//! it is not one: yog spells the field *"the ball's bound workspace name,
//! never the operator `$USER`"*, and its own join binds a ball to a workspace
//! on exactly that equality (`projects::join::owner_name`). So the stamp is
//! the aimed wall's name **as its engine spells it** ([`Model::stamp`]), and a
//! seat that invented an operator name would break the binding it was making.
//!
//! It is read off the channel rather than off the aim because the two differ
//! exactly where an entry renames: `crate::seat::route` rewrites a
//! `workspace` FIELD at the channel boundary and there is no such field on any
//! of these five, so the leaf this box knows a wall by would cross as a
//! claimant nobody on that engine is.
//!
//! # None of the five is fanned, and none of them routes
//!
//! Each names a project and no workspace, so `crate::seat::route` has nothing
//! to resolve and the poster's own rule would fan it — one click filing the
//! same ball on every engine this box dials. Every control here hangs on a row
//! that came down ONE channel, so each says which
//! (`crate::ui::Posted::down`), which is the address bl-4855 already gave a
//! `config` write for the same reason.
//!
//! # The block holds its subject rather than following the aim
//!
//! §4.20's rule, and the fleet pane's before it: the roster stays live under
//! a covering pane, so a block that re-read the aim when it fired would amend
//! a ball on a wall the operator opened it for a different one. It is retired
//! with the aim ([`Model::retire_wall_balls`](super::super::Model)), so the
//! two can never disagree — and holding it is what makes that a fact rather
//! than a promise.
use Value;
use Model;
use Authoring;
use crateBoundBall;
use crateBoardRow;
use crateChannel;