@@ -1,6 +1,6 @@
1# Questions from the 2026-11-02 review
1# Questions from the 2026-11-02 review
3−Every decision that [the review](2026-11-02-repo-review.md) raises, with options. Each **Answer** is prefilled with the recommended option, so only the ones you disagree with need changing. A-numbers point into the review's appendix.
3+Every decision that [the review](2026-11-02-repo-review.md) raises, with options. Each **Answer** was prefilled with the recommended option. An answer marked *(chosen)* is the one Montelot picked; the rest are still the recommendation. A-numbers point into the review's appendix.
5Questions 16 to 28 are language or spec rulings. Under the ground rules they are @iko's to make and are recorded in decisions.md before the code changes.
5Questions 16 to 28 are language or spec rulings. Under the ground rules they are @iko's to make and are recorded in decisions.md before the code changes.
@@ -12,7 +12,7 @@ Questions 16 to 28 are language or spec rulings. Under the ground rules they are
12- b) Open a pull request.
12- b) Open a pull request.
13- c) Leave it on the branch.
13- c) Leave it on the branch.
15−**Answer:** a
15+**Answer:** a *(chosen)*
17**2. What should be done first?**
17**2. What should be done first?**
@@ -21,7 +21,7 @@ Questions 16 to 28 are language or spec rulings. Under the ground rules they are
21- c) The docs cleanup.
21- c) The docs cleanup.
22- d) Nothing more for now.
22- d) Nothing more for now.
24−**Answer:** a, then c
24+**Answer:** a *(chosen)*
26**3. How should fixes land?**
26**3. How should fixes land?**
@@ -29,14 +29,14 @@ Questions 16 to 28 are language or spec rulings. Under the ground rules they are
29- b) One pull request per theme.
29- b) One pull request per theme.
30- c) A branch you merge yourself.
30- c) A branch you merge yourself.
32−**Answer:** a
32+**Answer:** a *(chosen)*
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.
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.
36- a) Yes, before any fix that touches tools/ship, the desks or the mark.
36- a) Yes, before any fix that touches tools/ship, the desks or the mark.
37- b) No, eval checks are enough.
37- b) No, eval checks are enough.
39−**Answer:** a
39+**Answer:** a *(chosen)*
41## Direction
41## Direction
@@ -46,14 +46,14 @@ Questions 16 to 28 are language or spec rulings. Under the ground rules they are
46- b) Keep adding recovery paths until milestone 2's examples pass, and refactor after.
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.
47- c) Both: make today's recovery fall back to ordinary inference now, and plan the core as the next milestone-2 task.
49−**Answer:** c
49+**Answer:** a *(chosen)*
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.
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.
54- b) No, keep the two pipelines.
54- b) No, keep the two pipelines.
56−**Answer:** a
56+**Answer:** a *(chosen)*
58## Checker fixes
58## Checker fixes
@@ -62,35 +62,35 @@ Questions 16 to 28 are language or spec rulings. Under the ground rules they are
62- a) Run ordinary inference first, and recovery only for components it leaves unresolved. Some todo diagnostics may change.
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.
63- b) Keep recovery first, and fall back to ordinary inference when it declines.
65−**Answer:** a
65+**Answer:** a *(chosen)*
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)
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)
69- a) Yes, once the todo, store and program tests pass.
69- a) Yes, once the todo, store and program tests pass.
72−**Answer:** a
72+**Answer:** a *(chosen)*
74**9. How should an imported Hoon `(unit T)` be handled?** (A10)
74**9. How should an imported Hoon `(unit T)` be handled?** (A10)
76- a) Translate it to the prelude's `unit` union, passing the prelude template into the import bridge.
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.
77- b) For now, make it fit as unknown, so it fails closed instead of giving a false error.
79−**Answer:** a
79+**Answer:** a *(chosen)*
81**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)
86−**Answer:** a
86+**Answer:** a *(chosen)*
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)
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)
91- b) No, keep the per-kind rules.
91- b) No, keep the per-kind rules.
93−**Answer:** a
93+**Answer:** a *(chosen)*
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)
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)
@@ -98,28 +98,28 @@ Questions 16 to 28 are language or spec rulings. Under the ground rules they are
98- b) Only the fix.
98- b) Only the fix.
101−**Answer:** a
101+**Answer:** b *(chosen)*
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)
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)
108−**Answer:** a
108+**Answer:** a *(chosen)*
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)
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)
115−**Answer:** a
115+**Answer:** a *(chosen)*
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)
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)
120- b) Keep the scan and document its budget.
120- b) Keep the scan and document its budget.
122−**Answer:** a
122+**Answer:** a *(chosen)*
124## Language and spec rulings
124## Language and spec rulings
@@ -128,56 +128,56 @@ Questions 16 to 28 are language or spec rulings. Under the ground rules they are
128- a) Follow Hoon: a term literal fits its own aura family, so `%1.000` is `@ud` and `%&` is `?`.
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.
129- b) Keep grammar.md:141 as written.
131−**Answer:** a
131+**Answer:** a *(chosen)*
133**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)
138−**Answer:** a
138+**Answer:** a *(chosen)*
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)
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)
142- a) Yes: say in the spec that `*` may hold gates.
142- a) Yes: say in the spec that `*` may hold gates.
143- b) No: design a typed erasure first.
143- b) No: design a typed erasure first.
145−**Answer:** a
145+**Answer:** a *(chosen)*
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)
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)
149- a) In the parser, at the closer, with new golden cases.
149- a) In the parser, at the closer, with new golden cases.
150- b) In the checker, as definite errors.
150- b) In the checker, as definite errors.
152−**Answer:** a
152+**Answer:** a *(chosen)*
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)
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)
156- a) One record: the duplicate is an error.
156- a) One record: the duplicate is an error.
157- b) Two scopes, as compiler.md says now.
157- b) Two scopes, as compiler.md says now.
159−**Answer:** a
159+**Answer:** a *(chosen)*
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)
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)
166−**Answer:** a
166+**Answer:** a *(chosen)*
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)
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)
173−**Answer:** a
173+**Answer:** a *(chosen)*
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)
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)
177- a) No, match Hoon.
177- a) No, match Hoon.
180−**Answer:** a
180+**Answer:** a *(chosen)*
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)
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)