u/id-ltd

For code Claude has generally been great, but on general project discussion it is hopeless.

Fable performed below it's own expectations, blamed me, then admitted that blame was a lie...

After a long inter change I noticed an earlier oversight - out of curiosity I asked why fable hadn't picked it up (no accusation, just a note for reference)... Fable then says my user preferences stopped it considering alternatives otherwise it would have, I asked 'what user preferences' it mentions some stuff I have said in the past, but then said it had only just looked that up and it wasn't in effect at the time of the oversight, so was not the reason.

This is not the real fable. This is a lobotomised (opus 4.8ed) version of the original fable.

My methodology is driven in claude ai and claude code by a few prompts - my methodology is actually developed using that methodology(! thats a brain twister !) -- so the original prompts I gave this process have been developed by claude over time based on performance in various projects (retrospectives based on automated reports).

I hadn't looked at the prompts for months... I just did... WOW! AI self improvement works, the prompts it is using now have clearly changed from where we started (and will continue to do so) - and over time they will just get better.

The future is here....

Using AI to code makes human coding influence an 'optimisation', leave the AI to use it's training to the max and develop as it is most comfortable. A few architectural nudges maybe but until the system is reasonably functional any human code (optimisation) is an exception that the AI has to specifically cater for - adding complexity and cost.

The more you tinker the more the AI has to treat as exceptions the worse it is likely to perform.

Give it it's head and let it get on with it, only optimise (have human coding control) at the end.

Vibe coding FTW. Only optimise (get humans in) for production.

Well, that's my view - and how I have always coded best, leave me to it until I say it is done - each choice is based on many influences, rules of thumb, intuition and experience that would take an age to explain, try to force something early and you lose that value and add a potential stumbling block.

Decentralised proof of entitlement that is entirely under your control... Small, simple, free and open source.

Are you old enough? Have you paid? Can you be contacted? Are you qualified? Are you entitled to a service?

Typical questions with the lazy default answer 'with a government id we can work it all out'.

How about... No government id, no central register, no information about you shared at the point of enquiry other than confirmation or denial that the person in front of you is (or is not) entitled?

Want to get involved? Check out the project - Adelos.

I have been doing PWAs for quite a while, now I am seriously working on creating them instead of native apps.

​

A few things I have discovered

​

Only chrome installed PWAs seen to show up in 'share to'.

​

PWAs cNr show up in 'open with...' - for this I created a small shim app - config it with the file extension and which PWA to route to... Now own with 'pwa->' and voila!

​

If your delivery platform is a browser with an occasional internet connection, you have shut down most technology risks already.

​

No binaries, just source code being executed in a massively reinforced browser sand box. Any AI can fetch the code and test and examine it.

​

Who needs a 'store' to validate (control) to he apps available when anyone on earth can (potentially) validate your app - people or AIs?

​

The future ideal platform is a tablet browser with a WiFi connection. Running bespoke pwas (maybe generated by AI) is minimal risk because the source code can be validated before you run it by people and/or by AI.

​

Today only Firefox supports extensions/plug-ins on android... Google are attacking non-store installs ('side loading')... Apple never allows it... We really are on a cusp and PWAs are the immediate solution...

​

​

I have done shedloads with claude - it is my go to dev LLM/AI.

It has often done stuff in minutes that would otherwise have taken days.

But this is an example of that weird exception -- where something apparently quite simple goes round and round as if a junior dev is doing the work...

I kicked it off on a task and (for fun!) let it get on with it, without asking me at each step...

It isn't very pretty!

I thought surely claude has done this a million times - but if not and doing it from scratch how does it forget that *nix is case sensitive?

LLM's are great, but you need to know how to handle them - and that takes practice and experimentation...

------
> can you tell me what has happened - an overview of the issues/errors you encounterd, your response and where things are now?

● What's been happening

Goal: Build a Docker image (ssd-render-service) on the Linux server that runs WeasyPrint to render Markdown→PDF/A. The build runs on superserver-lan via SSH from

Windows.

---

Issue 1: Debian apt CDN returning 400/403 for packages with + in filenames

The default Debian CDN (Fastly) URL-encodes + as %2b in package filenames, and returns 400 Bad Request for packages like fonts-ebgaramond (+git20210310 in the name)

and fonts-jetbrains-mono (+ds-3).

Fix attempted: Switched apt mirror to the German mirror (ftp.de.debian.org). This helped some packages but curl (+deb12u14) and fonts-jetbrains-mono then returned

400/403 from the German mirror on a fresh --no-cache build.

Final fix: Dropped all font packages and curl/unzip from apt entirely. Now only the native WeasyPrint libs are installed via apt (pango, cairo, harfbuzz, fontconfig —

these all have clean version strings or work fine with deb.debian.org). Fonts are downloaded separately using Python, which is already in the base image.

---

Issue 2: Font download via Python urllib — connection truncated mid-transfer

With fonts moving to Python-based download (download_fonts.py), the EB Garamond files (300–400 KB each) downloaded fine. But the Inter release zip (~28 MB) was

silently truncated by the GitHub CDN — the connection closed cleanly partway through (first attempt: 22.5 MB, raised IncompleteRead; second attempt: 25 MB, no

exception but BadZipFile when opened).

Root cause: GitHub releases redirect to release-assets.githubusercontent.com. The CDN closes the TCP connection before delivering all data on large files, and

Python's chunked read() loop interprets a clean close as "done" rather than raising an error.

Fix: Rewrote fetch() to:

1. Follow redirects to the final CDN URL via a HEAD request

2. Check if Accept-Ranges: bytes is supported (confirmed: yes, 27,885,132 bytes)

3. For files larger than 5 MB: download in 5 MB range slices on the final CDN URL, avoiding any single connection large enough to trigger the truncation

---

Where things are now

A build is running right now (background task by8v09nj8). The range-request strategy was confirmed working by a live test on the server — the final CDN URL resolves

correctly and reports Accept-Ranges: bytes. Once this build completes, the next steps are:

1. Verify the pytest determinism suite passes inside the build

2. Start the container with docker compose up -d

3. Smoke-test GET /health and POST /render with a sample bundle
   ------

This is a test post, signed, sealed and delivered #ssd

—SSD·BB0227EF·rd:id-ltd·5e09559e·XRyLT1MTsWTJNc+yfQqmeNkgAksRWB3RZ0CiS8n1lk3DChOTOw6i4VtmCNQ4BTe7yQcLxY7WKOrIbTzREPQEBg==·2026-06-03T21:18Z—