Development Journal

Version 2 is out

Shipped

SceneWeaver version 2.0.00 went public this week. Free, Student and Pro tiers are live on the pricing page; the £19 launch discount on Pro runs until 30 September 2026, and Version 1 continues to be available on the older-versions page for anyone who wants to stay on it. Verified end-to-end on all four target platforms — the Paddle live account, licence issuance, email delivery and activation all now do in production what the three months of test-account rehearsal said they would.

A silent-email trap, caught in the first real transaction

The first live purchase surfaced a bug the sandbox couldn’t have. The licence had inserted correctly, but the email hadn’t sent because the transactional-email account had briefly hit its rate limit — and the retry path treated the “licence exists” check as “already processed” and skipped the email a second time. Fixed with an email_sent_at column so retries know to resend, plus a recovery path for any existing-but-unemailed licence. Every subsequent transaction has landed cleanly.

A public issue tracker

The first post-launch feature is the Reported Issues page — a public, always-current list of everything anyone has reported, on both sceneweaver.uk/issues and whiterosecode.co.uk/issues. Reported doesn’t mean confirmed bug: a report can turn out to be user error, expected behaviour, or something that couldn’t be reproduced. The status on each card shows where the investigation landed, and a “Me too” count on open issues helps prioritise. It felt dishonest to launch a paid product without an open place to see what people have found; this closes that gap.

Next

The website copy that was written pre-launch is being brought current now that v2 is the delivered product, not a future release. The shipped sample manuscripts remain the piece that never quite got the writing time they deserved — that’s the next content pass, along with the tutorial videos that slipped from launch week.

The last full week before version 2 goes public

Working at severely reduced pace

This entry belongs at the top of the week rather than buried in it. I’ve been in a fibromyalgia flare with migraines since Friday 7 August, and the practical effect is that I have been unable to work longer than a few minutes at a time and so progress has been severely impacted. This has impacted the tutorial videos significantly — that work needs continuous concentration and headspace that hasn’t been available. Naming that here because it belongs in the honest record of how the project got made, not just the tick-list of what shipped.

Launch-window setup

The commercial setup for the paid tiers went from “built” to “armed” this week. The Paddle live account is now a full mirror of the test account the licensing side has been running against for the last three months — same products, same customer experience, plus the launch discount and a per-transaction limit that stops customers accidentally paying for more licences than we can issue at once. The pricing page went live on Sunday with a launch announcement and the strike-through £79/£60 pricing showing the £19 launch discount on Pro. Purchase buttons are still “coming 17th August” placeholders; they switch to the real checkout on launch morning.

A small internal admin page went live alongside it — a private page that only I can reach, locked down so it doesn’t appear anywhere from the public site. It lets me issue a real licence to a friend or family member, or to a customer who reports a broken code, without going anywhere near the normal purchase flow.

An honest mistake, and the time it cost

Spent a chunk of the week “fixing” something that turned out not to be broken. I noticed the grammar underlines weren’t appearing in the editor and assumed the highlighting had a real fault — traced through the code, restructured it, tested the changes. Somewhere near the end of that work I realised I simply hadn’t switched on the option that shows the highlighting in the first place. With proper focus it would never have been an issue at all — the checkbox is obvious once you know to look for it. Given how little productive time I’ve had these past days, spending several hours on a problem that didn’t exist has been genuinely frustrating; those hours were a very finite resource that could have been better spent on other things on the launch-prep list. The restructured code is cleaner than it was, so the effort wasn’t a total loss — but it wasn’t the trade I’d have made if I’d caught the mistake at the start.

The in-app help, brought current

Every top-level topic in the in-app help was written for version 1 and had drifted far enough from version 2’s reality to be actively misleading in places. This week’s biggest single job was a full sweep — sixteen topics rewritten, all customer-facing language checked against the app’s actual screens, all new version-2 features (the Research Library, the Notes panel, Convert-to-Token, the Built-in Tokens panel, the special-chapter types, the one-touch LanguageTool installer, the drop-in file discovery, the tier model) properly documented. The help browser inside the app is now something a new user can actually learn version 2 from, rather than a museum piece describing an app they no longer have.

Installers for all four target platforms

Built version-2 installers for the four target platforms: an AppImage that runs on any modern Linux, a .deb for Debian and its family, an .rpm for Red Hat’s family, and a Windows installer. The Windows installer was built on Windows itself; the three Linux packages were built on my working Linux machine. All four were then tested on fresh installations of their target operating system — not on my working machine, where dependencies would resolve differently than they would on a real user’s new install. Each fresh installation was snapshotted in a clean-baseline state so the launch-week testing pass can be repeated against exactly what a customer will experience, as many times as it takes.

Everything in one place

Longer-lived tidying work: everything I write for the business — the SceneWeaver source, the SceneWeaver website, the White Rose Code website, the internal admin app — used to live in separate project folders scattered across my machine. This week I consolidated them into one place with their full history preserved. The main practical effect is that everything is now backed up together and cross-referenceable in one place, which was overdue.

Launch-week UAT, and what came out of it

The last two days of the week were the full end-to-end pass across all four target platforms — done in short sessions between rest, still in the flare that opened this week’s entry. That’s the honest frame for what follows: a batch of small polish items got over the line despite the reduced pace. The View menu regrouped into visual sections. Front and back cover backgrounds locked to a sensible fixed presentation. Character-level formatting made to persist properly in Show Text mode. Paragraph-style changes between body styles now preserving direct bold / italic / underline the way any modern word processor does. In-prose Heading 1–4 lines exporting to Word with the correct Heading style. A splitter-layout inconsistency between the F5 cycle and the Smart Collections menu toggle reconciled. None of them the sort of thing that would make version 2 unlaunchable; all of them the sort of thing that would make the first review a bit rougher than it needs to be. That any of it landed at all this week is largely down to picking small, well-scoped fixes and being able to hand each one off to a fresh session when concentration ran out.

The one thing that might move the date

Version 2 is meant to go public on Monday 17 August. The code is where it needs to be for that to happen. The remaining question is the shipped sample manuscripts — the small demo projects that open when a first-time user picks “Reset Sample Manuscripts”. They need to be genuinely useful, not just present, and the help sample in particular still has content that reads like a placeholder. Sample content work needs the sort of continuous, considered writing time that the last ten days haven’t reliably provided. If a short delay is what it takes to ship samples that actually help a new writer learn the app, that’s the trade I’ll take.

Next

Final content pass on the sample manuscripts, at whatever pace this stretch of my body allows. Marketing announcements queued up. Screenshots re-captured against whichever build ends up shipping. Version 2 goes public as soon as the samples are worth shipping — on Monday 17 August if the week gives me the space to get there, a few days later if it doesn’t.

A first-launch conversation, and a long-running attribution bug

First-launch consent, done properly

The most user-visible change of the week is a small dialog nobody had asked for by name, but which the app has been quietly missing since the first release. On first launch of SceneWeaver — and again the first time a future major version arrives — users now see a plain-language question about anonymous usage feedback. What the app can send, what it never sends, why the team asks, and why sharing helps. Enable or Decline. Your choice is remembered until the next major version and can be changed any time in the settings screen.

The old flow had this option buried in a settings tab most first-time users would never open. That was fine as an intellectually honest opt-in but a bit stingy in practice; a properly explained question in a proper moment feels much better. The copy went through several passes to find the right register — not begging, not corporate, plainly informative. The value exchange isn’t “we’re free so please help” (version 2 will have paid tiers, so that framing wouldn’t scale honestly); it’s the simpler and truer “the version you’re running gets better”.

The Linux install path, unblocked on modern distros

Also this week: a real user reported that the SceneWeaver AppImage refused to launch on a fresh Debian 13 install. The cause turned out to be the AppImage runtime the build script had been using, which depends on a system library called libfuse2 that Ubuntu 24.04, Debian 13 and other current distributions no longer ship by default. Rebuilt against the current-generation AppImage tool, which speaks the newer FUSE version and gracefully falls back on older systems. Every recent distribution now runs the AppImage out of the box without side-installing anything. Verified on Linux Mint and Debian 13.

Story-scope entity awareness

The heaviest work of the week — five compile cycles from v1.0.0S through v1.0.0X — was a single class of bug that surfaced in a real manuscript. Two locations both called their thing “the Archive”. Both existed in the same story. But one was in Chapter 1 and one was in Chapter 2, and each had an Introduction Node and Exit Node set to say so. The reader would have no trouble telling which archive is meant in any given scene; SceneWeaver was attributing every mention to whichever entity happened to sort first alphabetically.

The fix turned out to touch every place in the app that maps a keyword to an entity: the keyword conflicts report, the highlighter in the editor, the token resolver that expands <<archive:name>> into the actual value, the two continuity checks that flag early or late appearances of an entity, the Entity Usage report’s Used / Unused status and its per-node occurrence list, and the used indicator on the Locations side panel. Each one had its own path through the code, and each round of UAT would clear one and expose the next. The whole thing landed as v1.0.0X, and Mike’s verdict after the final round was the entire sign-off: “Yep we have a fully working system now.”

There is a whole separate post about this on the SceneWeaver site — what the fix means for the writer, how to use the Introduction and Exit Node fields, and why it matters for anyone whose cast is bigger than a couple of dozen characters.

Version 2 continues in parallel

On the version-2 side, Sprint 10 EPIC 2 continues. The corkboard view got a proper clickable breadcrumb across the top so you always know where you are in the manuscript’s structure and can walk back up with one click. The Research Library panel from a fortnight ago gained the ability to add top-level folders from any context, plus drag-and-drop reorganisation and a right-click menu on folder pages for creating items in place. Focus Mode’s floating word count now reflects whichever view is on screen — the current scene when writing, the current chapter or scene when working in the corkboard, the loaded item when reading in the Research Library — instead of always showing the last-loaded scene’s count regardless of what’s actually in front of you.

These are the sorts of small consistency fixes that make an app feel considered.

Background images across every exporter, and two proper admin panels

The export half of a long feature

The first half of this feature landed a while back — you can attach a background image to any chapter, scene or section in the editor, position it, size it, adjust its transparency. The point being visual atmosphere while writing: an old photograph behind a memory scene, a piece of concept art behind a location, a texture behind a special chapter. This week was the other half, which is making all of that render correctly in every export format.

There are seven of them: DOCX, PDF, EPUB, HTML, Markdown, plain text, and Fountain. Each format handles background images differently. DOCX embeds them as watermark-shaped floating pictures. EPUB and HTML use CSS. PDF has to draw them properly in the page background rather than as inline content. Markdown, plain text and Fountain don’t support images at all — but they need a way to still respect the chapter-boundary logic that goes with them, so the layout on those formats stays coherent.

The DOCX exporter also picked up proper book-design pagination this sprint. Cover pages start on the right (as they do in a printed book), each new chapter starts on the right (so the last page of the previous chapter can be a blank verso), and a full back cover renders on its own page rather than bleeding onto the previous one. This is the sort of typography a novelist expects a professional export to get right without being asked.

Sprint 10 EPIC 1 closed on the Friday at v1.10.16Q after fifteen UAT rounds. Every one of the seven exporters now handles the feature end-to-end, and the Delivered Features catalogue was updated accordingly.

Two admin panels, one custom domain

The other big theme of the week was infrastructure. Two new admin surfaces went live behind IP-allowlist and bearer authentication on the private metrics domain: a Downloads panel and a Telemetry panel.

The Downloads panel gives me a live view of what’s been downloaded, from where, in the last day / week / month / year. Overview headline, per-day chart, breakdowns by platform, version, country and city, and a paginated recent-downloads list with IP addresses so I can eyeball obvious data-centre traffic. A “Hide bots” toggle strips out fifteen categories of known crawler and library-HTTP-client user agents. And when the user-agent filter isn’t enough — because some data centres run headless browsers that report perfectly normal Chrome user agents — there’s a right-click “Hide downloads from this IP” on every row. That builds a persistent deny-list stored in a D1 table alongside the downloads themselves. The first pass through the real download log removed most of the noise and left the actual human downloads visible for the first time.

The Telemetry panel does the same for the anonymous usage data. Total events, unique installs, per-day chart, top event names, breakdown by app version and by OS, and a p50/p95/max/avg timing table for the perf-instrumented operations. Both panels are private and locked to the operator; neither exposes any user identity because there is no user identity to expose.

Along the way I decommissioned a small standalone dashboard worker that had been serving one earlier version of the telemetry view. Its role is now handled by the consolidated metrics worker, and one fewer moving piece is one fewer thing that can drift.

The desktop admin app follows suit

The White Rose Code admin desktop app — the thing I use to manage licences, downloads and telemetry from a single native window rather than juggling browser tabs — gained two new tabs to embed the Downloads and Telemetry pages inline. Same authentication as the web pages, but wrapped in a proper application shell so I’m one keyboard shortcut away from any of them.

The Research Library takes shape

A simpler model

The bulk of the week went into the Research Library — the piece of SceneWeaver that lets you keep source material next to your writing. Character sketches, location photographs, quotations, links to background reading, PDFs, Word documents; the sort of thing that would otherwise live in a folder on your desktop and slowly drift out of sync with the manuscript.

The design that emerged was simpler than what I started with. I originally split it into “drawers” (top-level containers) and “folders” (nested), thinking the distinction would help. It didn’t. Every folder is now just a folder, at any depth. That single change made half the code lighter and the mental model plainer, and I’m always slightly suspicious when the right design turns out to have fewer moving parts than the one I started with, but it usually does.

A shared shell

Every kind of item — note, image, quotation, link, document — wears the same shell: a header card with the item’s title and a one-line description on top, a source citation strip at the bottom, and only the middle changes to suit what the item is. Notes are a clean manuscript-paper writing surface. Images sit inside a white mat with a subtle drop shadow, alongside a small sidebar of dimensions, filename, format and added-date. Quotations are big pull-quote typography, with the open and close marks framing the excerpt. Links auto-fetch the page’s title and description, present them as a preview card with the hero image, and pull the page’s readable text into a reader pane, so the captured content remains available even if the page later changes or disappears. Documents (PDF, DOCX, RTF and a handful of others) work the same way: drop the file, we keep the bytes safely inside your manuscript, extract the text for reading in-app, and let you open it in your usual viewer when you want to.

Bindings, rebuilt

The bindings — how a research item links back to the chapters, scenes and entities in your manuscript — got a proper rebuild too. The old picker asked you to paste an ID from somewhere; nobody was ever going to do that, so everyone typed a human name instead, which the app would dutifully treat as a valid reference until the next launch, when a cleanup pass would quietly remove it. Now you pick from a list of what actually exists, and the bindings survive.

Two quiet wins

Somewhere in the middle of all this I found and fixed a quiet duplicate-image problem where dragging the same photograph into different research items would keep making new copies of it. Not any more — identical bytes are recognised and reused. Same idea applies to documents.

Two small libraries came in with all the proper paperwork: one for reading PDF text, one for reading RTF text. Both are permissively licensed, pure Python, and small. Both are listed in the audit doc and on the startup screen alongside every other bundled component.

Security review and tutorial restructuring

Security review

Spent Friday on a full security review of everything running on the payments and licensing side. Nothing frightening turned up, but a handful of small hardening opportunities did, and they are all now sorted. The kind of quiet work that never makes a headline and shouldn’t need to.

Guides and Tutorials rework

Then the Guides and Tutorials rework on the SceneWeaver site. Three sections instead of two: Start Here for the introduction video, Getting Started for the install walkthroughs on Windows, Linux, and macOS, and the ordinary Tutorial Series for everything after. Placeholder cards go up first so the layout is stable while the videos are being recorded.

Hosting cleanup

A small warning kept showing up in the browser console on the tutorials page. It turned out to be something the hosting layer was adding to the response automatically, entirely outside my control, and there is a supported way to opt out of it. Now opted out. Not exciting, but worth chasing because a clean console is one of those small quality signals that people notice without noticing.

Protecting prose from an empty-save failure

The editor bug

A hard week. The prose editor has a mode where the merge tokens (the little placeholders that stand in for a character or place name in the raw text) render as the actual values instead, so what you see on screen reads like finished prose. Convenient for writing, fiddly to keep in step with the underlying document. This week I discovered that under an unusual sequence of edits, the mode could quietly lose text. Two safety nets went in: a timestamped backup of the affected node is always written before an empty save is allowed, and a diagnostic trail records every sync so I can trace what caused any future recurrence. The underlying cause turned out to be a small failure being handled as if it were a legitimate empty document. Both the safety nets and the fix stay in; belt and braces.

Student verification tightening

Also several rounds of tightening on the student verification flow. The verification dialog was making decisions from a slightly stale copy of what the server had actually said. Each round narrowed the gap. The last of them made the reverification date update the moment verification succeeds, rather than waiting for the next start-up. Small things, but each one was a genuine surprise from a real user’s perspective.

Customer-support tooling and keyboard navigation

Admin panel

Sprint 7 closed, Sprint 8 opened. The theme of Sprint 8 is customer-support tooling — a proper admin panel that lets me look up any customer’s licence, see its current state, and process a refund or force a re-verification with a couple of clicks. It replaces a stack of manual queries I was quietly assembling for launch. It is also locked down properly, so even in the unlikely event that credentials were ever exposed, the panel would still refuse to open for anyone but me.

Keyboard navigation

Also this week: a full rework of keyboard navigation in the prose editor. Step between scenes with Ctrl and the page keys, jump to the nearest heading with Alt and an arrow, walk between mentions of a specific character or place with a modifier combo, tab through spelling and grammar issues with F3. Nothing hard individually. But there are dozens of small edge cases: what happens at the start of a chapter, how a heading counts as a heading, how the shortcut behaves in a chapter with no issues at all. The whole thing took the week.

Licensing, single-instance and themes

Four sprints in three days

The most productive week of the whole project so far, and probably the most reckless. Four sprints closed in three days — making sure only one copy of the app can run against a single project at a time, the licensing system in full, the compliance audit, and the design for how paid tiers will handle re-verification. It sounds heroic. In practice each sprint was a natural extension of the previous one, and it was cheaper to push through than to stop and let the design go cold.

The licensing system

The licensing system is the piece I’m proudest of. Your licence is a signed file that verifies on your own machine when the app starts up. The free tier never phones home. The paid tier does, but only occasionally, and only to confirm the licence is still valid; if your network is down, the app carries on working with a generous grace window. If a licence is ever revoked (a genuine chargeback, or an abusive use), that decision is remembered locally too, so it can’t be undone by a reinstall. The whole thing is designed on the honour-system model with just enough teeth to catch obvious misuse, and nothing more intrusive than that.

Themes

Also this week: themes. Three of them — light, dark, and a high-contrast accessibility mode for anyone who needs stronger separation between text and background. Most of the work was checking every custom part of the interface to make sure it actually used the current theme’s accent colour, and not one hard-coded from months ago.

Version 2 begins; images arrive in the editor

Version 2 opens

Started work on version 2. Version 1 shipped last week and is out in the world doing its own thing; version 2 is being built on a separate track where I can experiment without touching what’s already downloaded.

Images in the editor

The big piece this week is images. Version 1 supports images in exports, but the editor itself doesn’t let you attach them to a manuscript. In version 2 you can: each character, place, or item can carry a photograph; scenes and chapters can hold reference images; and there is a proper image library at the manuscript level so a single portrait can be inserted anywhere without being copied around. The tricky part was making the editor keep its head straight when an image is pasted, cut, deleted, or moved around. That took most of the week.

Backlog note

Also this week: a new item added to the backlog around making sure only one copy of the app can be open on the same project at a time. If two are open at once they can trip over each other’s saves. Not observed in the wild yet, but I’d rather solve it before it ever happens than after.

Version 1.0 goes public

SceneWeaver version 1.0 is public. The download page went live on Wednesday, the website copy is finally in a shape I’m not embarrassed by, and the app has been out in the world for a few days now.

The lead-up was not glamorous. A dozen small snags with the Windows build to get secure connections working. Repeated rebuilds of the Linux package to clear stale caches. An unnoticed typo in a machine-readable file on the website that no browser would ever have complained about but which blocked search-engine ingestion. An afternoon spent on a version-check that only misbehaved once served from the real host, not the local one. Nothing dramatic, all small — but the sort of small that matters at launch.

The website itself went from a sales-pitch voice to something quieter. Overpromising is a worse look than plain description, and it reads better now.

Installers, telemetry and licence audit

Installers

The proper install packaging went in on Tuesday. By the end of the week the app was building cleanly for Windows and both major Linux package formats. I had been putting this off for weeks because packaging is unglamorous work that I knew would take longer than I wanted. It took longer than I wanted. The Windows installer tool I settled on has been in service for over two decades and does exactly what it says on the tin every time; when you’re the person who has to answer the support email if a Windows install fails at midnight, that kind of reliability matters more than anything shiny.

Opt-in telemetry and crash reports

The other new thing this week is opt-in anonymous usage telemetry. It’s off by default, it never sees a word of what you write, and it exists purely so I can tell when a feature nobody expected to be popular is actually getting used. There is a bug reporter too, wired into the crash handler; if the app dies unexpectedly, the report dialog offers to send back the technical details of the failure. That’s it — nothing else about the manuscript.

Licence audit

Also worked through the open-source licence review for the third-party libraries the app depends on. Not exciting, but a lot of solo developers get this wrong and then get a nastygram, so I read the licences twice and documented what I did.

Commercial model locked; trust-and-stability sprint

The commercial model

A big rethink week. The commercial model is finally locked. Version 1 is free-perpetual and full-featured. Version 2 will introduce optional paid tiers that gate only the number of simultaneous manuscripts you can have open — the core writing feature set will remain available on the free tier. I want version 1 to be the thing you keep using even if you never pay a penny for version 2, and I want version 2 to be a fair deal for people who want a bit more headroom or wish to support the project.

Trust-and-stability sprint

Then the mid-week sprint: making sure that when you rename or delete something, every other place in your manuscript that referred to it stays coherent; a full set of round-trip tests for every export format so a bug in the export pipeline can’t sneak past me unnoticed; a written policy for how the app handles files created by older versions of itself; and a Project Health view that surfaces anything odd about the current state of a manuscript. All of that is the quiet trust-and-stability work that nobody notices until it’s missing. Which is how it should be.

Reference consistency, timeline and bibliography

Two sprints back-to-back. The first delivered reference consistency (so a citation to a scene you just renamed still works) and a proper beta-reader package with a DOCX round-trip. The second brought Timeline drag-and-drop reordering, version labels and milestones for tracking a manuscript’s own history, publisher target presets, scoped review printing, and a full bibliography and citation management module including the Harvard citation style. That is a lot for a week. A couple of those will need revisiting, but the core is in.

Getting DOCX paragraph spacing right took multiple attempts. Word calculates spacing from a place I hadn’t looked, in a way that isn’t obvious. Once I found it, the fix was small. Getting there was three days.

Fountain export and continuity validation

This sprint delivered Fountain export (the screenplay format — not part of the core novelist workflow, but a modest lift that adds a whole new dimension to what SceneWeaver can be used for), unified export and import dialogs (six formats behind one panel that reveals options as you make choices, rather than six separate menu items), a full audit of the in-app help content, and continuity validation. The continuity check is the piece I’d been quietly wanting for months: it scans a manuscript for characters or places that appear before their introduction, or after their exit, and surfaces the mismatches in a report. It found three real ones on the sample manuscript. That was a good afternoon.

The next sprint rolled straight into DOCX round-trip import, which needed more thought about paragraph indent handling than I expected. It also included a proper Close Manuscript flow that fully clears the previous project from every panel. I’d found a couple of side-panels that were still holding onto the closed manuscript’s data, which is exactly the sort of small leak that becomes a big problem at scale.

Annotations and a right-panel rework

Sprint closed on Sunday with inline comments and annotations, style and consistency checks, and a rework of the right-hand side of the interface so the Description, Entities, Notes and Annotations panels are each one click away rather than buried inside menus. The annotations feature is the one I use most on my own manuscript now — being able to leave “check this fact” or “reword this line” attached to a specific chapter and pick it up in the next writing session has changed how I use the app.

Planning for the next sprint started midweek. The theme is fewer, sharper dialogs and better exports. The exports one is quietly important: SceneWeaver’s commitment is that every export format is fully featured, without anything held back. So every format has to actually be as good as advertised.

Compile presets, restore-point diffs, spell and grammar

A heavy Monday. Compile presets so you can save something like “novel manuscript”, “beta reader package”, or “short-story submission” and reuse them without reconfiguring every time; a comparison view for restore points that shows exactly what has changed since a saved state, so a rollback is never a leap of faith; and PDF export alongside the plain-text and Fountain exporters. Also a couple of tweaks to the text exporters I owed from the previous sprint.

The rest of the week was the next sprint proper: spell check, grammar checking (using LanguageTool, running locally on your own machine so nothing about your writing leaves it), a small writing-coach dashboard, and a new mode that resolves the merge-token placeholders into their real values so you can read your prose as prose. Making the grammar checker feel fast rather than sluggish took a bit of trial and error, but it’s snappy now.

Entities, reports and manuscript-wide search

Two sprints closed inside the same week. Entities landed properly: characters, locations, items, and organisations, each carrying keywords and configurable fields (things like “rank” or “colour”), with proper merge-token support so those values can be woven into the prose. Then reports and search: a repeated-phrases report that has already flagged three of my own writing habits, a readability scoring pass, and a global search across the whole manuscript that finally makes a large project feel navigable.

A third sprint came in on the weekend — not planned that way, but the momentum was there and I didn’t want to break it.

Rich text, special chapters and a deferred image experiment

Rich text formatting finished, and the special-chapter flow, DOCX pagination and metadata sprint nearly finished by the end of the week. There was one small detour where I attempted to add image support inside the editor and had to revert it. The way the underlying text framework handles images does not play nicely with the way the app saves and loads documents. Rather than force it, I marked it as a backlog item for later and moved on.

The chapter special types are how SceneWeaver represents things like a Title Page, an Acknowledgements section, or an Appendix — not just prose chapters but structural elements that carry different rules for page breaks and for whether they count towards the manuscript’s word total. Getting those to feel natural in the tree took a few passes.

Edit: When “later” came around, adding image support properly took the whole of the first version-2 sprint. Past-me was right to defer it.

Safe save

Spent the week reworking the way manuscripts are saved to disk. What I had before was a working prototype; what I have now is something I’d be willing to put on a real user’s machine without lying awake worrying about it. Every save is safe against a power cut mid-write. Upgrades to newer versions of the app never damage older files, and older files always ask permission before being touched.

Also a small tightening of the bold button in the toolbar. The sort of change that takes fifteen minutes and makes the app feel a lot less bumpy.

Starting the journal

Starting the journal on the first of the month felt tidy. What I’m working on is SceneWeaver, a desktop writing application for long-form fiction. It has been under development for a while now, but this is the first week I’ve decided to keep a proper weekly note rather than trusting my memory and the commit history.

The app is built around a manuscript tree — chapters, scenes, and sections, all reorderable, with word counts that roll up. Characters, locations, items and organisations will get proper entity records with photographs and configurable fields. And the compile pipeline is being built to export to every format a writer is likely to need — DOCX for Word, PDF, EPUB for e-readers, HTML, Markdown, plain text, Fountain for screenplays, and LaTeX. Some of that is in place, some of it is in flight, some is still on the plan. What’s ahead is a lot of feature work, then the polish, the packaging, the trust work, and eventually a public release.

The goal for version 1 is to ship something a novelist can install once, use for their whole book, and not have to fight. No cloud, no accounts, no upsell prompts. If the project ever earns any money, that will be through version 2 — and version 1 will stay free forever regardless.