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
//! **What a workspace routes to** — the provider table, and what one row is
//! offering (yog's `docs/REMOTE.md` §8.3; PROTOCOL 13).
//!
//! Three kinds in one module because they are one subject read three ways:
//! `providers` is brazen's ROUTING TABLE for this workspace — the rows the
//! operator named in config plus the built-in presets holding a credential
//! (brazen bl-6feb; lernie bl-67aa) — `catalog` is its SIGN-IN CATALOG, every
//! row `bz --login` can serve whether or not it is signed in (REMOTE §9.27;
//! bl-8c03), and `models` is what one row will answer to. A seat that filed
//! them apart would have split the provider in three. The two listings share
//! one row shape under two kinds, so they share one parser — [`row`] — and a
//! row can be in either without the other: an unsigned oauth preset is
//! catalog-only, a keyed row is table-only. The login pane renders the
//! catalog; every other "which rows exist" question stays on the table.
//!
//! # `blocked` is the whole of whether a row can be signed in to
//!
//! It is a sentence when the row cannot take a sign-in and absent when it can,
//! and the absence is the reading: nothing is wrong with this row. The seat
//! never composes that sentence — the server knows which auth model a row
//! declares and this end does not — so a control is offered off the option's
//! shape and the reason is painted in the server's own words.
//!
//! # `effort` and `priority` are CAPABILITIES, not settings
//!
//! They say whether this row takes the §9.4 tuning pair at all, which is a
//! different fact from what [`super::roles`] reports about a role. Upstream
//! states the division: *"it gates a control, never a write"*. So they belong
//! to the row rather than to any assignment, and the pane says what a row
//! takes rather than deciding anything with them.
//!
//! # What is NOT here is the flow a row serves
//!
//! yog's own `ProviderRow` carries a `device` column — the headless flow's
//! capability — and its rendered view does not, so the fact does not cross the
//! wire (REMOTE §8.3, bl-7c9f). This seat therefore cannot tell a
//! device-capable row from a browser-only one, and the pane says the loopback
//! remedy for **every** row on a workspace held elsewhere rather than guessing which
//! rows need it. A stated remedy that is sometimes unnecessary beats a silence
//! that is sometimes wrong.
use ;
use fields;
/// The kind token the table answers to.
pub const KIND: &str = "providers";
/// The kind token the sign-in catalog answers to — the table's row shape,
/// the other membership.
pub const CATALOG: &str = "catalog";
/// The kind token one row's offering answers to.
pub const MODELS: &str = "models";
/// One provider row, as this workspace resolves it.
/// The server's endings for a row that needs a credential and holds none: a
/// sign-in row's, then a keyed row's.
pub const BARE: = ;
/// The two capability words, in the order a row states them.
const EFFORT: &str = "effort";
const PRIORITY: &str = "priority";
/// One row, strictly. Every field is required except the block, whose absence
/// is the reading ([`super::fields`]).
pub
/// One model id, which is a bare string rather than an object: the listing has
/// exactly one fact per element and an envelope around it would be a field
/// nobody reads.
pub