Tests that follow the code, and enforced layers

.github/tickets/README.md

@@ -40,8 +40,11 @@ carries what the agent needs:
 3. **`Its responsibilities are:`** only where there are distinct ones.
 4. **`should`** for each requirement, with the reason straight after it.
 5. **`Where:`** the files and types to start from. Paths are relative to the
-   solution folder `SNP_Evolution/`: `SNP_Evolution/...` is the app and
-   `SNP_Evolution.Tests/...` the tests.
+   solution folder `SNP_Evolution/`, whose folders are the layer projects
+   (`Model/...`, `Specs/...`, `Search/...` and so on, as the README lists them)
+   and `SNP_Evolution.Tests/...` the tests; a file the ticket creates follows
+   the word "new". `python3 .github/tickets/where.py` checks that every
+   path in an open ticket's `Where:` line exists.
 6. **`Done when:`** a checklist that a reviewer can tick without asking.
 7. **`Read first:`** the spec sections, last line, no trailing period.
 

.github/tickets/m2.5/m2.5-p6-1-test-fixtures.md

@@ -18,7 +18,7 @@ Its responsibilities are:
 
 Tests should keep their assertions, because this is a move; a test that changes what it checks belongs in another ticket.
 
-Where: `SNP_Evolution.Tests/`, `SNP_Evolution.Tests/TestNetworks.cs`, `SNP_Evolution.Tests/Evolution/ModuleFixtures.cs`.
+Where: `SNP_Evolution.Tests/`, `SNP_Evolution.Tests/Fixtures/TestNetworks.cs`, `SNP_Evolution.Tests/Fixtures/ModuleFixtures.cs`.
 
 Done when:
 - [ ] No builder or setup is defined in more than one test file

.github/tickets/m2.5/m2.5-p6-2-project-split.md

@@ -19,7 +19,7 @@ Its responsibilities are:
 The exact cut may move a type to a lower layer where a reference would otherwise point upwards, and each such move should be listed, because the cut is right only where the dependencies agree with it.
 `install-snp.sh` and `dotnet tool install` should work as before, because that is how the tool is used.
 
-Where: `SNP_Evolution.slnx`, `SNP_Evolution/SNP_Evolution.csproj`, `SNP_Evolution.Tests/SNP_Evolution.Tests.csproj`, `Directory.Build.props`, `install-snp.sh`.
+Where: `SNP_Evolution.slnx`, `Cli/Cli.csproj`, `SNP_Evolution.Tests/SNP_Evolution.Tests.csproj`, `Directory.Build.props`, `install-snp.sh`.
 
 Done when:
 - [ ] The solution builds as separate projects and no project references one above it

.github/tickets/m2/m2-p3-1-streaming-tasks.md

@@ -18,7 +18,7 @@ Its responsibilities are:
 The task should use the existing `Readout.SpikeTrain`, because it already returns every firing step of the output neuron.
 Inputs should be generated with a fixed seed per case, because the exhaustive engine needs the same input every time.
 
-Where: new `SNP_Evolution/Evolution/Tasks/StreamingTask.cs`; `SNP_Evolution/Evolution/Tasks/SpikeTrains.cs` and `TaskSuite.cs`; `SNP_Evolution/Simulation/InputSpikes.cs`.
+Where: new `Specs/Tasks/StreamingTask.cs`; `Specs/Tasks/SpikeTrains.cs` and `Search/Benchmarking/TaskSuite.cs`; `Simulation/InputSpikes.cs`.
 
 Done when:
 - [ ] Both tasks appear in `dotnet run -- tasks`

.github/tickets/m2/m2-p3-2-timing-robustness.md

@@ -14,7 +14,7 @@ We want a simulation option that delays each spike on each synapse by 0 to j ext
 The robustness score should be reported for every library part and be available as a MAP-Elites dimension, because robustness is a property to select for, not only to report.
 Jitter should be a sampled engine option and the exhaustive engine should refuse it, because the branching from every delay choice would explode the exhaustive search.
 
-Where: `SNP_Evolution/Simulation/ISimulationEngine.cs` (`SimulationOptions`), `SNP_Evolution/Simulation/NetworkSimulation.cs`, `SNP_Evolution/Simulation/SequentialCpuEngine.cs`; the library summary from the `evolve-parts` command.
+Where: `Simulation/SimulationOptions.cs`, `Simulation/NetworkSimulation.cs`, `Simulation/SequentialCpuEngine.cs`; the library summary from the `evolve-parts` command.
 
 Done when:
 - [ ] With j = 0 every result equals today's

.github/tickets/m3/m3-p1-1-control-parts.md

@@ -20,7 +20,7 @@ Join's cases should include both orders, equal steps, and the largest gap the co
 Each contract should leave every neuron as it began, as every first part does, because a join left holding one spike fires early next round.
 The contracts should be general, not taken from the add loop, because they are goals for automatic discovery.
 
-Where: `SNP_Evolution/Evolution/Contracts/FirstParts.cs` (catalogue and `Table()`), `SNP_Evolution/Evolution/Contracts/Specification.cs` (a specification for each), `SNP_Evolution/Evolution/Contracts/PartEvolution.cs`; tests in `SNP_Evolution.Tests/Evolution/FirstPartsTests.cs`.
+Where: `Specs/Contracts/FirstParts.cs` (catalogue and `Table()`), `Specs/Contracts/Specification.cs` (a specification for each), `Search/PartSearch.cs`; tests in `SNP_Evolution.Tests/Specs/Contracts/FirstPartsTests.cs`.
 
 Done when:
 - [ ] The four contracts are in the catalogue with specifications that agree with their cases

.github/tickets/m3/m3-p1-2-function-programs.md

@@ -20,7 +20,7 @@ The interpreter should follow every choice when the program has one, because a c
 A program should leave every register but the outputs at zero when it halts, and the search should check this, because a compiled part must end as it began.
 Each count contract in `FirstParts` and `ArithmeticParts.Count` should be a valid search target without special cases, because the route has to be general.
 
-Where: `SNP_Evolution/Compilation/RegisterMachine.cs`, `SNP_Evolution/Compilation/ProgramSearch.cs`, `SNP_Evolution/Evolution/Contracts/Contract.cs`; tests in `SNP_Evolution.Tests/Compilation/CompilerTests.cs`.
+Where: `Compilation/RegisterMachine.cs`, `Search/ProgramSearch.cs`, `Specs/Contracts/Contract.cs`; tests in `SNP_Evolution.Tests/Compilation/RegisterProgramTests.cs` and `SNP_Evolution.Tests/Search/ProgramSearchTests.cs`.
 
 Done when:
 - [ ] Hand-written function programs for add, increment, double, fan-out, register and zero test pass their contracts' cases in the interpreter

.github/tickets/m3/m3-p1-3-compile-programs-to-parts.md

@@ -22,7 +22,7 @@ Shrinking should keep the cheapest network that still verifies, as parts from se
 The part file should record that it came from a compiled program and keep the program, because the paper must say which parts came from the compiler.
 A `--route search|compile|both` option should choose the route (both by default for count contracts: compile, then search from the shrunk part), because the routes should be comparable.
 
-Where: `SNP_Evolution/Compilation/RegisterMachineCompiler.cs`, `SNP_Evolution/Evolution/Contracts/PartEvolution.cs`, `SNP_Evolution/Evolution/Contracts/PortBinding.cs`, `SNP_Evolution/Storage/PartLibraryFiles.cs`, `SNP_Evolution/Cli/PartsSession.cs`.
+Where: `Compilation/RegisterMachineCompiler.cs`, `Search/PartSearch.cs`, `Specs/Contracts/PortBinding.cs`, `Storage/PartLibraryFiles.cs`, `Application/PartsService.cs`.
 
 Done when:
 - [ ] The hand-written function programs for register, add, increment, fan-out and zero test compile to parts that pass their contracts on the exhaustive engine

.github/tickets/m3/m3-p1-4-compiled-parts-benchmark.md

@@ -15,7 +15,7 @@ The table should give, per contract, seeds solved, evaluations, and neurons, syn
 The n1 x n2 runs should repeat the M1 benchmark settings (10 seeds per algorithm, 6000 evaluations, lexicase, 5 sampled runs) with `--hand-built off`, because only then is the change attributable to the library.
 If n1 x n2 is not solved, the report should say so and give the best fitness and the parts the best networks hold, because an honest negative is still the result.
 
-Where: `SNP_Evolution/Evolution/Benchmarking/Benchmark.cs`, the `evolve-parts` and `benchmark` commands; results in RESEARCH.md "Evolved against hand-designed arithmetic" and README "Composing machines from parts".
+Where: `Search/Benchmarking/Benchmark.cs`, the `evolve-parts` and `benchmark` commands; results in RESEARCH.md "Evolved against hand-designed arithmetic" and README "Composing machines from parts".
 
 Done when:
 - [ ] The per-contract table is in RESEARCH.md, seeds 1 to 5

.github/tickets/m3/m3-p2-1-part-programs.md

@@ -21,7 +21,7 @@ A count out-port should add to its register rather than overwrite it, because tw
 A register read by a call should be emptied by it, because a count port consumes what it reads; a program that needs a value twice must fan it out first, as the network must.
 The step estimate should be marked as an estimate, because exact timing comes only from the lowered network.
 
-Where: new `SNP_Evolution/Evolution/Programs/` (or beside `SNP_Evolution/Compilation/RegisterMachine.cs`), `SNP_Evolution/Evolution/Contracts/Specification.cs`, `SNP_Evolution/Evolution/Modules/ModuleLibrary.cs`.
+Where: new `Compilation/PartPrograms/` (or beside `Compilation/RegisterMachine.cs`), `Specs/Contracts/Specification.cs`, `Specs/Parts/ModuleLibrary.cs`.
 
 Done when:
 - [ ] A hand-written part program for n1 x n2 from register, add, zero test, decrement and fan-out gives every multiply case in the interpreter

.github/tickets/m3/m3-p2-2-lower-programs.md

@@ -20,7 +20,7 @@ The lowering should only use parts from the library and plain relays, because a
 Where the lowering needs a part the library lacks (a join, a merge, a timer), it should say which, because that is a proposal the run can make.
 A disagreement between the interpreter and the network should be reported with the case and both readings, because it means either a lowering bug or a part whose contract does not say enough about timing.
 
-Where: `SNP_Evolution/Evolution/Modules/Composition.cs`, `SNP_Evolution/Evolution/Modules/PartWiring.cs`, `SNP_Evolution/Evolution/Modules/Promotion.cs`; the n1 x n2 and Fibonacci programs from the previous ticket as tests.
+Where: `Specs/Parts/Composition.cs`, `Specs/Parts/PartWiring.cs`, `Search/Modules/Promotion.cs`; the n1 x n2 and Fibonacci programs from the previous ticket as tests.
 
 Done when:
 - [ ] The hand-written n1 x n2 program lowers to a network that passes the multiply contract on the exhaustive engine and is promoted

.github/tickets/m3/m3-p2-3-part-program-search.md

@@ -21,7 +21,7 @@ Its responsibilities are:
 Evaluations should be counted in the same units as composition search (one interpreter run per case counts as one evaluation of a network), plus every lowered network verified, because the two genomes must be compared on one budget.
 A program that solves in the interpreter but fails after lowering should be kept out of the population and logged, because the interpreter would otherwise reward it forever.
 
-Where: new search beside the part-program interpreter; `SNP_Evolution/Evolution/Modules/CompositionSearch.cs` for the edit and evaluation conventions, `SNP_Evolution/Evolution/Proposals/PartProposals.cs`, `SNP_Evolution/Cli/CommandLine.cs` (`compose`), `SNP_Evolution/Evolution/Benchmarking/Benchmark.cs`.
+Where: new search beside the part-program interpreter; `Search/EvolutionSearch.cs` (`CompositionSearch`) for the edit and evaluation conventions, `Search/Proposals/PartProposals.cs`, `Cli/Commands/ComposeCommand.cs`, `Search/Benchmarking/Benchmark.cs`.
 
 Done when:
 - [ ] `compose --task "Contract multiply" --genome program` solves from a library with no hand-built parts on at least half of 10 seeds, with the median evaluations reported next to composition search

.github/tickets/m3/m3-p2-5-arithmetic-depth.md

@@ -16,7 +16,7 @@ Reuse should be reported per level: which promoted parts appear in each solution
 An n^k contract should be added to `ArithmeticParts` with a specification, keeping its cases small enough for the exhaustive engine, because it has to be verifiable to count.
 Sizes and steps should be added to the published-circuit table, because Zeng et al. give hand-built sizes for the same four operations.
 
-Where: `SNP_Evolution/Evolution/Contracts/ArithmeticParts.cs`, `SNP_Evolution/Evolution/Contracts/Specification.cs`, `SNP_Evolution/Evolution/Modules/PartReuse.cs`; results in RESEARCH.md "Evolved against hand-designed arithmetic".
+Where: `Specs/Contracts/ArithmeticParts.cs`, `Specs/Contracts/Specification.cs`, `Specs/Parts/PartReuse.cs`; results in RESEARCH.md "Evolved against hand-designed arithmetic".
 
 Done when:
 - [ ] Solved counts over 5 seeds for subtraction, division, comparison and n^k, by part-program and by composition search, are in RESEARCH.md

.github/tickets/m3/m3-p3-1-counterexample-guided-search.md

@@ -21,7 +21,7 @@ The loop should stop after a set number of counterexamples (8 by default) and re
 The counterexample should be the structured one the M2.5 verifier returns, because a counterexample as text cannot be scored.
 A counterexample should be added as a full case from the specification, so lexicase sees it as one more case, because a special penalty would be one more scoring rule to tune.
 
-Where: `SNP_Evolution/Evolution/Contracts/BoundedCheck.cs` (`Admit`), `SNP_Evolution/Evolution/Contracts/PartEvolution.cs`, `SNP_Evolution/Evolution/Tasks/ContractTask.cs`, `SNP_Evolution/Evolution/Proposals/PartProposals.cs`, `SNP_Evolution/Evolution/Modules/Promotion.cs`, `SNP_Evolution/Storage/PartLibraryFiles.cs`.
+Where: `Specs/Verification/BoundedCheck.cs` (`Admit`), `Search/PartSearch.cs`, `Specs/Tasks/ContractTask.cs`, `Search/Proposals/PartProposals.cs`, `Search/Modules/Promotion.cs`, `Storage/PartLibraryFiles.cs`.
 
 Done when:
 - [ ] Given the add loop as it was before its done waited for the accumulator, composition search with the counterexample loop on finds a version that passes admission past a = 14

.github/tickets/m3/m3-p3-2-proof-by-composition.md

@@ -21,7 +21,7 @@ The use check should be stated as what the contract's cases assume and nothing m
 The timing of a child should come from its specification's latency bound, and a composition that relies on exact timing between children should be refused with the reason, because start and done are what make composition timing-safe, and anything else is unproven.
 Where the flattened check and the proof by composition both run, they should agree, and a test should cover this, because the new proof is only trusted where it has been checked.
 
-Where: `SNP_Evolution/Evolution/Contracts/BoundedCheck.cs`, `SNP_Evolution/Evolution/Contracts/Specification.cs`, `SNP_Evolution/Evolution/Modules/Promotion.cs` (recipes), the `verify` command; tests in `SNP_Evolution.Tests/Evolution/BoundedCheckTests.cs`.
+Where: `Specs/Verification/BoundedCheck.cs`, `Specs/Contracts/Specification.cs`, `Search/Modules/Promotion.cs` (recipes), the `verify` command; tests in `SNP_Evolution.Tests/Specs/Verification/BoundedCheckTests.cs`.
 
 Done when:
 - [ ] The add loop and the promoted multiplier are proven by composition to at least five times their flattened bounds in the same time

.github/tickets/m3/m3-p4-1-bit-serial-adder.md

@@ -16,7 +16,7 @@ The comparison should give neurons, synapses and steps against Aimone et al.'s 4
 The contract should be a family over width, because the binary primitives of the verified library in M5 are built on it.
 If the profile run also solves it, the part should be exported to NIR and checked by co-simulation, because a bit-serial adder is the part that fits integrate-and-fire hardware.
 
-Where: `SNP_Evolution/Evolution/Contracts/ArithmeticParts.cs`, `SNP_Evolution/Evolution/Contracts/Specification.cs`, `SNP_Evolution/Evolution/Contracts/PortEncoding.cs`, `SNP_Evolution/Evolution/Contracts/PartEvolution.cs`; the published-circuit table in RESEARCH.md.
+Where: `Specs/Contracts/ArithmeticParts.cs`, `Specs/Contracts/Specification.cs`, `Specs/Contracts/PortEncoding.cs`, `Search/PartSearch.cs`; the published-circuit table in RESEARCH.md.
 
 Done when:
 - [ ] The binary add contracts and their specifications are in the catalogue

.github/tickets/m3/m3-p4-2-part-families.md

@@ -19,7 +19,7 @@ A built member should be verified and proven like any other part, because compos
 A built member should be replaced by an evolved one only when the evolved one is cheaper, because the library already keeps the cheaper of two parts that read the same.
 The family's members should be one entry per k in the library, under the family's name, because composition and part programs need a concrete part to wire.
 
-Where: `SNP_Evolution/Evolution/Contracts/Contract.cs`, `SNP_Evolution/Evolution/Contracts/FirstParts.cs`, `SNP_Evolution/Evolution/Modules/Promotion.cs`, `SNP_Evolution/Evolution/Modules/ModuleLibrary.cs`, `SNP_Evolution/Storage/PartLibraryFiles.cs`.
+Where: `Specs/Contracts/Contract.cs`, `Specs/Contracts/FirstParts.cs`, `Search/Modules/Promotion.cs`, `Specs/Parts/ModuleLibrary.cs`, `Storage/PartLibraryFiles.cs`.
 
 Done when:
 - [ ] Delay k and sequencer k are families, and members for k up to 8 are built from the library's members, verified and proven

.github/tickets/m3/m3-p4-3-library-compression.md

@@ -16,7 +16,7 @@ It should count, for each candidate sub-composition, how many promoted parts hol
 A candidate should only count if it has a contract that can be read off its ports and checked, because a part without a contract cannot be verified or reused.
 It should end in a recommendation: build compression into promotion, or leave it, with the numbers behind it.
 
-Where: `SNP_Evolution/Evolution/Modules/Promotion.cs` (recipes), `SNP_Evolution/Evolution/Modules/PartReuse.cs`, the libraries left by the M3 benchmarks; the finding in RESEARCH.md "Toward general synthesis".
+Where: `Search/Modules/Promotion.cs` (recipes), `Specs/Parts/PartReuse.cs`, the libraries left by the M3 benchmarks; the finding in RESEARCH.md "Toward general synthesis".
 
 Done when:
 - [ ] RESEARCH.md lists the candidate sub-compositions found, how many promoted parts hold each, and the recipe size saved

.github/tickets/m4/m4-p1-1-algorithm-spec.md

@@ -23,7 +23,7 @@ Case generation should be seeded and deterministic, because two runs of one spec
 A spec built for a catalogue contract should agree with that contract's cases and its `Specification`, checked with `Specifications.Disagreements`, because the catalogue is what existing parts were verified against.
 Training cases should include the edges of the domain (zero, one, the largest training value), because off-by-one parts pass the middle and fail the edges.
 
-Where: new `SNP_Evolution/Evolution/Specs/AlgorithmSpec.cs`; `SNP_Evolution/Evolution/Contracts/Specification.cs`, `SNP_Evolution/Evolution/Contracts/Contract.cs`, `SNP_Evolution/Evolution/Contracts/PortEncoding.cs`, `SNP_Evolution/Evolution/Contracts/ArithmeticParts.cs`, `SNP_Evolution/Evolution/Tasks/ContractTask.cs`; tests in `SNP_Evolution.Tests/Evolution/`.
+Where: new `Specs/Contracts/AlgorithmSpec.cs`; `Specs/Contracts/Specification.cs`, `Specs/Contracts/Contract.cs`, `Specs/Contracts/PortEncoding.cs`, `Specs/Contracts/ArithmeticParts.cs`, `Specs/Tasks/ContractTask.cs`; tests in `SNP_Evolution.Tests/Specs/`.
 
 Done when:
 - [ ] Specs for add, multiply, compare and fan-out make contracts with no disagreements against the catalogue's

.github/tickets/m4/m4-p1-2-recurrence-task.md

@@ -21,7 +21,7 @@ A gap after a mistake should still earn credit when it follows the rule from the
 Coefficients as inputs should be optional, because a fixed rule is the first test and the family g(k) = c1 g(k-1) + c2 g(k-2) is the stretch.
 The compiled recurrence network should be the reference that scores 1, because `RecurrenceCompiler` already makes a network that follows the rule for any start it is built with.
 
-Where: new `SNP_Evolution/Evolution/Tasks/RecurrenceTask.cs`; `SNP_Evolution/Evolution/Tasks/SequenceTask.cs`, `SNP_Evolution/Evolution/Tasks/TriggeredSequenceTask.cs`, `SNP_Evolution/Compilation/Recurrence.cs`, `SNP_Evolution/Compilation/RecurrenceCompiler.cs`, `SNP_Evolution/Evolution/Tasks/TaskSuite.cs`; the spec type from this epic.
+Where: new `Specs/Tasks/RecurrenceTask.cs`; `Specs/Tasks/SequenceTask.cs`, `Specs/Tasks/TriggeredSequenceTask.cs`, `Compilation/Recurrence.cs`, `Compilation/RecurrenceCompiler.cs`, `Search/Benchmarking/TaskSuite.cs`; the spec type from this epic.
 
 Done when:
 - [ ] A network that lists the 16 Fibonacci gaps from 1,1 scores below 0.5 on the held-out cases

.github/tickets/m4/m4-p1-3-relation-specs.md

@@ -20,7 +20,7 @@ Every computation should have to satisfy the checker, not just one, because a pa
 A spec with no solution for an input should say so in its domain, and the part should answer on its no-answer done port, because a part that never fires done cannot be composed.
 The checker should not be used to make expected values for the case text, because two parts that give different valid answers read differently but are both right.
 
-Where: the spec type from this epic; `SNP_Evolution/Evolution/Tasks/ContractTask.cs`, `SNP_Evolution/Evolution/Contracts/BoundedCheck.cs`, `SNP_Evolution/Evolution/Contracts/Specification.cs`, `SNP_Evolution/Simulation/ExhaustiveCpuEngine.cs`.
+Where: the spec type from this epic; `Specs/Tasks/ContractTask.cs`, `Specs/Verification/BoundedCheck.cs`, `Specs/Contracts/Specification.cs`, `Simulation/ExhaustiveCpuEngine.cs`.
 
 Done when:
 - [ ] A "some divisor of n other than 1 and n, or no answer" spec scores a hand-built nondeterministic network as solved when every computation gives a valid divisor