What the work is.
- Canonical records and ordering
- Schemas and archive validation
- Editing and local recovery
- Draft data and deploy review
- Source and publication history
Local-first publishing for irregular work
Deko
Boko
A Git-native publishing platform that treats a website as an evolving archive—not a stack of interchangeable pages.
- Form
- Publishing platform
- Pilot
- mina.systems
- Status
- V0.1 archive loop active
01 / Premise
Some bodies of work refuse the template.
Art portfolios, living archives, research notes, and experimental media sites rarely develop in neat, repeatable units. Their relationships shift. Their formats collide. A project may need a bespoke page while still belonging to the same searchable archive as everything around it.
DekoBoko—named for unevenness, 凸凹—starts with that irregularity. Canonical archive objects hold the durable parts; an editorial workflow prepares them for a site-specific renderer. The current CMS is one interface within that larger publishing model, not the whole platform.
02 / Publishing model
One archive.
Two responsibilities.
How the work appears.
- Layout and typography
- Custom project pages
- Animation and interaction
- Responsive behavior
- Final public rendering
DekoBoko does not become a second version of mina.systems. Archive previews pass draft or production data through the same mina.systems frontend, so the comparison stays grounded in the real site. A separate compatibility preview remains deliberately minimal: it tests generated output, not visual parity.
03 / Working loop
Keep the path to public inspectable.
- 01Shape
Edit canonical project records locally. Debounced autosave writes valid content without silently publishing it.
- 02Validate
Typed schemas check the complete archive—identity, routes, status, ordering, body content, and media references.
- 03Preview
Draft archive data enters the actual mina.systems frontend through a local preview; production data remains a separate view.
- 04Review
Source checkpoints, target diffs, file selection, and route warnings expose what will change before publication.
- 05Publish
The approved Archive Listing and Project Rendering Contracts move into mina.systems, with Git retaining the audit trail.
04 / Current progress
The archive loop works.
The page loop is next.
A living snapshot of implementation readiness in the V0.1 Mina Pilot, verified against the repository on July 27, 2026. These bars describe capability—not a release schedule.
- Canonical content model
- Archive publishing loop
- Preview and deploy workflow
- Ownership architecture
- Project rendering contract
- Project-page integration
- Authoring experience
- Media operations
- Multi-site capability
- 64
- canonical records
- 15
- custom mina.systems pages
- 49
- contract-eligible records
- 1
- paragraph-block fixture
05 / Archive object
A project is more than its page.
PROJECT / 007
STATUS / PUBLISHED
DekoBoko
- Identity
- id · title · slug · route
- Position
- section · category · order · featured
- Meaning
- summary · description · tags · dates
- Material
- Markdown · paragraph blocks · media · links
- History
- status · source route · provenance
- Ownership
- customPage: true
A custom-page flag keeps a project in the canonical archive while its hand-authored page remains owned by mina.systems. The record stays searchable and ordered, but its body is locked in the CMS and excluded from DekoBoko’s Project Rendering Contract and compatibility-page generation.
06 / Position
Structure should hold the work.
It should not flatten it.
DekoBoko is now a functional local archive pipeline: 64 canonical records can be edited, validated, previewed, reviewed, and published into mina.systems. MRI Supernova is the first non-custom public route to consume the Project Rendering Contract in both draft and production; the next proof is sustained editorial use and expansion to additional project pages.