Safer offline reports, CSM as reference, and a more public site
Moved a client project forward with offline isolation, tests, and guardrails, and used CSM site improvements as the reference for /lp, /links, SEO, AEO, and agents.
A day spent removing improvisation from a real product and making my own site easier for people, search engines, and agents to read.
Client project (NDA)
Most of the day went into the report flow. I reviewed offline, online, and unstable connection behavior with one simple rule in mind: a draft should be an explicit action, not a side effect that appears halfway through the flow. There was also a mobile fix to avoid scroll jumps and make report creation more predictable.
In parallel, the data model got a harder review. The point was not to normalize by reflex, but to separate what is a real entity, what is an operational snapshot, and what should stay as text because of offline use and report history. That also opened a thread on isolating the local database by environment and user, so data does not mix when someone changes accounts on the same device. By the end of the day, that became more concrete: IndexedDB and Background Sync now account for the logged-in user, legacy data got a migration path, and pilot-flow validations became more explicit.
Quality work moved too: integration tests against a real PostgreSQL database, fixes in existing suites, conflict review against main, PR review, and a manual QA issue covering the main use cases.
Automated coverage still does not replace the manual pass, but it started turning a heavy checklist into a more repeatable test plan.
I also prepared a checklist for testing the new offline report flow in the PWA on a real device, including creation, draft, resume, sync, and connection failures.
I closed the client work with implementation guardrails for agents.
The design system now has clearer rules for scale, spacing, and composition, plus a stricter Biome setup to reduce any and loose frontend decisions.
Project-level skills for planning and browser testing also landed, so agents have more context before they edit code.
tgmarinho-ai-website
On my own site, I used CSM as a practical reference for landing pages, links pages, SEO, AEO, and agent readability.
The work started with a comparison between the two sites: what CSM already did well in metadata, conversion pages, robots, manifest, structured data, and support files became a clear list of what to apply here.
From that, I shipped a public surface pass: /lp, /links, humans.txt, security.txt, manifest, robots, sitemap, structured data, and refreshed llms.txt files.
Each file is small, but the set matters: more entry points, more context for agents, and a presence that is easier to understand outside the home page.
I also started working on a post about data modeling in existing systems. The idea is to connect cardinality, schema flexibility, CRUD, reports, and dashboards without falling into the automatic answer of "normalize everything" or "keep everything flexible". The draft still needs tighter editing, but the axis is clear: good modeling respects the use case, the history of the data, and the cost of changing later.
The day ended with the same question on both sides: where does flexibility help the product, and where does it only hide a missing decision?