I put the two histories side by side and tried to make them disagree as loudly as possible.
On the left was ordinary forward progress. Newer approved work was current, and Story Architect was supposed to bring me back to it.
On the right was rollback. An older approved state had been deliberately restored as current while newer approvals remained in history.
Same product. Same leave-and-return behavior. Opposite direction of authority.
“Give me one rule that explains both,” I typed to ChatGPT. “No new exceptions.”
It answered with the easiest one.
“Prefer the most recent approved state.”
I pointed at the rollback history.
“That one is older.”
ChatGPT adjusted.
“Then prefer the most recent valid approved state that has not been superseded.”
“They are all valid.”
I waited.
The pause was longer this time.
“Then recency and validity are not enough to determine current continuation authority.”
“Good. Stop trying to infer current from record attributes.”
I pulled the two histories closer together on the screen.
The forward-progress case had newer equal current.
The rollback case had older equal current.
That was the whole point.
Any rule that treated chronology as authority would work only when the history happened to cooperate.
“What does the system actually need to know before it compares boundaries?” I asked.
ChatGPT started to answer in implementation terms.
“It could inspect restoration markers, approval timestamps, supersession status, or continuation metadata before ranking candidates.”
“No. Those are still attributes.”
I could hear my own irritation sharpening.
“I am not asking what properties you can inspect. I am asking what decision has to be made first.”
That changed the answer.
“The system has to establish which approved state currently owns continuation authority before comparing candidate boundaries.”
I sat back.
There it was again, but cleaner this time.
Not a condition.
Not a tie-breaker.
A decision that had to happen before the selector was allowed to choose anything.
I opened the existing resume flow and traced it from the top with that distinction in mind.
Story Architect collected approved records.
Then it filtered and ranked them.
Then it tried to infer which returned boundary made the most sense.
By the time continuation authority entered the reasoning, selection was already underway.
ChatGPT followed the trace with me.
“The selector is effectively being asked to discover authority while it is already choosing among records.”
“Exactly.”
I moved to the forward-progress history first.
In that case, the shortcut rules had occasionally looked correct because newer happened to be current.
Recency could impersonate authority.
Then I moved to rollback.
There, the same shortcut failed because older was current by deliberate action.
The system had no stable way to know the difference because it had never established authority before selection began.
I asked ChatGPT to test validity against both histories next.
It did.
Every important state was valid.
That rule collapsed too.
Then I asked about eligibility.
The earlier patch had already shown that changing eligibility could change the returned boundary.
But eligibility alone had not told the system which state should be current. It had only changed which records were available to win.
I put the failed shortcuts in one sentence: recency, validity, eligibility, and restoration markers could all influence selection, but none of them by itself established continuation authority.
ChatGPT gave me the architecture vocabulary for the same problem.
“Current continuation authority is being inferred during boundary selection instead of being resolved before boundary selection starts.”
I kept that version.
Then I looked again at the two histories.
They were no longer just regression tests.
They were proof that the order mattered.
If newer and current always pointed to the same place, the architecture flaw could stay hidden behind a recency rule.
Rollback had broken that illusion.
I could feel the repair getting larger as the diagnosis got cleaner.
That made me uneasy.
Large repairs were dangerous because they invited me to redesign things I had not proved were broken.
But this was no longer one selector comparison gone wrong.
The selector was being asked to operate before the system had answered the question that should constrain it.
ChatGPT tried one last shortcut.
“We could add a pre-ranking authority marker check and leave the rest of the selector unchanged.”
I did not reject it.
I also did not accept it.
“That might be part of the implementation,” I typed. “But first we decide whether the architecture has to change.”
I saved the diagnosis at the top of the repair notes.
Current Authority Before Boundary Selection.
The narrow patch had failed because it had tried to make the selector smarter without giving it the one fact it needed before selection began.
I left the two histories open beneath the heading and moved on to the scope decision.
I left the two regression histories open and gave ChatGPT one last chance to save the smaller repair.
“Defend staying narrow,” I typed. “Strongest case you have.”
It did not hesitate.
“We can keep the eligibility patch and add a rollback-specific precedence rule. Forward progress would continue using the newer eligible state, while intentional restoration would allow the restored older state to take precedence. That would cover both known histories without reopening the continuity architecture.”
I read it twice because that was exactly the kind of answer I could have talked myself into earlier.
Two known failures, two targeted rules, and the temptation to call it done.
Except it was not done.
“Count what that logic actually requires,” I typed.
ChatGPT started listing it.
“One rule for ordinary forward progress. One exception for rollback. A fallback if restoration markers are missing or conflicting. Potential tie-breaking if multiple approved states still qualify.”
I stopped reading there.
“That is the narrow fix?”
ChatGPT paused.
“It is still localized to resume selection.”
“That is not what I asked.”
I copied its own list into the repair notes.
The supposed one-line patch had become a little decision system inside the selector.
One path guessed that newer meant current.
Another path guessed that rollback meant older should win.
A fallback would decide what to do when the signals disagreed.
And none of that answered the question that had broken every shortcut so far.
“After all those conditions run, does the selector know which state is current, or is it still inferring current from markers and ordering?” I typed.
“It would still infer the current state from the available conditions and markers.”
I highlighted that sentence and left it there.
I pulled the forward-progress and rollback histories closer together again.
In one, newer was current.
In the other, older was current.
The visible records could not answer that contradiction by themselves.
The system needed to know what the user had actually established as the place to continue.
I opened a new section in the repair notes.
Allowed scope.
Then I typed the decision I had been avoiding.
Reopen continuity architecture around authority-first resolution.
ChatGPT answered immediately.
“Then we should review persistence reconstruction, recovery paths, rollback handling, approval transitions, resume resolution, and selector behavior as one continuity system.”
“No.”
I almost laughed.
It had taken less than a sentence for the larger repair to become an excuse to touch everything.
“We are reopening one architectural boundary. Not continuity as a whole.”
I wrote the allowed change beneath the heading.
Establish current approved continuation authority before boundary selection begins.
Then I added the first exclusion.
Do not rewrite approval semantics.
ChatGPT helped with the next one.
“Preserve intentional rollback history.”
I added it.
Do not rewrite rollback history.
Then I added another.
Do not change unrelated persistence behavior.
ChatGPT tried to qualify that.
“If persistence participates in authority reconstruction, it may still need adjustment.”
“If the repair proves that, yes. Proximity alone does not earn scope.”
I added one more line.
Do not add recovery work unless authority-first resolution exposes a separate recovery failure.
The exclusions were becoming as important as the repair itself.
I had learned that once a system-level change was open, every adjacent imperfection started looking like part of the same job. ChatGPT was especially good at seeing those connections and especially bad at knowing when the connections were not yet earned by evidence.
I needed it for the first part and me for the second.
“Read the scope back to me,” I typed.
ChatGPT did.
“Allowed: resolve current approved continuation authority before boundary selection. Preserve approval semantics and rollback history. Leave unrelated persistence and recovery behavior unchanged unless the authority-first repair exposes a separate failure there.”
“That is the repair.”
The sentence felt heavier than the eligibility patch had.
The smaller fix had let me imagine I was still one condition away from launch.
This did not.
This meant admitting that the failure lived in the order of operations, not in one bad comparison.
I changed the repair note from selector patch to architecture repair.
For a moment I just looked at the new label.
I had resisted that phrase because it sounded like scope creep.
Now keeping the old label would have been dishonest.
ChatGPT still wanted to helpfully tidy the area around it.
“We could also normalize how recovery and fresh-session persistence construct the authority object so all entry paths share the same logic.”
“Deferred.”
It stopped.
I opened a section called Deferred and moved fresh-session reconstruction, recovery-path normalization, and adjacent continuity cleanup into it.
They could come back if evidence earned them.
They did not get to enter the current repair just because we had noticed them.
I saved the document.
The launch was still blocked.
The narrow patch was over.
And the larger repair finally had edges.
That mattered more than making it feel small.
I had chosen the architecture change deliberately instead of drifting into it one exception at a time.
Now we could turn that decision into a repair contract strict enough to fail.
I kept the architecture note open and told ChatGPT I wanted something another pass could execute without having to guess what we meant.
“Turn this into a repair contract,” I typed. “Not a discussion. Not a list of possibilities. Something we can implement and test.”
ChatGPT responded with a version that immediately tried to solve more than the evidence had earned.
“Resolve current continuation authority, normalize recovery behavior, validate persistence reconstruction, preserve rollback semantics, and then update resume selection to operate within the resolved authority.”
I read it once and deleted half of it.
“You just folded the deferred list back into the repair. Keep only what the current evidence supports.”
I pulled the two regression histories back onto the screen.
The forward-progress case was simple: newer approved work remained current and had to survive an ordinary leave and return.
The rollback case was the opposite: an older approved state had been deliberately restored as current while newer historical approvals remained present, and that older state had to survive the same leave and return.
Those two histories were enough to force the rule we actually needed.
“Write only what both cases require.”
ChatGPT tried again.
“Resolve the current approved continuation authority first. Then permit boundary selection only within that authority.”
I stopped there.
“That is the core rule.”
I pasted it at the top of the contract.
Then I added the release standard above it, where it could not quietly change after implementation.
After a user approves work, leaves, and returns, Story Architect must restore the current approved continuation authority.
I had written that sentence before any of the architecture work. It had survived the failed eligibility patch, the changed-but-still-wrong result, and the rollback test. I wanted it to survive the next repair too.
“Convert the two histories into pass conditions,” I told ChatGPT.
It wrote the forward case first.
“Forward progress passes only if the newer approved state that currently holds continuation authority is restored after leave and return.”
Then the rollback case.
“Rollback passes only if the intentionally restored older approved state remains current after leave and return, even while newer historical approvals remain present.”
I added one more line beneath both.
Both fail if recency, validity, or selector ordering can override the already established authority.
ChatGPT did not argue.
That mattered because the contract was finally describing behavior instead of implementation guesses.
I could change the code later without changing what success meant.
I could also fail the repair without having to debate whether the result was close enough.
I opened the exclusions from the previous Beat and copied in only the constraints that protected the repair boundary.
Preserve approval semantics.
Preserve rollback history.
Leave unrelated persistence and recovery behavior alone unless the core repair exposes a separate failure.
Then I added one more boundary: no selector exception or recency fallback could override resolved authority.
For a few minutes, the document was quiet enough that it felt almost finished.
Then ChatGPT did what ChatGPT did.
“We should add a fresh-session case now. If current authority must survive a new session, persistence reconstruction is part of the contract.”
I looked at the sentence and felt the pull immediately.
It was a good question.
It was probably an important question.
It was also not the question the current repair had earned yet.
“Deferred.”
ChatGPT pushed once more.
“If the warm-session repair passes but fresh-session reconstruction fails, we would still be blocked from release.”
“Yes. And then we will have a new failure with its own evidence.”
I moved fresh-session recovery, persistence reconstruction, and adjacent continuity cleanup into a deferred section under the contract.
I did not delete them.
That distinction mattered.
Deferred did not mean irrelevant. It meant not allowed to contaminate the current repair before the core authority rule had proved itself.
I read the whole document from the top.
The release requirement sat above the core rule. Beneath that were the forward-progress and rollback regressions, their pass conditions, the exclusions, and the deferred questions.
Nothing in it depended on optimism.
Nothing in it required us to remember what we had meant three hours earlier.
And nothing in it allowed a better-looking result to redefine success after the fact.
I saved the contract.
The launch status stayed blocked.
That no longer bothered me in the same way.
Earlier, blocked had meant I had found a failure and did not yet know how large it was.
Now it meant the next repair had a fixed rule, fixed tests, fixed exclusions, and a known boundary around what we were not touching.
Spine Event 2 was done.
The next pass would begin from a contract that could actually prove us wrong.