--- title: CHANGELOG slug: changelog layer: GOVERNANCE layer_order: 1 order: 81 description: Chronological record of all protocol decisions, infrastructure changes, and version releases in the FLUX archive system. --- > **FLUX DOCUMENTATION SYSTEM** > Layer 9 — GOVERNANCE | changelog > flux.dantesisofo.com/wiki/changelog/ # CHANGELOG A complete chronological record of protocol decisions, infrastructure changes, and version releases. All dates are in ISO 8601. All decisions are final unless explicitly marked DEPRECATED or PROPOSED. --- ## v1.0 — ARCHIVE LAUNCH Released: 2026-05-13 ### Protocol - `FRAMES_PER_ISSUE = 36` locked as a protocol constant in `flux_constants.py`. Comment added: "Do not change without updating all dependent scripts." This value is immutable. - Canonical filename convention established: `YYYY-MM-DD_HH-MM-SS_PhotographerName_OriginalFilename.JPG`. Separator between date-time block and photographer name is underscore. Separator between photographer name and original filename is underscore. Timestamp uses hyphens within date (`YYYY-MM-DD`) and hyphens within time (`HH-MM-SS`), with underscore between date and time blocks (not ISO 8601 `T`). - Contact sheet grid locked: 6×6 = 36 cells. One cell per frame. Grid is square. - Manifest format locked: 2 columns × 18 rows = 36 entries per manifest page. ### PDF Standard - PDF structure locked at 44 pages total. Page assignments: - Page 1: front cover - Page 2: blank (IFC — inside front cover) - Page 3: protocol page - Page 4: blank - Pages 5–40: 36 photographs (one per page) - Page 41: parity pad - Page 42: contact sheet (6×6 grid) - Page 43: manifest (2 columns × 18 rows) - Page 44: blank back cover - Total page count: 44. This is a protocol constant. ### Infrastructure - S3 namespace defined: personal photos stored at `photos/` prefix, thumbnails at `thumbs/`, personal issues at `FLUX_ISSUES/`. - S3 bucket: `flux-dantesisofo`. CloudFront distribution: `E1QJZ6W1R67CZD`. - Site live at `flux.dantesisofo.com`. --- ## v1.1 — PUBLIC CATALOG Released: 2026-05-14 ### Protocol - CAT_NNN namespace established. Public catalog identifiers (`CAT_001`, `CAT_002`, ...) are separated from personal archive identifiers (`FLUX_001`, `FLUX_002`, ...). The two namespaces do not overlap and never will. - `catalog.json` established as the single source of truth for all public catalog entries. All catalog reads and writes go through this file. ### Infrastructure - `publish_submission.py` created. Implements the full public submission pipeline: 1. Receive submission ZIP 2. Validate ZIP contents (exactly 36 JPEGs, valid filenames, valid EXIF) 3. Extract and rename photographs to canonical filename format 4. Generate FLUX PDF (44 pages, full protocol structure) 5. Upload PDF and photographs to S3 6. Update `catalog.json` 7. Return CAT_NNN identifier to submitter - `FLUX_CATALOG/` S3 prefix established for all public catalog assets. This prefix is distinct from `FLUX_ISSUES/` used for personal archive issues. - Public catalog generator launched: any photographer can generate a FLUX issue from their own photographs without creating an account. --- ## v1.2 — PHYSICAL CALIBRATION Released: 2026-05-15 ### PDF Standard - Gutter compensation added to physical PDF generation. Inner margins on spread pages are shifted to account for saddle-stitch binding. Calibrated against physical output on Brother laser printer. Gutter offset is hardcoded in `generate_flux_issue.py`. - Physical print pipeline tested end-to-end: PDF generation → print → fold → staple. Human stapling confirmed as final assembly step. No automated stapling. ### Infrastructure - Auto-generation trigger implemented in `approve_worker.py` via `_maybe_trigger_build()`. Logic: when the count of unassigned approved photographs in the queue reaches `FRAMES_PER_ISSUE` (36), `issue_builder_worker.py` is spawned as a detached subprocess. The trigger fires at exactly 36. It does not fire at 35. - File lock at `/tmp/flux_issue_builder.lock` prevents duplicate builder runs. If the lock file exists when the trigger fires, the new build is skipped. The lock is released when the builder process exits normally or abnormally. - `issue_builder_worker.py` confirmed as the canonical auto-generation entry point. --- ## v1.3 — CATALOG STABILITY Released: 2026-05-19 ### Infrastructure - **Bug fixed:** `_next_catalog_id()` was computing the next catalog ID by reading `max(catalog.json entries) + 1`. This was incorrect because `catalog.json` was not always current with S3. The bug caused new entries to reuse existing CAT IDs, overwriting previous catalog records. - **Fix applied:** `_next_catalog_id()` now scans S3 `FLUX_CATALOG/` folder prefixes directly (`ListObjectsV2` with `Delimiter='/'`) to determine the highest existing `CAT_NNN/` prefix. The computed next ID is `max(existing_prefixes) + 1`. `catalog.json` is not consulted for ID generation. - **Bug fixed:** `_save_catalog()` was writing `catalog.json` to local disk only. S3 upload was deferred and sometimes skipped. This created divergence between local and S3 state. - **Fix applied:** `_save_catalog()` now uploads `catalog.json` to S3 immediately on every write, before returning. S3 is always current. - **Bug fixed:** `_load_catalog()` was preferring local disk over S3. If local disk was stale, stale data was used for all subsequent operations. - **Fix applied:** `_load_catalog()` now loads both local and S3 versions. Whichever version has more entries is used. The local disk version is updated to match S3 after load. ### Recovery - CAT_002 and CAT_003 were overwritten by the `_next_catalog_id()` bug. Both entries were recovered from S3 object versioning (S3 versioning was enabled on the bucket). S3 versioning is confirmed as a safety net for the catalog. - Catalog integrity audit performed. All 18 entries verified: CAT_001–CAT_018. - Igor Krivokon (Edgelands) = CAT_017. James B (San Antonio) = CAT_018. Both entries confirmed. ### Protocol - Catalog count as of 2026-05-19: 18 entries (CAT_001–CAT_018). --- ## v2.0 — DOCUMENTATION ARCHITECTURE Released: 2026-05-20 ### Documentation - FLUX_WIKI restructured from a flat collection of pages to an 8-layer protocol documentation system (FLUX_WIKI v2.0). Layer assignments established. Each document assigned to a layer, layer_order, and global order. - New layer added: INTELLIGENCE (Layer 5). `intelligence.md` created as layer overview. Intelligence subdocuments created: `embeddings.md`, `keeper-model.md`, `metadata-enrichment.md`, `autonomous-sequencing.md`, `training-data.md`. - New layer added: GOVERNANCE (Layer 9). `changelog.md`, `decisions-log.md`, `versions.md` created. - New layer added: OPEN SOURCE (Layer 10). `open-source.md` created. - `generate_wiki.py` updated: `LAYER_ORDER` list extended to 10 layers. ### Infrastructure - **Hardware ordered 2026-05-20:** - Apple Mac mini M4 Pro — designated compute node for all FLUX processing, PDF generation, and ingest pipeline - Synology NAS — primary storage, 2x mirrored IronWolf drives. NAS becomes the canonical archive root. - Storage architecture formalized: - NAS = canonical archive root (primary, mirrored) - Mac mini = compute node (processing, no primary storage) - S3 = public distribution (CloudFront CDN, public access) - NAS folder structure defined: ``` /FLUX_ARCHIVE/ — full photographic corpus (~400,000 frames + keepers) /FLUX_SYSTEM/ — scripts, configuration, code /FLUX_PUBLIC/ — public-facing assets mirrored to S3 /FLUX_METADATA/ — SQLite database, manifests, CSV exports /FLUX_EMBEDDINGS/ — vector database files /FLUX_ISSUES/ — generated PDF issues (personal archive) /FLUX_LOGS/ — all system and process logs /FLUX_INBOX/ — incoming photographs for processing ``` - Personal archive status: ~400,000 Ricoh JPEGs on SanDisk SSD with EXIF intact. ~15,000 keeper images in chronological folder structure. Both to be migrated to NAS on arrival. - Personal issue count as of 2026-05-20: 423+ issues (FLUX_001–FLUX_423+). --- ## v2.1 — PROTOCOL STABILIZATION Released: 2026-05-25 ### Protocol - **36-frame standard reaffirmed as permanent.** DECISION-001 and DECISION-009 confirmed as binding. `VALID_ISSUE_LENGTHS` reverted to `[36]` in `flux_constants.py` and `generate_flux_issue.py`. - 24-frame PDF support was introduced as experimental code but was never ratified as a protocol change. It has been removed. The wiki pages stating 36 as the locked standard were correct throughout. - The FLUX Dispatch (24-frame thermal accordion) remains documented as a historical and conceptual object. It is not a FLUX issue format. There is no generator path for it. - `FRAMES_PER_ISSUE = 36` is immutable. The contact sheet grid is 6×6. The PDF is 44 pages. The manifest is 2 columns × 18 rows. None of these change. ### Code - `flux_constants.py`: `VALID_ISSUE_LENGTHS` reverted from `[24, 36]` to `[36]` - `generate_flux_issue.py`: local `VALID_ISSUE_LENGTHS` reverted from `{24, 36}` to `{36}` - `flux_portal/portal_generator.py`: stale comment `# 36→44, 24→32` corrected to `# 36→44` - `flux_portal/project_generator.py`: stale comment `# 36→47, 24→35` corrected to `# 36→47` - `flux_portal/app.py`: API docstring corrected to reflect 36-only constraint --- ## SEE ALSO | Document | Layer | Relationship | |----------|-------|-------------| | [DECISIONS LOG](../decisions-log/) | Layer 9 — Governance | RFC-style record of canonical protocol decisions | | [VERSIONS](../versions/) | Layer 9 — Governance | Version numbering reference and locked-version semantics | | [ROADMAP](../roadmap/) | Layer 8 — Roadmap | Forward-looking development timeline | | [BOOTSTRAP](../bootstrap/) | Layer 4 — Infrastructure | Phased implementation plan with hardware context | | [PROTOCOL](../protocol/) | Layer 2 — Protocol | The core protocol that all versions extend | --- FLUX_WIKI_v2.0 — flux.dantesisofo.com/wiki/changelog/