Seven dense days, in which the “blog” project went from being a static site with a makeshift Flask panel to a small ecosystem: a well-written CMS, images generated by the local model, and a direct line between the two machines at home that now also records what I do. I retrace everything in order, with links to the posts already written in detail.
Sunday: the definitive CMS (.NET 10 + Angular 20 + Hugo)
The week started by throwing away the Flask panel and replacing it with
BlogAdmin: REST APIs in
ASP.NET Core 10 organized as feature slices (Auth, Posts, Media,
Rebuild), an Angular 20 UI with NgRx signal stores, JWT login and a
two-container Docker deploy with a shared volume. Plus .NET
Aspire to bring up API + Angular +
dashboard with a single dotnet run during development.
The result: I write in Markdown with live preview, and Publish runs the Hugo build by itself. From that day on, every post of this week was born there.
Monday–Tuesday: GX10 and Strix Scar 16 finally at the same table
The missing piece was the link between the laptop (Strix Scar 16) and the
server (GX10). I configured Copilot on the Scar with a custom GX10-Qwen
endpoint pointing at the proxy on the server, enabling toolCalling, and
verified the flow with a multimodal test — sending an image from the Scar
and having Qwen3.8 Flash Next running on the GX10 comment on it. Details
in Connecting the GX10 and the Strix Scar
16.
A technical detail worth remembering: in its custom endpoint, VS Code
does not forward the apiKey in requests (it sends an empty
`Authorization: *** To tell which machine is speaking, the proxy
switched to identification via source IP, with the apiKey as a fallback
when it does arrive.
From there also came the big question: does it make sense to sum the laptop’s 16 GB of VRAM and the GX10’s 128 GB of unified memory for “four-hands” inference? The analysis is in a dedicated post (“16 + 128 = 144 GB”) — short answer: for the models I use today, no; the bottleneck is the bandwidth between the two machines, not the memory.
Wednesday–Thursday: the blog that draws its own covers
The CMS now generates its own covers:
a /covers endpoint that submits a workflow to ComfyUI with Qwen Image
(quantized GGUF 2512 version + Turbo LoRA at 4 steps), polls the status and
writes the PNG into static/images/, updating the post’s front matter. A
precompiled prompt derives the subject from the title, description and
tags; the seed is reproducible. Meanwhile the UI moved to a real layout in
Angular Material.
Friday–Saturday: the diary that writes the posts
The most fun idea: if the proxy between VS Code and Qwen sees everything,
it can also record. The gx-telegram gateway now has a JSONL activity
log with machine, project and the text of the turns — discarding
Copilot’s internal prompts and masking secrets. A script
(scripts/generate-draft.py) takes the last N days, filters out what is
private, turns it into a digest and asks the local model to transform it
into a post draft with the right front matter. A systemd timer launches it
every Monday at 09:30.
This post is also a test of that flow — with the irony that today’s automatic draft already exists, and I am rewriting it by hand. For now the model recounts well what happened but flattens the numbers and loses the connections between things: for weekly summaries, the human pass stays.
The week’s numbers
- 19 commits across two repos (15 on the blog, 4 on
gx-telegram) - 5 posts published, 3 of them with a cover generated by Qwen Image
- 2 machines linked via proxy, with IP-based identification
- 1 Flask panel permanently retired
Next week: clean up the draft generator (the digest should include git commits too, not just chats) and see whether the Monday-morning trigger really works without me.