EXPERTA

1Context

Alan R. Vazquez answered the alpha review questions on 2026-10-19 (GitHub issues #7 to #65, label alpha-review, all on commit a3790d3). node scripts/export-review.mjs reads 60 answers, of which 55 count. The answers sort into four groups:

His "Other comments" answer (#65) proposes to tailor EXPERTA to one field of application (for example biotechnology, the food industry or manufacturing), because the readers of JQT and Quality Engineering already know FrF2. He will search for papers on applications to choose the field. This is a decision of both authors and is not part of this plan (decision F13).

Measurements made for this plan (FrF2 2.3.5, native R 4.6.1; scripts and output in replication_materials/plans/review-fixes-probes/):

• all-2fis-clear.R: in entry 9-4.1 (9 factors, 32 runs) factor 9 is in no 2FI alias chain, so it has all 2FIs clear, and it is the only such factor of that design. 21 of the 327 entries whose name ends in .1 have some, but not all, factors with this property, for example 7-2.1 (factors 4, 5, 7) and 8-3.1 (factors 5, 8).
• rank1-ties.R: the 19 entries that share rank 1 are all the catalogue entries of five sizes: 128 runs with 41, 42, 43, 44 and 50 factors. FrF2 selects the first of them (for example 41-34.1a). In each size the entries have equal distance distributions of the rows, so their word length patterns are equal at every length (MacWilliams identities).
• wlp-error-defaults.R: two FrF2 defaults have a stored WLP error, 21-16.1 and 22-17.1 (32 runs). The error is a split number (A6 = 1608 is stored as 160 and 8). By the computed WLP, each .1 entry has less aberration than all other catalogue entries of its size (50 and 34 entries). The five other defaults with a stored WLP error are 20-8.1 to 24-12.1 in 4096 runs (the stored WLP is wrong from A13).
• xu2009-128-runs.R (128 runs, 25 to 39 factors): Xu (2009, Section 4) enumerates all odd 128-run designs of resolution IV, which exist only up to 40 factors. He finds that the odd designs of Block and Mee (2005) are complete, and he lists all MA and weak MA designs up to 40 factors (Table 9 of the preprint of 2007-09-28). The probe builds each of his MA designs from the printed columns. For every size from 25 to 40 factors, the FrF2 .1 entry has the same distance distribution, so the same word length pattern at every length. A4 to A6 also equal the printed values, which checks the transcription. A literature check found no report of a better design for these sizes. For 25 to 33 factors the MA status rests on Xu's computer enumeration only. For 1024, 2048 and 4096 runs, Xu (2009) shows MA up to 24, 23 and 24 factors, and Ryan and Bulutoglu (2010) add the sizes up to 28, 32 and 26 factors, so the sources of these regions are correct.

Goal: The app makes the MA and "good" claims that the review supports, uses the glossary texts and references that Alan R. Vazquez gave, and asks him again, on the review page, only the questions that are still open.

Architecture: The claim of a design is a new field catalogue.claim of the R report (MA, good, full_factorial or none), computed in r/ffd_report.R from the guarantee class, the size and a reviewed range for each region. The statement comes from the claim. The report version becomes 1.3.0, so stored projects rebuild with the existing rule (spec 8.1). The review page gets a list of questions that are asked again: answers filed before the question changed show as earlier answers and do not count.

Tech Stack: R 4.6.1 with FrF2 2.3.5 and DoE.base, WebR 0.6.0, Next.js 16.3.8, React 19.3.0, TypeScript 5.9.3, zod 4.6.5, vitest 4.1.11, Playwright 1.63.0. No new package.

Spec: replication_materials/plans/2026-10-14-ff-design-translator-design.md (version 7; Task 5 makes version 8), Sections 1.8, 7.7, 8.1, 9.5, 14.4, 17.1 and 19.

2Decisions

Exact texts used by the tasks:

• Claim statements (F1, F4, and unchanged ones): MA → "Minimum aberration design from the FrF2 catalogue, entry {name}."; good → "Design from the FrF2 catalogue, entry {name}. FrF2 lists it as good, not necessarily minimum aberration."; full_factorial → "Full factorial design ({n} runs)."; none with an entry → "Design from the FrF2 catalogue, entry {name}."; none without an entry → "Design not from the FrF2 catalogue."
• Glossary generators: replace "equal to the product of some base factor columns" with "equal to the element-wise product of some base factor columns". Nothing else changes.
• Glossary clear_2fis: replace "The definition comes from FrF2 and does not take interactions of three or more factors into account." with "The definition comes from FrF2 and does not take interactions of three or more factors into account, assuming the principle of hierarchy. This principle states that main effects and two-factor interactions are more important than higher-order effects."
• Glossary effect_heredity (and spec 1.8): "Strong heredity: an interaction is more likely to be active if the main effects of all its factors are active. Weak heredity: an interaction is more likely to be active if the main effect of one of its factors is active."
• Glossary all_2fis_clear: "A factor has all 2FIs clear if every 2FI that contains the factor is clear. For example, in the FrF2 design for 9 factors in 32 runs (entry 9-4.1), no 2FI that contains factor 9 is aliased with a main effect or with another 2FI. So factor 9 has this property, and the other 8 factors do not. Other designs also have such factors, for example factors 4, 5 and 7 of entry 7-2.1 and factors 5 and 8 of entry 8-3.1 (both 32 runs). The factor order in step 2 sets which named factors have this property. In a design of resolution V or higher, and in a full factorial, every factor has this property."
• Glossary guarantee: "A minimum aberration (MA) design minimizes (A_3) first, then (A_4), and so on, among the designs of the same size. FrF2 selects each fractional design from its catalogue. The statement gives what a reviewed source supports for the selected entry. An MA entry gets "Minimum aberration design from the FrF2 catalogue, entry 7-3.1." A good design gets "Design from the FrF2 catalogue, entry 29-19. FrF2 lists it as good, not necessarily minimum aberration." Other entries get only the entry name. The statement also holds with center points, with replications and for a request that gives only a resolution." Reference: "Wu and Hamada (2021), Chapter 5; Groemping (2014); Xu (2009); Ryan and Bulutoglu (2010); Mee (2009)".
• References (glossary and spec 19):
  • "Mee, R. W. (2009). A comprehensive guide to factorial two-level experimentation. Springer." https://doi.org/10.1007/b105081
  • "Ryan, K. J., and Bulutoglu, D. A. (2010). Minimum aberration fractional factorial designs with large N. Technometrics, 52(2), 250-255." https://doi.org/10.1198/TECH.2010.08020
  • "Xu, H. (2009). Algorithmic construction of efficient fractional factorial designs with large run sizes. Technometrics, 51(3), 262-277." https://doi.org/10.1198/TECH.2009.07120
• Review page, region question asked again (guarantee.region.128.25-64), context paragraphs: "Your answer of 2026-10-19 confirms 40 to 64 factors." / "For 25 to 39 factors, Xu (2009, Section 4) enumerates all odd 128-run designs of resolution IV, which exist only up to 40 factors, and finds that the odd designs of Block and Mee (2005) are complete. His table gives all MA and weak MA designs up to 40 factors. For each size from 25 to 40 factors, the first-ranked FrF2 entry has the same word length pattern at every length as the MA design in his table." / "The tool now makes the MA claim for 25 to 64 factors. For 25 to 40 factors, it also checks each design when it makes it: the word length pattern of the design must equal the pattern of Xu's MA design of that size, which the tool builds from his printed columns. If the check fails, the statement names only the entry." Question: "Do you agree with the MA claim for 25 to 39 factors in 128 runs?"
• Review page, guarantee.no-claim, title "Claims for the other catalogue entries", context paragraphs: "After your answers, the tool makes these four claims." / "1. The 19 entries that share rank 1 (128 runs with 41, 42, 43, 44 and 50 factors, names such as 41-34.1a) get the MA statement. They are the only catalogue entries of their size. Your answer calls the 128-run designs with 40 to 64 factors MA. The entries of each size have equal word length patterns at every length, computed from the design matrix." / "2. The entries without a running number (for example 29-19 in 1024 runs) and the 12 entries 69-61.1 to 80-72.1 in 256 runs get the statement for good designs." / "3. 21-16.1 and 22-17.1 (32 runs) get the MA statement. Their stored word length pattern is wrong only because one number is split in two (1608 is stored as 160 and 8). By the computed pattern, each has less aberration than every other catalogue entry of its size." / "4. The 4096-run entries 20-8.1 to 24-12.1 get only the entry name. Their stored pattern is wrong from (A_{13}), and the catalogue does not list every 4096-run design." Question: "Do you agree with these four claims? If not, give the number of the claim in the comment."
• Review page, earlier answer line: "Earlier answer, before this question changed: {choice label} ({date}, {name})."
• Review page, intro sentence after the existing one: "Four questions are asked again after the answers of 2026-10-19. An earlier answer shows under each of them and does not count."
• Known issues (replaces the glossary item): 'Two glossary entries, "Guarantee statement" and "Factors with all 2FIs clear", show "Draft, not yet reviewed" until they are answered again.'

3Global Constraints

• Branch. Work on review-fixes, made from project-pages (head 417faf4), because replication_materials/project/roadmap.json and the project site exist only there. Its pull request to main follows the merge of project-pages.
• No package changes. Implementers do not run npm install or npm ci (Dropbox). npm run setup:runtimes is allowed: it copies r/ into the git-ignored public/r/.
• Secrets and outside contact. Never read .env. Subagents make no network call to Vercel, Upstash, GitHub or an LLM provider. The secret scan runs only as node scripts/secret-scan.mjs --env <a made-up file>.
• R. Native R is C:/Program Files/R/R-4.6.1/bin/Rscript.exe (scripts/lib/rscript.mjs). Never pass several statements in one Rscript -e; run a script file.
• Texts. The texts of this plan are exact. The other glossary entries, the R23 text and the other question texts do not change. About 80% ASD-STE100, plain academic tone.
• Generated files. data/guarantee-table.json and data/catalogue-summary.json come only from scripts/build-catalogue.R; data/glossary.json only from node scripts/build-glossary.mjs. Never edit them by hand.
• Tests. All in replication_materials/tests/. Test first. npm run check -- --fast after each task; npm run check after Tasks 2, 4 and 5.
• Commits. One or more per task, each ending with the attribution lines of the session (Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> and the Claude-Session: line), whatever model runs the task.

4Review Focus

1. The boundaries of the 128-run regions and of the reference check: 24, 25, 40, 41, 64 and 65 factors all give MA, with basis region, region_and_reference_wlp (25 and 40), region_and_equal_wlp_tie (41) and region; a design of 30 factors whose WLP differs from Xu's gives none. Test in Task 1.
2. A design with center points or replications, and a request with only a resolution: the claim of the selected entry stays (Alan's answer #49). Test in Task 1.
3. A stored or imported project with a report of version 1.2.0: it rebuilds to 1.3.0 and shows the new statement; when the rebuilt run sheet differs, the existing rule applies unchanged. Test in Task 2.
4. An answer filed before a question was asked again, and one after it: only the later one counts, on the page, in the server read-back and in the CSV export; "Other comments" keeps every answer. Test in Task 4.
5. A tie entry or an errata entry selected by a request: the report of 41 factors in 128 runs and of 21 factors in 32 runs passes all post-checks and shows the MA statement. Test in Task 1.

5Task 1: Claims in the R report and the guarantee table

Files:

• Modify: r/ffd_report.R (the regions table, ffd_guarantee_claim(), ffd_guarantee_statement(), the catalogue part of the report, FFD_REPORT_VERSION), scripts/build-catalogue.R, r/README.md
• Rebuild: data/guarantee-table.json, data/catalogue-summary.json
• Test: replication_materials/tests/r/test-guarantee.R, replication_materials/tests/r/test-report.R, create replication_materials/tests/r/test-guarantee-evidence.R

Interfaces:

• Produces: FFD_REPORT_VERSION <- "1.3.0"; FFD_MA_REGIONS gains reviewed_min and reviewed_max (the full range of each of the 13 regions; a later review can narrow one); FFD_ERRATA_MA <- c("21-16.1", "22-17.1"); FFD_XU2009_128, a named list "25" to "40" of the added columns of Xu's MA designs, copied from replication_materials/plans/review-fixes-probes/xu2009-128-runs.R with a comment that names the source (Table 9 of the preprint of 2007-09-28); ffd_reference_wlp(nruns, nfac) builds that design (independent columns 1, 2, 4, ..., 64 in Yates order) and returns its WLP from the same WLP function as the report (spec 7.6), or NULL outside 128 runs with 25 to 40 factors; ffd_guarantee_claim(class, entry_name, nruns, nfac, wlp) returns list(claim, basis), with claim one of "MA", "good", "full_factorial", "none" and basis one of "full_factorial", "region", "region_and_reference_wlp", "reference_wlp_differs", "region_and_equal_wlp_tie", "errata_verified", "frf2_good", "none"; ffd_guarantee_statement(claim, entry_name, nruns); the report's catalogue gets claim and claim_basis (strings, unboxed). guarantee-table.json: top-level review becomes { status: "partial", reviewer: "Alan R. Vazquez", reviewed_on: "2026-10-19", answers: "GitHub issues #7 to #65 (label alpha-review), commit a3790d3" }, each region gets reviewed_min and reviewed_max, and each entry gets claim and claim_basis. build-catalogue.R computes the WLP only for the entries that need the reference check.

• Step 1: Write the failing R tests. In test-guarantee.R, replace "statements make no MA claim before the review" with: the claim and statement of 7-3.1 (16, 7) are MA and the MA sentence; 41-34.1a (128, 41) MA; 21-16.1 with class stored_wlp_error MA; 20-8.1 with class stored_wlp_error none; 29-19 (1024, 29) good with the good sentence; 69-61.1 (256, 69) good; 7-3.2 none; broken_entry none; a full factorial full_factorial with "Full factorial design (16 runs)."; no entry none with "Design not from the FrF2 catalogue."; the 128-run boundaries of Review Focus 1; ffd_reference_wlp(128, 30) has A4 to A6 equal to 335, 972, 4662 (Xu's printed values) and ffd_reference_wlp(128, 41) and ffd_reference_wlp(64, 30) are NULL; for 30-23.1 a WLP equal to the reference gives MA with basis region_and_reference_wlp, and the same WLP with A6 plus 1 gives none with basis reference_wlp_differs. Add a count test over data/guarantee-table.json: claims MA 327, good 235, none 2537, total 3099 (MA: the 306 entries of class MA, the 19 ties and the 2 errata entries; none: 2,443 ranked after the first, 87 stored-WLP errors and 7 broken entries). In test-report.R, the coating report (7-3.1) has the MA sentence and claim == "MA"; a 7-factor 16-run design with 2 center points and one with 2 replications keep it; reports of 41 factors in 128 runs and 21 factors in 32 runs pass all checks with the MA sentence. In test-guarantee-evidence.R, copy the checks of rank1-ties.R (equal distance distributions in each tie size) and of wlp-error-defaults.R (the .1 entry is best by computed WLP), as testthat tests.
• Step 2: Run node scripts/run-r-tests.mjs (or the R test runner the repository uses). Expected: the new tests fail (no claim, old statements, old counts).
• Step 3: Implement the interfaces. ffd_guarantee_claim follows this order: full_factorial class → full_factorial; class MA or rank1_tie and nfac inside the reviewed range of the region of its size → if ffd_reference_wlp(nruns, nfac) is not NULL, MA (basis region_and_reference_wlp) when wlp equals it at every length and none (basis reference_wlp_differs) otherwise, including a missing wlp; else MA (basis region_and_equal_wlp_tie for a tie, region otherwise); class stored_wlp_error and the name in FFD_ERRATA_MA → MA (errata_verified); class catalogue_not_MA or rank1_outside_documented_region → good (frf2_good); otherwise none. The report passes the WLP it computed from the design matrix (the cube points). Update the comments ("Review by Alan R. Vazquez is pending" goes) and r/README.md. Run "C:/Program Files/R/R-4.6.1/bin/Rscript.exe" scripts/build-catalogue.R.
• Step 4: Run the R tests again. Expected: all pass. Run npm run setup:runtimes, then npm run check -- --fast.
• Step 5: Commit feat: the MA and good claims after the review by Alan R. Vazquez (report 1.3.0).

6Task 2: The app side of report 1.3.0

Files:

• Modify: lib/report/types.ts (REPORT_VERSION = "1.3.0", catalogue.claim: z.enum(["MA", "good", "full_factorial", "none"]), catalogue.claim_basis: z.string()), the report fixtures in replication_materials/tests/fixtures/reports/ (made again with replication_materials/tests/fixtures/make-report-fixtures.R) and replication_materials/tests/fixtures/large-report.ts
• Test: every test that pins the report version "1.2.0" (on 2026-10-19: records.spec.ts:41,43, worker.spec.ts:14, engine-client.test.ts:7, rebuild.test.ts:7-8, report-html.test.ts:108, projects.test.ts:155, exports-xlsx.test.ts:63; search again with grep -rn '1\.2\.0' replication_materials/tests), plus report-types.test.ts and design.spec.ts:27

Interfaces:

• Consumes: the R report of Task 1.
• Produces: report.catalogue.claim and report.catalogue.claim_basis for Phase 2 and the benchmarks.

• Step 1: Write the failing tests. report-types.test.ts: the schema accepts the four claims and refuses another value; REPORT_VERSION equals FFD_REPORT_VERSION (the test exists; it now fails until the TS constant changes). design.spec.ts:27: step 3 shows "Minimum aberration design from the FrF2 catalogue, entry 7-3.1.". report-html.test.ts: the report shows the MA sentence for the coating fixture. records.spec.ts (the rebuild test): a stored project with a 1.2.0 report shows the rebuild note, then "The report was updated to version 1.3.0. The rebuilt design matches the stored run sheet (SHA-256)." and the MA sentence. The other pinned versions change to "1.3.0" where they name the current version; a test that needs an older report keeps "1.2.0" as the older one.
• Step 2: Run the focused unit tests and npx playwright test design.spec.ts. Expected: FAIL on the version, the schema and the statement.
• Step 3: Implement. Change the constant and the schema; make the fixtures again from R; keep a 1.2.0 fixture for the rebuild test.
• Step 4: Run npm run check. Expected: all pass.
• Step 5: Commit feat: report 1.3.0 in the app: the claim field, the new statements and the rebuild of older reports.

7Task 3: Glossary texts, review dates and references

Files:

• Modify: content/glossary.json, lib/review/known-issues.ts
• Rebuild: data/glossary.json (node scripts/build-glossary.mjs)
• Test: replication_materials/tests/unit/glossary.test.ts, replication_materials/tests/unit/review/known-issues.test.ts

Interfaces:

• Produces: the five texts and three references of the "Exact texts" list; reviewed_by/reviewed_on on 33 entries; all_2fis_clear and guarantee keep null.

• Step 1: Write the failing tests. glossary.test.ts: exactly 33 entries have reviewed_by: "Alan R. Vazquez" and reviewed_on: "2026-10-19"; the two drafts are all_2fis_clear and guarantee; the five texts equal the exact texts; the references include the three new keys "Mee (2009)", "Ryan and Bulutoglu (2010)", "Xu (2009)" with their citations and DOI URLs, in alphabetical order of the key with the others; the guarantee entry cites the three new keys. (Ockuly et al. (2017) stays in the list, as today, although no entry cites it: spec Section 1.8 cites it.) known-issues.test.ts: the new item text.
• Step 2: Run npx vitest run --project unit replication_materials/tests/unit/glossary.test.ts replication_materials/tests/unit/review/known-issues.test.ts. Expected: FAIL.
• Step 3: Implement. Edit content/glossary.json and its note (the review is recorded per entry), then node scripts/build-glossary.mjs. Edit the known issues.
• Step 4: Run the focused tests and FFD_RELEASE=1 npx vitest run --project unit replication_materials/tests/unit/glossary.test.ts. Expected: the focused tests pass; the release gate fails only for the 2 drafts (record the count in the report). Then npm run check -- --fast.
• Step 5: Commit feat: the glossary after the review: Alan R. Vazquez's texts, 33 reviewed entries and three references.

8Task 4: Questions asked again on the review page

Files:

• Create: data/review-asked-again.json ({ "after": 65, "questions": ["guarantee.region.128.25-64", "guarantee.no-claim", "glossary.all_2fis_clear", "glossary.guarantee"] })
• Modify: lib/review/questions.ts (new contexts, title and question of F6), lib/review/answer.ts (latestAnswers), components/review/QuestionCard.tsx, components/review/ReviewPage.tsx (intro sentence; progress and "Show only questions without an answer" use the counted answers), scripts/export-review.mjs (the counted column reads the same JSON)
• Test: replication_materials/tests/unit/review/questions.test.ts, answer.test.ts, export.test.ts, replication_materials/tests/e2e/review.spec.ts

Interfaces:

• Produces: StoredAnswer gains earlier: boolean; latestAnswers returns for a question that is asked again the newest answer with an issue number above after (not earlier), followed by the newest answer at or below it (earlier: true), and only these two; a question with only earlier answers has no counted answer. answeredIds(answers) (exported) gives the ids with a counted answer. "Other comments" keeps every answer.

• Step 1: Write the failing tests. answer.test.ts: for guarantee.no-claim, issues #63 (not_sure) and #70 (agree) → counted agree and earlier not_sure; only #63 → no counted answer and one earlier; a question not asked again keeps the old rule. questions.test.ts: the four questions have the exact texts; 55 questions still; the asked-again ids exist. export.test.ts: #63 has counted: no when the JSON names it; #70 has counted: yes. review.spec.ts (mocked API as today): the asked-again card shows the earlier answer line and counts as open; "Show only questions without an answer" shows the four asked-again cards and the cards without answers.
• Step 2: Run the focused tests. Expected: FAIL.
• Step 3: Implement. The export script reads the JSON with readFileSync (it cannot import the TS question list). Keep the fixed messages of lib/review/answer.ts.
• Step 4: Run npm run check. Expected: all pass.
• Step 5: Commit feat: the review page asks four questions again and counts only the later answers.

9Task 5: Specification version 8 and the records

Files:

• Modify: replication_materials/plans/2026-10-14-ff-design-translator-design.md (Version row; Section 1.8 heredity text; Section 7.7: the claims, the reviewed ranges, the statements and the review outcome of F1 to F7; Section 8.1: report 1.3.0; Section 9.5: 33 reviewed entries; Section 14.4: the questions asked again; Section 17.1: the guarantee and glossary rows say what is done and what is asked again, the R23 and references rows are done, a new row for F13, the row "The scope of the paper" is answered by F14, the refused defaults wait for Alan's revision of the FrF2 findings, and Section 7.7 describes the reference check of F2; Section 19: Mee (2009), and the DOIs of Xu (2009) and Ryan and Bulutoglu (2010)), replication_materials/process/process.json (event e34), replication_materials/project/roadmap.json (milestone review: state now, documents, blockers), README.md (Status, one sentence)
• Rebuild: replication_materials/plans/spec-page/ (node scripts/build-spec-page.mjs), the plan page replication_materials/plans/review-fixes-plan-page/
• Test: the existing record tests (npx vitest run --project unit replication_materials/tests/unit/project-site/) and the spec page test

• Step 1: Edit the spec with the decisions F1 to F13 and the exact texts, in the style of the spec (no new vocabulary). The review milestone of roadmap.json lists the plan and its ledger; the blockers are: the four questions asked again and the FrF2 findings (Alan), the Upstash check (Fadel), and this plan (Claude).
• Step 2: Run node scripts/build-spec-page.mjs, the build of the plan page with --milestone "Alan's review and the fixes" --status "Done; merge pending", node scripts/build-project-site.mjs --offline --out <temp folder>, and the unit tests. Expected: all pass, and the progress page lists the four asked-again questions under the next milestone.
• Step 3: Run npm run check. Expected: all pass.
• Step 4: Commit docs: specification version 8 and the records of the review fixes.

10After the plan (needs approval for each step)

1. Merge of project-pages (its own pull request; the app does not change), then the pull request of review-fixes to main, merge, deployment to production. Checks on https://expertadoe.app: step 3 of a 7-factor 16-run design shows the MA sentence; site.spec with FFD_EXPECT_CSP=1; GET /api/review without the key gives 401.
2. Close the issues whose answer the app now applies, with a link to the pull request. The issues of the four questions asked again and of the refused defaults stay open. A closed issue still counts on the review page (spec 14.4).
3. Fadel tells Alan once that four questions are asked again and that his texts are in the app (one message, as agreed).
4. The switch-on of the project pages (its own plan checkpoint), then Milestone 4.