Work Enaction
Enaction · Role-play memoryIn Enaction you run story scenes and pick which character is speaking. Each character keeps its own memories. I wanted that pick to decide whose memory a turn changes, and never to change yours.
Component study · twelve tests passed on September 19, 2026, with no AI model running
You speak as Guide: "I will bring the blue folder."
With two characters in a scene, one character's line could be filed as the other's memory. An AI review found it in August 2026.
Choosing a character changed the name on screen and nothing underneath it. The memories a turn produced could land with the wrong character.
The choice is saved with the turn and decides where its memories go. Nine new tests came with it.
The nine new tests ran with three older ones from August 12 that check your own record. No failures and no skips.
Imagine a short scene with two characters, Guide and Archivist. Each one keeps its memories in its own collection, apart from yours. The scene is made up to explain what the tests check, so clicking through these steps doesn't run Enaction.
Step 1 of 5
You pick Guide and type "I will bring the blue folder." That choice says who is talking in this scene. Your own profile stays as it was.
Enaction checks the pick before using it. It refuses your own identity as a character, and it refuses a character who isn't in the scene.
When a turn is prepared, Enaction saves the chosen character with the line. Each request carries an ID so Enaction can recognize a retry. If a retry with the same ID names Archivist instead, Enaction treats it as a conflict and keeps Guide.
While a turn is being prepared or waits to be accepted, the workspace also locks the role controls and says why.
You accept a manual turn, one where the character's reply is typed in by hand and no AI model runs. Enaction files the memories it produces under the character saved with that turn. The test uses two characters and runs once with each one chosen. Every memory lands with the character who was speaking, and none land anywhere else.
New memories still wait for review. Filing one in the right place doesn't approve it or make the character's belief true.
Another test picks a character that has no memory collection. Enaction writes no memory at all, even though another character's collection was there to take it.
For Guide, that means the blue-folder line isn't handed to Archivist or to you just to produce a result.
One more test takes fingerprints of your profile and your memories before a manual scene. A fingerprint is a code computed from the exact data, so any change gives a different code. The test closes the scene with requests sent straight to the app, accepts one proposed change and rejects the other two.
Afterward both fingerprints match their starting values. Nothing new was added to your memories or your state records, and the character's collection did get its memories.
Two companion tests show the check can fail: adding one memory to your collection changes its fingerprint, and a different profile name gives a different profile fingerprint.
Choosing who speaks, accepting a turn and reviewing what a scene proposes to change are three separate decisions.
The chosen character is saved with the turn and its request ID. While a turn is being prepared or is waiting, the workspace locks the role controls and says why. The character on screen can't drift away from the one the waiting turn will use.
The cost: to switch characters, you finish or abandon the waiting turn first.
If the chosen character has no memory collection, nothing is written, and no one else's collection stands in. Memories stay with the character they belong to, even when that means recording nothing.
The cost: someone has to notice the missing collection. Enaction doesn't repair it.
I decide what each project is for and check what comes back. Here I wanted to see which character spoke, what it remembers and what a scene proposes to change, so a character's experience can't quietly rewrite the person playing it or become settled fact in the story.
AI tools write the code, including the twelve tests on this page. An AI review in August 2026 found the problem described above, and nine of the tests came with its fix.
| Case | What the tests showed |
|---|---|
| The chosen character gets the memories | The test picks each of two characters in turn. Every memory from the accepted turn goes to the chosen character's collection, and none to the other character's or yours. |
| The choice is part of the request | The chosen character is saved with the prepared turn. Sending the same request again returns the original turn; the same request ID with a different character is refused as a conflict. |
| Invalid choices | Your own identity, or a character outside the scene, is refused as the speaker. |
| The chosen character has no collection | No memory is written, and neither another character's collection nor yours stands in. This covers a missing collection, not other storage failures. |
| No character chosen | Memories still go to a character, by Enaction's default order of preference, and never to you. This case files memory by default; it isn't a refusal. |
| Your record after a scene | After a manual scene, closed and reviewed through direct requests to the app (one change accepted, two rejected), the fingerprints of your profile and memories match their starting values. Nothing was added to your memories or state records, and the character's collection got its memories. |
| Two controls | Changing your profile name changes its fingerprint, and adding a memory to your collection changes that fingerprint. Both show the check can fail. |
Nine tests came with the fix merged on September 1, 2026. The other three, the record check and its two controls, date from August 12, 2026.
On September 19, 2026, the tests ran Enaction's own code for preparing a turn, filing memory and reviewing proposed changes. Storage was in memory or in temporary SQLite databases (small single-file databases). Web requests went to the app inside the test process, under the app's one fixed single-user identity. No AI model, live service, browser or PostgreSQL database was involved.
The record's wording was revised on September 22 and 23, 2026. The "No character chosen" case and the background were added then, read from the source of the same twelve tests and the project's history. No tests were rerun.