I reopened the repair question before I opened the code.
What exact rule is allowing the older approved boundary to stay eligible and win at resume?
I had left the sentence there on purpose. It was the smallest version of the problem I trusted, and I did not want to lose it now that I was finally ready to make a change.
“Start from this,” I typed to ChatGPT. “Do not widen it.”
It widened it anyway.
“The observed behavior could involve approval ordering, resume pointer selection, persistence state, rollback precedence, recovery-path differences, or selector eligibility.”
I stared at the response.
“You made the question bigger in one sentence.”
ChatGPT paused.
“You want only the path that explains why the older approved state remains eligible.”
“Yes. Trace that one path.”
I pulled the older returned state into view beside the current approved continuation point and opened the selector logic.
The older state was approved.
It was valid.
It had not been archived.
Nothing in the part of the selector I was looking at disqualified it simply because another state had become the active continuation authority later.
ChatGPT started narrating possibilities again.
“This could still interact with recency ordering or stale resume metadata.”
“Not yet. This path alone is enough to test because it leaves the older state in the candidate set after a newer continuation authority exists.”
The sentence was narrow enough to make me uncomfortable.
That was a good sign.
Broad explanations were hard to falsify because they could absorb almost any result. This one could be wrong in a very specific way.
ChatGPT tried to soften it.
“A more cautious formulation would be that older approved states may remain eligible depending on the selector path.”
“No.”
I had finally reached the point where caution could become another form of vagueness.
“This exact path leaves the older state eligible. We can test that.”
I made ChatGPT restate it without adding anything else.
“An older approved state remains eligible even after a newer continuation authority has been established.”
Then I asked it directly, “What single code change would test that claim without touching the rest of continuity behavior?”
ChatGPT answered with a bounded proposal.
“Remove older approved states from resume candidacy once a newer continuation authority has been established.”
I read the line several times.
It was small.
That was exactly why I distrusted it.
Small fixes were attractive because they let me imagine I was one edit away from release. But that was also why I wanted to test one. If it worked, the delay really might still be contained. If it failed, I would have earned the right to look wider.
I opened the file containing the eligibility rule.
Before touching it, I pinned the original reproduction beside the code.
Same project.
Same current approved continuation authority.
Same ordinary leave-and-return path.
Same wrong earlier boundary.
Under that I pasted the release requirement.
After a user approves work, leaves, and returns, Story Architect must restore the current approved continuation authority.
ChatGPT tried to extend the patch before I had changed a line.
“We could also add fallback behavior if the candidate set becomes empty, handle rollback precedence, and define a newer-state preference if multiple approved states survive.”
“No. We are testing one hypothesis. If it breaks something else, that is evidence. We do not pre-repair hypothetical failures.”
ChatGPT backed off.
I changed only the eligibility rule.
The edit was almost offensively small compared with the amount of anxiety attached to it.
One condition moved from permissive to restrictive.
Older approved states that no longer held continuation authority would not remain eligible by approval status alone.
I saved the file.
Then I stopped myself from running the test immediately.
“Read the success standard back to me first.”
ChatGPT answered, “The repaired system must restore the current approved continuation authority. A merely different returned boundary does not count as success.”
I copied that sentence into the repair note beneath the patch.
That was the trap I did not want either of us to fall into.
If the selector returned something different after the change, the difference itself would feel encouraging. It would be easy to call movement progress and progress success.
The standard had to stay outside the mood of the test.
I looked once more at the code change.
The patch touched the eligibility rule only. It did not alter persistence, recovery behavior, rollback handling, or broader selector ranking.
For the first time since the launch block, I had done something concrete instead of arguing about what the system might be doing.
I reset the test with the patch, hypothesis, original reproduction, and fixed release requirement all visible together.
Either this one rule was enough to restore the current continuation point, or it was not.
I left the launch status blocked and started the run.
I wanted this run to be the one that gave me the launch back.
The patch was small enough to make that hope feel reasonable, which was exactly why I did not trust it.
Before I left Story Architect, I made ChatGPT put the standard in front of me one more time.
“The repaired system must bring you back to the story state you actually established as current. A different result is not enough.”
I left through the same ordinary path as before and came back.
The project opened somewhere different.
For one second I felt a clean rush of relief.
ChatGPT reacted even faster than I did.
“The patch is working.”
I opened the expected continuation point beside the returned section.
They were different.
The selector had stopped choosing the old failure, but it still had not brought me back to the place I had actually established as current.
“Compare that result to the release requirement,” I typed.
ChatGPT slowed down.
“The returned state still does not match the current approved continuation authority.”
That was the result.
I went back to the note we had written before touching the code.
A changed result is not a pass unless it satisfies the release requirement.
A few minutes earlier, I had been worried that I would call movement success if the patch changed anything at all. Now the trap was sitting directly in front of me.
The system looked better than it had before, and I wanted that to mean I was close.
I wrote down what had actually happened instead.
Changed behavior is not correct continuation.
Then I made ChatGPT state what the run had earned without turning it into a victory.
“The eligibility rule is part of the path producing the return because changing it changed the outcome. But this one change still did not restore the state the user had actually made current.”
I read the sentence twice.
Removing one older state from candidacy had changed the outcome, so the rule was involved. But the new outcome still missed the state I had actually established as current.
I could have kept nudging the selector until this one history finally landed in the right place. That would have been easy to justify one change at a time, especially now that the system was visibly reacting.
Instead, I needed a history that would punish the wrong idea.
“What test would make this patch look worst?” I asked.
ChatGPT paused longer than usual.
“A history where recency and current authority point in different directions.”
I felt the shape of the test before it finished explaining.
Rollback.
Take an older approved state and intentionally restore it as current while leaving newer historical approvals in place.
If the patch really followed authority, it would have to return to the restored older state. If it was only leaning on ordering, recency, or a narrower candidate set, the history would expose that.
I opened a new test case beneath the current result.
ChatGPT helped me define it in plain terms: newer approved work remains in history, an older approved state is intentionally restored as current, I leave and return normally, and Story Architect must bring me back to that restored older state.
I stopped before running it.
The current test had already done its job.
The patch had changed the behavior without satisfying the release requirement.
That was enough to earn a harder test.
I saved the rollback case beside the existing release requirement and left the launch status blocked.
The next run would force the selector to answer the question the current history could not.
Could it follow authority when authority pointed backward?
I built the rollback case carefully because this time I wanted the history to disagree with my instincts.
The newer approvals stayed in place. Nothing was deleted, hidden, or archived. Then I deliberately restored an older approved state and made that restored state the place where the story was supposed to continue.
ChatGPT looked at the history and fell into the trap immediately.
“The newest approved state still appears to be the likely resume target.”
I pointed at the restoration action.
“The restored older state is current now. Keep that as the standard.”
I left the newer approvals visible on purpose. They were not mistakes. They were history. The test only worked if the system had to distinguish between what existed most recently and what I had actually chosen as current.
I ran the patched selector.
It returned the wrong state.
Not the old wrong boundary from the first defect. Not the restored state I had intentionally made current. Something else the selector could justify from the records in front of it.
ChatGPT responded with the kind of speed that usually meant it had already decided what shape the fix should take.
“We can add a rollback-specific precedence rule. If a restoration marker exists, the selector can prefer the restored state over newer approved records.”
I looked at the answer and felt the same frustration I had felt with the eligibility patch, only cleaner this time.
“That would only teach this test its answer. I am not adding another exception.”
I pulled the forward-progress history onto the screen beside the rollback history.
In the first one, newer was current.
In this one, older was current.
Both histories contained valid approved states. Both histories contained an ordinary leave-and-return path. The only thing that changed was which approved state actually held continuation authority.
“Compare them,” I typed.
ChatGPT stopped proposing code for a moment.
In the forward-progress history, the system had needed to follow the newer approved state because that state was current.
In the rollback history, the system needed to follow the older restored state because that state was current.
The selector-level shortcuts kept failing because the visible properties of the records could point in opposite directions depending on the history.
Recency worked in one case and failed in the other.
Validity was useless because every important state was valid.
Eligibility changes could alter which boundary won without establishing why that boundary was current.
I asked ChatGPT the question I had been trying to reach all afternoon.
“What does the selector know before it starts choosing?”
It took longer this time.
“It knows the available approved records and their properties, but it does not yet know which approved state holds current continuation authority.”
There it was.
I wrote the observation in plain language.
The system is choosing before it knows what current means.
ChatGPT gave me the more technical version.
“Current continuation authority is being inferred from record properties during boundary selection rather than resolved before boundary selection begins.”
I kept both sentences.
For once, they were saying the same thing at different levels instead of hiding the same uncertainty behind different words.
I went back to the rollback result.
The narrow patch had changed behavior in the earlier test. That had mattered. It told me the eligibility rule was part of the path.
Now this history had proved the patch was not enough.
I marked the narrow repair failed.
ChatGPT did not argue.
Then I saved both histories as regression cases.
Forward progress: newer approved work is current and must survive leave and return.
Rollback: an older approved state is intentionally restored as current while newer historical approvals remain, and that older state must survive leave and return.
Those two histories now formed a pair.
Any future repair had to satisfy both without changing the rule between them.
I looked at the launch status.
Still blocked.
That part no longer felt negotiable.
What had changed was what I was willing to repair next.
I closed the selector patch and opened a new section above it for the order in which continuity decisions were made.
ChatGPT tried one final time to keep the change local.
“We could still preserve the current selector and add an authority marker check before ranking.”
I did not reject that immediately.
Maybe that would eventually be part of the answer.
But I was done pretending I knew enough to patch it in place.
“Not yet,” I typed. “The next question is architecture.”
I gave the new section a title.
Current Authority Before Boundary Selection.
The narrow fix was over.
Chapter 4 would have to decide whether to reopen the continuity flow around that rule instead of stacking one more exception on top of the selector.