@@ -7,191 +7,336 @@ Questions 16 to 28 are language or spec rulings. Under the ground rules they are
7## Scope and process
7## Scope and process
9**1. Where should the review land?** It is on `claude/project-thread-7prdcx` now.
9**1. Where should the review land?** It is on `claude/project-thread-7prdcx` now.
10−a) Push it to `master`, as development.md's "push straight to master" rule says. b) Open a pull request. c) Leave it on the branch.
11+- a) Push it to `master`, as development.md's "push straight to master" rule says.
12+- b) Open a pull request.
13+- c) Leave it on the branch.
11−Answer: a
15+**Answer:** a
13**2. What should be done first?**
17**2. What should be done first?**
19+- a) The eight "fix first" bugs.
14−a) The eight "fix first" bugs. b) The simplifications, starting with the test runner. c) The docs cleanup. d) Nothing more for now.
20+- b) The simplifications, starting with the test runner.
21+- c) The docs cleanup.
22+- d) Nothing more for now.
15−Answer: a, then c
24+**Answer:** a, then c
17**3. How should fixes land?**
26**3. How should fixes land?**
18−a) Commits straight to `master` once every check passes, as development.md says. b) One pull request per theme. c) A branch you merge yourself.
28+- a) Commits straight to `master` once every check passes, as development.md says.
29+- b) One pull request per theme.
30+- c) A branch you merge yourself.
19−Answer: a
32+**Answer:** a
21**4. Should a fake ship be set up in the cloud container**, so the ship checks run too? That needs the brass pill from GitHub LFS and a few minutes to boot.
34**4. Should a fake ship be set up in the cloud container**, so the ship checks run too? That needs the brass pill from GitHub LFS and a few minutes to boot.
22−a) Yes, before any fix that touches tools/ship, the desks or the mark. b) No, eval checks are enough.
36+- a) Yes, before any fix that touches tools/ship, the desks or the mark.
37+- b) No, eval checks are enough.
23−Answer: a
39+**Answer:** a
25## Direction
41## Direction
27**5. How should the checker grow from here?** (A121)
43**5. How should the checker grow from here?** (A121)
28−a) Build the general core first: union-find bindings with levels, a deferred-constraint queue and Maranget's usefulness check, with `main = (program …)` checked as an ordinary application. b) Keep adding recovery paths until milestone 2's examples pass, and refactor after. c) Both: make today's recovery fall back to ordinary inference now, and plan the core as the next milestone-2 task.
45+- a) Build the general core first: union-find bindings with levels, a deferred-constraint queue and Maranget's usefulness check, with `main = (program …)` checked as an ordinary application.
46+- b) Keep adding recovery paths until milestone 2's examples pass, and refactor after.
47+- c) Both: make today's recovery fall back to ordinary inference now, and plan the core as the next milestone-2 task.
29−Answer: c
49+**Answer:** c
31**6. Should the partial `golden-types` report be rendered from the full checker's per-definition results**, so there is one pipeline? (A122) About 283 `types.txt` outputs would change once.
51**6. Should the partial `golden-types` report be rendered from the full checker's per-definition results**, so there is one pipeline? (A122) About 283 `types.txt` outputs would change once.
32−a) Yes. b) No, keep the two pipelines.
54+- b) No, keep the two pipelines.
33−Answer: a
56+**Answer:** a
35## Checker fixes
58## Checker fixes
37**7. How should the keyed-view screen be fixed?** (A119, A38)
60**7. How should the keyed-view screen be fixed?** (A119, A38)
38−a) Run ordinary inference first, and recovery only for components it leaves unresolved. Some todo diagnostics may change. b) Keep recovery first, and fall back to ordinary inference when it declines.
62+- a) Run ordinary inference first, and recovery only for components it leaves unresolved. Some todo diagnostics may change.
63+- b) Keep recovery first, and fall back to ordinary inference when it declines.
39−Answer: a
65+**Answer:** a
41**8. Should the narrow initializer recovery go?** Deleting the null-sample gate and `program-init-context` (about 140 lines) lets the general path handle reordered models, and the seven negative init fixtures still fail. (A39)
67**8. Should the narrow initializer recovery go?** Deleting the null-sample gate and `program-init-context` (about 140 lines) lets the general path handle reordered models, and the seven negative init fixtures still fail. (A39)
42−a) Yes, once the todo, store and program tests pass. b) No.
69+- a) Yes, once the todo, store and program tests pass.
43−Answer: a
72+**Answer:** a
45**9. How should an imported Hoon `(unit T)` be handled?** (A10)
74**9. How should an imported Hoon `(unit T)` be handled?** (A10)
46−a) Translate it to the prelude's `unit` union, passing the prelude template into the import bridge. b) For now, make it fit as unknown, so it fails closed instead of giving a false error.
76+- a) Translate it to the prelude's `unit` union, passing the prelude template into the import bridge.
77+- b) For now, make it fit as unknown, so it fails closed instead of giving a false error.
47−Answer: a
79+**Answer:** a
49**10. Should printed types say `ask` and `qath` instead of `ask.internal` and `qath.internal`?** Two expected outputs change. (A134)
81**10. Should printed types say `ask` and `qath` instead of `ask.internal` and `qath.internal`?** Two expected outputs change. (A134)
50−a) Yes. b) No.
83+- a) Yes.
51−Answer: a
86+**Answer:** a
53**11. Should every `?-` branch kind join its arm results by one rule:** unify, and if that fails, widen to an explicitly present parent aura or `@`? Then `?- b %.y n %.n 0` with `n=@ud` checks. (A133)
88**11. Should every `?-` branch kind join its arm results by one rule:** unify, and if that fails, widen to an explicitly present parent aura or `@`? Then `?- b %.y n %.n 0` with `n=@ud` checks. (A133)
54−a) Yes. b) No, keep the per-kind rules.
91+- b) No, keep the per-kind rules.
55−Answer: a
93+**Answer:** a
57**12. Should top-level resolution make one pass in dependency order**, keeping the fixpoint as a fallback, with a 400-definition timing check added to the suite? (A135)
95**12. Should top-level resolution make one pass in dependency order**, keeping the fixpoint as a fallback, with a 400-definition timing check added to the suite? (A135)
58−a) Yes. b) Only the fix. c) No.
98+- b) Only the fix.
59−Answer: a
101+**Answer:** a
61**13. Should the checker keep the errors it already finds?** That means the real error inside a local `++`, the name of the failing definition, the API reasons, and a definite error for a derived-name clash. Boundary strings that tests lock in would change. (A12, A40, A24)
103**13. Should the checker keep the errors it already finds?** That means the real error inside a local `++`, the name of the failing definition, the API reasons, and a definite error for a derived-name clash. Boundary strings that tests lock in would change. (A12, A40, A24)
62−a) Yes. b) No.
105+- a) Yes.
63−Answer: a
108+**Answer:** a
65**14. Should the 26-variable printer limit stop gating which modules check?** The printer would print `T27` and on, as it already can. (A124)
110**14. Should the 26-variable printer limit stop gating which modules check?** The printer would print `T27` and on, as it already can. (A124)
66−a) Yes. b) No.
112+- a) Yes.
67−Answer: a
115+**Answer:** a
69**15. Should the 32,768-node freshness scan be replaced** by a fresh-ID high-water mark computed once, with `%recursive` treated as a leaf? (A37)
117**15. Should the 32,768-node freshness scan be replaced** by a fresh-ID high-water mark computed once, with `%recursive` treated as a leaf? (A37)
70−a) Yes. b) Keep the scan and document its budget.
120+- b) Keep the scan and document its budget.
71−Answer: a
122+**Answer:** a
73## Language and spec rulings
124## Language and spec rulings
75**16. Which auras may a term literal fit?** Today `^- @tas %1.000` and `^- @tas %&` are accepted and `^- @ud %1.000` is rejected, the opposite of Hoon. grammar.md:141 supports the code; grammar.md:29 and "Literals: exactly Hoon's" don't. (A20)
126**16. Which auras may a term literal fit?** Today `^- @tas %1.000` and `^- @tas %&` are accepted and `^- @ud %1.000` is rejected, the opposite of Hoon. grammar.md:141 supports the code; grammar.md:29 and "Literals: exactly Hoon's" don't. (A20)
76−a) Follow Hoon: a term literal fits its own aura family, so `%1.000` is `@ud` and `%&` is `?`. b) Keep grammar.md:141 as written.
128+- a) Follow Hoon: a term literal fits its own aura family, so `%1.000` is `@ud` and `%&` is `?`.
129+- b) Keep grammar.md:141 as written.
77−Answer: a
131+**Answer:** a
79**17. May a name term fit `@t`, as `@tas` nests in `@t` in Hoon?** grammar.md:141 lists only `@tas`, `@ta`, `@` and `*`. (A20)
133**17. May a name term fit `@t`, as `@tas` nests in `@t` in Hoon?** grammar.md:141 lists only `@tas`, `@ta`, `@` and `*`. (A20)
80−a) Yes. b) No.
135+- a) Yes.
81−Answer: a
138+**Answer:** a
83**18. May a gate fit `*`?** core-language.md says a function isn't a noun, but the prelude's `element` erases gates into `*`. (A23)
140**18. May a gate fit `*`?** core-language.md says a function isn't a noun, but the prelude's `element` erases gates into `*`. (A23)
84−a) Yes: say in the spec that `*` may hold gates. b) No: design a typed erasure first.
142+- a) Yes: say in the spec that `*` may hold gates.
143+- b) No: design a typed erasure first.
85−Answer: a
145+**Answer:** a
87**19. Where should `[]` and `m()` be rejected?** Both are decided errors. Today the parser accepts them, and the checker calls `[]` "not supported". (A6, A100)
147**19. Where should `[]` and `m()` be rejected?** Both are decided errors. Today the parser accepts them, and the checker calls `[]` "not supported". (A6, A100)
88−a) In the parser, at the closer, with new golden cases. b) In the checker, as definite errors.
149+- a) In the parser, at the closer, with new golden cases.
150+- b) In the checker, as definite errors.
89−Answer: a
152+**Answer:** a
91**20. Is `[a=@ud [a=@t b=?]]` one record or two scopes?** Hoon treats it as flat, and field access already does. Today the duplicate `a` is accepted and `a.x` is "ambiguous". (A30)
154**20. Is `[a=@ud [a=@t b=?]]` one record or two scopes?** Hoon treats it as flat, and field access already does. Today the duplicate `a` is accepted and `a.x` is "ambiguous". (A30)
92−a) One record: the duplicate is an error. b) Two scopes, as compiler.md says now.
156+- a) One record: the duplicate is an error.
157+- b) Two scopes, as compiler.md says now.
93−Answer: a
159+**Answer:** a
95**21. Should `/% %foo` together with `++ foo 1` be allowed?** `/%` binds only a mold, and molds and values have separate namespaces (grammar.md:94 and :102), but the scope check rejects it. (A25)
161**21. Should `/% %foo` together with `++ foo 1` be allowed?** `/%` binds only a mold, and molds and values have separate namespaces (grammar.md:94 and :102), but the scope check rejects it. (A25)
96−a) Yes. b) No.
163+- a) Yes.
97−Answer: a
166+**Answer:** a
99**22. Should a `?-` arm that matches no remaining case be a definite error** ("arm matches no case"), as grammar.md:184 implies, instead of "not supported"? (A15)
168**22. Should a `?-` arm that matches no remaining case be a definite error** ("arm matches no case"), as grammar.md:184 implies, instead of "not supported"? (A15)
100−a) Yes. b) No.
170+- a) Yes.
101−Answer: a
173+**Answer:** a
103**23. Should `(mop K V)` carry its comparator,** so that `get.on gth` on an `lte` mop is an error? Neither Hoon nor decisions.md:39 does this. (A55)
175**23. Should `(mop K V)` carry its comparator,** so that `get.on gth` on an `lte` mop is an error? Neither Hoon nor decisions.md:39 does this. (A55)
104−a) No, match Hoon. b) Yes.
177+- a) No, match Hoon.
105−Answer: a
180+**Answer:** a
107**24. Should Hoon's `each` mold be renamed to `each.hoon`**, since the prelude also has the element gate `each`? They live in separate namespaces. (A64)
182**24. Should Hoon's `each` mold be renamed to `each.hoon`**, since the prelude also has the element gate `each`? They live in separate namespaces. (A64)
108−a) No, keep both. b) Yes.
184+- a) No, keep both.
109−Answer: a
187+**Answer:** a
111**25. When should `eq` and the gate-free type-variable constraint be built?** Both are decided, neither exists, and no doc tracks them. (A98)
189**25. When should `eq` and the gate-free type-variable constraint be built?** Both are decided, neither exists, and no doc tracks them. (A98)
112−a) In milestone 2. b) Later, and list them as outstanding.
192+- b) Later, and list them as outstanding.
113−Answer: a
194+**Answer:** a
115**26. Which Hoon unions should the importer learn?** Today `$%` with `%&`, `%|` or `%0` tags, `(each a b)` and `json` all fail, though the spec's import table lists them. (A50)
196**26. Which Hoon unions should the importer learn?** Today `$%` with `%&`, `%|` or `%0` tags, `(each a b)` and `json` all fail, though the spec's import table lists them. (A50)
116−a) The non-`%tas` tags now, then `each` and `json` as catalog entries. b) Only the tags. c) Later.
198+- a) The non-`%tas` tags now, then `each` and `json` as catalog entries.
117−Answer: a
202+**Answer:** a
119**27. Should the `%jibb` mark keep dropping the final newline on a `%txt` round trip**, as `%hoon` does? (A61)
204**27. Should the `%jibb` mark keep dropping the final newline on a `%txt` round trip**, as `%hoon` does? (A61)
206+- a) Keep it, like `%hoon`.
120−a) Keep it, like `%hoon`. b) Preserve the newline, and change tools/ship's assertion.
207+- b) Preserve the newline, and change tools/ship's assertion.
121−Answer: a
209+**Answer:** a
123**28. Should the printer flatten `[a [b c]]` to `[a b c]` and print named molds by name**, such as `theme` and `item.todo`? (A136)
211**28. Should the printer flatten `[a [b c]]` to `[a b c]` and print named molds by name**, such as `theme` and `item.todo`? (A136)
124−a) Yes. b) No.
213+- a) Yes.
125−Answer: a
216+**Answer:** a
127## Tests and tooling
218## Tests and tooling
129**29. Should one runner over the `tests/lib` test arms replace the 49 `tools/type-*-test` scripts and `importer-test`?** A prototype ran them in 681 s instead of 2,591 s. The `my-app` byte guards would move to a manifest. (A82, A120)
220**29. Should one runner over the `tests/lib` test arms replace the 49 `tools/type-*-test` scripts and `importer-test`?** A prototype ran them in 681 s instead of 2,591 s. The `my-app` byte guards would move to a manifest. (A82, A120)
130−a) Yes. b) No.
222+- a) Yes.
131−Answer: a
225+**Answer:** a
133**30. Should there be one `tools/check` command, and CI?** (A92, A96)
227**30. Should there be one `tools/check` command, and CI?** (A92, A96)
134−a) `tools/check` now, and a CI job for the eval checks now. b) `tools/check` now, CI at milestone 7 as planned. c) Neither.
229+- a) `tools/check` now, and a CI job for the eval checks now.
230+- b) `tools/check` now, CI at milestone 7 as planned.
135−Answer: b
233+**Answer:** b
137**31. How should the 28 copies of `my-app` files under `tests/` be handled?** (A108, A109)
235**31. How should the 28 copies of `my-app` files under `tests/` be handled?** (A108, A109)
138−a) Map `my-app` into the `jibb-dev` desk outside `/tests` and read it directly, removing the copies. b) Keep the copies, and guard them all from one manifest.
237+- a) Map `my-app` into the `jibb-dev` desk outside `/tests` and read it directly, removing the copies.
238+- b) Keep the copies, and guard them all from one manifest.
139−Answer: a
240+**Answer:** a
141**32. Should the generated `tests/lib/jibb.hoon` (3,949 lines) stop being committed?** Assembly drops it and regenerates it anyway. (A83)
242**32. Should the generated `tests/lib/jibb.hoon` (3,949 lines) stop being committed?** Assembly drops it and regenerates it anyway. (A83)
142−a) Yes, and add it to .gitignore. b) No.
244+- a) Yes, and add it to .gitignore.
143−Answer: a
247+**Answer:** a
145**33. Should the importer's test fixtures (about 550 lines) move out of `jibb-import.hoon`**, which app desks vendor, into `tests/lib/jibb-import.hoon`? (A52)
249**33. Should the importer's test fixtures (about 550 lines) move out of `jibb-import.hoon`**, which app desks vendor, into `tests/lib/jibb-import.hoon`? (A52)
146−a) Yes. b) No.
251+- a) Yes.
147−Answer: a
254+**Answer:** a
149**34. Should the import-only fixtures move off `my-app`** (`sur/import-fixture.hoon`, `mar/label.hoon`, the Tlon probe) to a fixtures desk? (A113)
256**34. Should the import-only fixtures move off `my-app`** (`sur/import-fixture.hoon`, `mar/label.hoon`, the Tlon probe) to a fixtures desk? (A113)
150−a) Yes. b) No.
258+- a) Yes.
151−Answer: a
261+**Answer:** a
153**35. Should the five `tools/hoon` checks that exit 0 whatever they print become test arms?** (A91)
263**35. Should the five `tools/hoon` checks that exit 0 whatever they print become test arms?** (A91)
154−a) Yes. b) No.
265+- a) Yes.
155−Answer: a
268+**Answer:** a
157**36. Should type-checker golden cases keep their full token and tree outputs?** They are 73% of all parser golden lines. (A94)
270**36. Should type-checker golden cases keep their full token and tree outputs?** They are 73% of all parser golden lines. (A94)
158−a) Keep them: each stage's output is compared. b) Let type cases opt out.
272+- a) Keep them: each stage's output is compared.
273+- b) Let type cases opt out.
159−Answer: a
275+**Answer:** a
161**37. Should the tests keep calling internal library arms (137 of them)?** (A126)
277**37. Should the tests keep calling internal library arms (137 of them)?** (A126)
162−a) Keep them for now, and revisit after the checker core changes. b) Move them behind a small public facade.
279+- a) Keep them for now, and revisit after the checker core changes.
280+- b) Move them behind a small public facade.
163−Answer: a
282+**Answer:** a
165**38. Should `my-app` keep the failing buttons example and the doc theme's static font?** Milestone 4 will treat both as errors. (A112)
284**38. Should `my-app` keep the failing buttons example and the doc theme's static font?** Milestone 4 will treat both as errors. (A112)
166−a) Keep them through milestone 2, and list it as a milestone-4 open question. b) Move the error example out now.
286+- a) Keep them through milestone 2, and list it as a milestone-4 open question.
287+- b) Move the error example out now.
167−Answer: a
289+**Answer:** a
169**39. Should every vendored package keep going into every desk?** (A117)
291**39. Should every vendored package keep going into every desk?** (A117)
170−a) Yes, as designed. b) Make it per desk.
293+- a) Yes, as designed.
294+- b) Make it per desk.
171−Answer: a
296+**Answer:** a
173**40. Should `tools/hoon` get a `--no-debug` mode** for timings, with the docs' figures re-measured? Every eval runs with `!:`, which makes checker work 2.2 to 2.6 times slower. (A137)
298**40. Should `tools/hoon` get a `--no-debug` mode** for timings, with the docs' figures re-measured? Every eval runs with `!:`, which makes checker work 2.2 to 2.6 times slower. (A137)
174−a) Yes. b) No.
300+- a) Yes.
175−Answer: a
303+**Answer:** a
177## Docs and repository
305## Docs and repository
179**41. Should status.md become a capability table** (area, status, the test that proves it) plus a short list of gaps, with the history table replaced by `git log`? (A97, A95)
307**41. Should status.md become a capability table** (area, status, the test that proves it) plus a short list of gaps, with the history table replaced by `git log`? (A97, A95)
180−a) Yes. b) Only fix the contradictions.
310+- b) Only fix the contradictions.
181−Answer: a
312+**Answer:** a
183**42. Until the Claude design doc is synced, which spec wins?** (A104)
314**42. Until the Claude design doc is synced, which spec wins?** (A104)
184−a) The repository copy, with a "synced" column in decisions.md. b) The Claude doc, as development.md says now.
316+- a) The repository copy, with a "synced" column in decisions.md.
317+- b) The Claude doc, as development.md says now.
185−Answer: a
319+**Answer:** a
187**43. Who syncs the Claude design doc with the repository's decisions?**
321**43. Who syncs the Claude design doc with the repository's decisions?**
188−a) Me, if you give me edit access to it. b) @iko. c) Leave it for now.
323+- a) Me, if you give me edit access to it.
325+- c) Leave it for now.
189−Answer: b
327+**Answer:** b
191**44. Should open-questions.md hold only open questions**, with settled ones moved to decisions.md? (A103)
329**44. Should open-questions.md hold only open questions**, with settled ones moved to decisions.md? (A103)
192−a) Yes. b) No.
331+- a) Yes.
193−Answer: a
334+**Answer:** a
195**45. Which licence should the repository have?** It has none, and doesn't state the licences of `vendor/` or the Tlon fixtures. (A107)
336**45. Which licence should the repository have?** It has none, and doesn't state the licences of `vendor/` or the Tlon fixtures. (A107)
196−a) MIT, like urbit/urbit. b) Another licence. c) None: keep it private.
338+- a) MIT, like urbit/urbit.
339+- b) Another licence.
340+- c) None: keep it private.
197−Answer: a
342+**Answer:** a