Failed Stories Get a Way Forward

New

• A drafted resolution for every failure — When a story fails, the architect reviews what happened and drafts a proposal: retry it as-is, reshape it so it can land, or remove it and rewire the stories that depended on it. The proposal appears on the failed story — and right on the Run page — with the reasoning and the exact changes, one click to approve or dismiss.
• Failures show their blast radius — A failed story's row on the Run page now explains what went wrong in plain words and shows a "blocking N stories" badge when other work is stuck behind it.
• Run-stalled alerts — When a failure leaves nothing else able to progress, the Run page raises a prominent banner naming the story that's wedging the run — with the drafted resolution embedded — and sends a notification so you find out even when you're away.
• Cut a stuck story — When an agent raises its hand because it genuinely can't make progress, you can now cut the story to an honest Failed state instead of looping through diagnose-and-retry forever. Cutting never deletes work: branches and merged code stay put, and the story blocks its dependents until you resolve it.
• Choose where your repos get created, right at the start — Creating a project now asks where its repositories should live — your Git host and workspace — on the new-project screen itself, so the destination is settled before setup begins. Need different homes for different repos? An "Advanced: per-repo destinations" option lets you send individual repositories to their own host or workspace.

Improved

• Clearer failure reasons — Failed stories describe what stopped them in plain language ("merge conflict", "PR closed externally", "authentication failed") instead of internal codes.
• Moving a project between personal and team spaces is dependable — A cross-space move now carries the Git identities the project relies on into its new home, rebuilds the member list fresh for where the project landed, and refuses up front if the destination has nowhere to host the repos — so a move can never leave a project half-relocated. If anyone's Git identity can't follow the move, the dialog tells you who.
• Repo locations stay honest after creation — Once a project's repositories exist, their host and workspace are shown as fixed in settings. Changing the connection method or the account you act as still works; only relocating already-published repos — which Trinity can't do — is held back, instead of a settings change quietly claiming a move that never happened.

Fixed

• Resetting a project clears everything — Reset now wipes all of a project's leftover local state, so starting fresh after a reset no longer leaves stale data behind.
• A clear path when deleting repositories needs extra permission — If your GitHub sign-in lacks permission to delete repositories, the Delete dialog now warns you ahead of time and offers a one-click way to grant it, instead of failing partway with a confusing error.
• Onboarding no longer repeats a question — Fixed a case where the same setup question could appear twice during onboarding.
• Onboarding no longer hangs on "Thinking…" — Fixed cases where the onboarding loader could stay stuck after a step finished, or where retrying a step could clear the step you were on.