*Had this idea in Bad Gastein initially when working Reaper for Ulfig. I thought: why not build the projects data as JSON and query it from that source of truth – instead of hardcode.

Let Claude Opus 4.5 rip a prototype. Told Leo about it and he said: „You’re so smart“ – kinda sarcastic, but also not – seems he doesn’t care about or get those ideas as much as I do. It’s not a bad idea

As mentioned in last post: https://v0.niklasall.com/work-journal/reaper-v3-1-major-ui-monaco-integration/

Also on the List: „The JSON CMS“ – a CMS UI we can include in every project.

PHP registering of post types = only needed for CMS. Frontend can remain static.

We have the proto already and I’ll now enhance it with OPUS4.

Introducing some new field types. Not sure if we can do relationships with JSON objects? – Probably: need to introduce post number id (curr id is text.).

JS fetch in the frontend. Needs to be baked into the code, but no problem for CC.

—

Opus 4 introduced new field types.

I can port the whole folder to a project, let claude register post types in PHP and have the UI.

Experimenting: letting Claude ripp a new post type – is UI truly dynamic pulling post type registries?

The JSON CMS fits the vision of fully agentic AI first website building.

No more need for WP.

GPT yesterday told me, it is saver than WP – no issues with using fetch().

My google note:

 „chatted with GPT.

nothing insecure about it.

Its Data is exposed in JSON, but thats fine. (easier to crawl)

JSON is filterable only by JS front.

SQLite would be queryable.

JS can build Render & Pagination Queries fine with fetch() – apparently so.“

We can have paginations. We can simulate queries. We can filter.

JSON vs SQLITE

We might want to go with SQLite for more complex things. We can have real queries – either good thing or bad thing. JSON is sufficient for the type of data we usually handle.

Still highly readable .db file for LLM (I think?) – I was wrong, it’s not human readable. The DB config is:

CREATE TABLE users (id INTEGER PRIMARY KEY, name TEXT);
INSERT INTO users (name) VALUES (‚Alice‘), (‚Bob‘);

I am not sure – haven’t needed it yet.

Might soon.

We’ll go for MySQL for Careerly.