@Jackeyhate9 hi, I read StoryMemory Studio end to end — the S/A/B/C/D Context Builder, the SQLite story-memory layer, the consistency checker, the AI-tone cleanup, and the IP adaptation matrix. The thing I kept thinking about is that all of this currently lives behind a Windows exe download or a python run_ui.py clone, so most repo visitors never get to see what "long story stops forgetting its own rules" actually feels like.
I wired the writing flow into a Socialistic demo, so a visitor can open it from your repo page and try the workflow on their own draft chapter, without downloading the exe or pulling the source.
The direct prompt is "Upload story bible and draft chapter" or "Describe the continuity issue", and the result lands in a sharable page — you can try it here or forward that link to a web-novel writer friend whose chapter 50 has started contradicting chapter 12.
What I think this is most useful for, on your side: each web run leaves a record of the actual chapter pasted, the continuity issue described, what the model returned, and where the writer retried. That is signal you currently cannot get from a local-only exe install. You can read those sessions and use them to sharpen the Context Builder priority layout, the AI-tone heuristics, or which IP-adaptation outputs people actually want.
One small design discussion, since you clearly thought hard about this: the mainstream long-fiction tooling default is still "paste the whole novel into a long-context model and pray". Your decision to keep SQLite as the source of truth and use long context only for global reasoning is the more durable bet, and it is the part repo visitors are least likely to understand from the README alone — letting them feel the difference inside one chapter is what the demo is for.
The platform covers API and model cost for the demo path, so writers can click through and try it without their own DeepSeek key or a local Ollama install. Feel free to close this if it does not fit. Contact: shesonglin@tinkerland.ai
@Jackeyhate9 hi, I read StoryMemory Studio end to end — the S/A/B/C/D Context Builder, the SQLite story-memory layer, the consistency checker, the AI-tone cleanup, and the IP adaptation matrix. The thing I kept thinking about is that all of this currently lives behind a Windows exe download or a
python run_ui.pyclone, so most repo visitors never get to see what "long story stops forgetting its own rules" actually feels like.I wired the writing flow into a Socialistic demo, so a visitor can open it from your repo page and try the workflow on their own draft chapter, without downloading the exe or pulling the source.
The direct prompt is "Upload story bible and draft chapter" or "Describe the continuity issue", and the result lands in a sharable page — you can try it here or forward that link to a web-novel writer friend whose chapter 50 has started contradicting chapter 12.
What I think this is most useful for, on your side: each web run leaves a record of the actual chapter pasted, the continuity issue described, what the model returned, and where the writer retried. That is signal you currently cannot get from a local-only exe install. You can read those sessions and use them to sharpen the Context Builder priority layout, the AI-tone heuristics, or which IP-adaptation outputs people actually want.
One small design discussion, since you clearly thought hard about this: the mainstream long-fiction tooling default is still "paste the whole novel into a long-context model and pray". Your decision to keep SQLite as the source of truth and use long context only for global reasoning is the more durable bet, and it is the part repo visitors are least likely to understand from the README alone — letting them feel the difference inside one chapter is what the demo is for.
The platform covers API and model cost for the demo path, so writers can click through and try it without their own DeepSeek key or a local Ollama install. Feel free to close this if it does not fit. Contact: shesonglin@tinkerland.ai