4040├── data-raw/
4141│ ├── pars/ # PARS submissions + manifest + reference-code snapshot/supplement
4242│ └── pars/_rejected/ # excluded historical submissions (not loaded)
43- ├── data/pacm/ # generated theme files (published output)
43+ ├── output/
44+ │ ├── www/ # generated theme files (published output; ../public/data symlinks here)
45+ │ └── export/ # flat CSV exports (never published)
4446└── tests/testthat/ # unit + characterization tests
4547```
4648
4749## Building
4850
4951``` r
5052# in R, from r/
51- targets :: tar_make() # full build; writes data/pacm /<theme>/*.json
53+ targets :: tar_make() # full build; writes output/www /<theme>/*.json
5254targets :: tar_outdated() # what would rebuild
5355```
5456
55- ``` sh
56- scripts/copy-data.sh # publish data/pacm/* to ../public/data/ and enum JSONs to ../src/lib/
57- ```
57+ There is no separate publish step: ` ../public/data ` is a symlink to
58+ ` output/www ` , so the app serves ` tar_make() ` output directly (the app fetches
59+ everything it needs from there at runtime, including ` species.json ` and
60+ ` platform_types.json ` ).
5861
5962Makara connection details are read from ` .env ` (` MAKARA_* ` ). The PARS path needs
6063** no database** — its reference vocabulary is a vendored snapshot
@@ -74,12 +77,13 @@ dataset** (`pacm_data`) as flat CSVs — one per table — for downstream analys
7477
7578``` r
7679# in R, from r/
77- tar_make(export ) # builds all six CSVs into data /export/
80+ tar_make(export ) # builds all six CSVs into output /export/
7881```
7982
80- Output goes to ` data/export/ ` , a ** sibling** of ` data/pacm/ ` . ` copy-data.sh ` and
81- ` deploy-data.sh ` act on ` data/pacm/* ` , so these exports are ** never** published to
82- the app or the GCS tarball. Individual tables build via their file targets
83+ Output goes to ` output/export/ ` , a ** sibling** of ` output/www/ ` . ` deploy-data.sh `
84+ and the app (which serves ` output/www ` via the ` ../public/data ` symlink) act on
85+ ` output/www/* ` only, so these exports are ** never** published to the app or the
86+ GCS tarball. Individual tables build via their file targets
8387(` export_deployments_file ` , ` export_analyses_file ` , …).
8488
8589| File | Grain | ` submission_id ` ? |
@@ -100,7 +104,7 @@ deployments/analyses), so they carry no `submission_id` — recover it by joinin
100104
101105Because ` submission_id ` reaches the app files only through frames the theme
102106writers build with explicit column lists (which omit it), the published
103- ` data/pacm /**` output is unchanged by these exports — see the export functions in
107+ ` output/www /**` output is unchanged by these exports — see the export functions in
104108[ ` R/export.R ` ] ( R/export.R ) .
105109
106110---
@@ -125,9 +129,9 @@ takes four steps and **no code**:
125129# 3. load it and confirm it validates clean (in R, from r/)
126130make_pars(" <submission_id>"
127131tar_read(pars_errors ) # must be 0 rows
128- # 4. rebuild + publish
129- tar_make() # regenerates data/pacm /<theme>/*.json
130- # then, in shell: scripts/copy-data.sh
132+ # 4. rebuild
133+ tar_make() # regenerates output/www /<theme>/*.json
134+ # (../public/data symlinks to output/www, so the app picks this up directly)
131135```
132136
133137If validation reports errors that are genuine data problems in the submission,
@@ -326,20 +330,19 @@ Retire a supplement code once it is adopted upstream.
326330#### 6. Rebuild and publish
327331
328332``` r
329- tar_make() # rebuilds pacm_data and the theme files under data/pacm /
333+ tar_make() # rebuilds pacm_data and the theme files under output/www /
330334```
331335
332336` tar_make() ` regenerates
333- ` data/pacm/<theme>/{sites,deployments,detections,tracks}.json ` via the
334- ` pacm_themes_files ` target. To push them to the app:
335-
336- ``` sh
337- scripts/copy-data.sh # copies data/pacm/* -> ../public/data/, and the two enum JSONs -> ../src/lib/
338- ```
337+ ` output/www/<theme>/{sites,deployments,detections,tracks}.json ` via the
338+ ` pacm_themes_files ` target. ` ../public/data ` is a symlink to ` output/www ` , so
339+ the app serves the rebuilt files directly — no publish step.
339340
340- Then verify in the running app. New PARS reference values (species, platform
341- types, and any new supplement codes) may also need syncing into the web-app enums
342- — see ` ../src/lib/constants.js ` and the ` ../scripts/check-codes.mjs ` assertion.
341+ Then verify in the running app. The app fetches ` species.json ` and
342+ ` platform_types.json ` from the data directory at startup, so new species and
343+ platform-type labels travel with the data automatically. A new * theme* still
344+ needs a menu entry in ` ../src/lib/constants.js ` — the
345+ ` ../scripts/check-codes.mjs ` assertion checks both.
343346
344347### The ` tar_cue(mode = "never") ` pattern
345348
@@ -379,7 +382,7 @@ why editing `pars-load.R` does not silently re-parse every historical submission
379382| Inspect reference-code drift (needs DB) | ` tar_read(pars_codes_drift) ` |
380383| Regenerate the vendored snapshot (needs DB) | ` refresh_reference_code_snapshot() ` |
381384| Full rebuild + write theme files | ` tar_make() ` |
382- | Publish to the app (shell) | ` scripts/copy- data.sh ` |
385+ | Publish to the app | nothing — ` ../public/ data` symlinks to ` output/www ` |
383386
384387### Current submissions
385388
0 commit comments