Restore the last open Content page

[3mdistal]

Problem

Opening Content at its root currently selects the first favorite page, or simply the first page returned by the document list. That makes arrival arbitrary for returning people and can drop a new person into an organization-visible page they did not choose.

Content should instead reopen the last page that person successfully loaded. When there is no usable saved page, it should provide a private place to begin rather than borrowing someone else's context.

Approach

Resolve root arrival through one typed action. The action reauthorizes any saved document before returning it; otherwise it creates or reuses a claimed Welcome to Agent-Native Content page in the caller's Personal space. Explicit /page/:id links continue to bypass root restoration.

The last-location key is intentionally separate from agent-facing navigation state. It is written only after the editor has loaded the target, and writes are serialized so a slower earlier navigation cannot overwrite a later one.

What changed

• Added resolve-content-landing, including authorization, deleted-page handling, canonical per-user welcome identity, and concurrent creation convergence.
• Preserved a renamed welcome page as the user's landing page and advanced its claimed generation after trashing or a deterministic-ID collision, creating one fresh replacement without restoring deleted work or exposing another user's page.
• Replaced root's first-document selection with the resolver and a generic fallback notice that does not expose the unavailable page's metadata.
• Persisted the last successfully loaded page from the editor with observable error feedback and ordered writes.
• Localized the new feedback, documented the action/state surface, updated the session-restore product contract, and added a user-facing changelog entry.

Safety and operations

The saved target is treated only as an opaque ID and is reauthorized on every root arrival. Missing, trashed, soft-deleted, or inaccessible targets fall back without returning their title, preview, owner, or prior context. The active welcome page is private, top-level, editable, and constrained to the caller's Personal space. A per-user application-state claim with an unpredictable replacement ID makes concurrent creation, post-trash replacement, and inaccessible-ID collision recovery converge without resurrecting or revealing unrelated work. Forward-compatible state fields remain part of exact compare-and-set checks, while malformed stored state fails visibly instead of looping.

There is no schema migration or backfill. Rolling back stops new restoration and returns root arrival to the previous first-document behavior; already created private welcome pages remain ordinary user-owned pages.

Verification

• Exact pushed head: aa98ee239; this includes unpredictable replacement welcome IDs and fresh prospective merge-tree CI is running against current main.
• Focused landing and parity tests: 13 passed, including authorized restore, denied/deleted fallback, no arbitrary existing-page selection, canonical email reuse, concurrent creation, renamed-page reuse, convergent replacement after trashing, recovery from preclaimed predictable IDs by persisting an unpredictable replacement claim with forward-compatible state, and loud failure for stored null state.
• Content typecheck passed at fe1a5bf76. The full 51-guard suite passed at ancestor 61dc0d061; focused landing and parity tests (13/13) plus Content typecheck pass at aa98ee239; all required prospective merge-tree CI checks pass at aa98ee239, including Content DB tests, lint/format, build, scaffold E2E, and generated standalone Chat smoke, including Content DB tests, lint/format, build, scaffold E2E, and generated standalone Chat smoke.
• Independent technical review found two client persistence edge cases; both were fixed and the same reviewer confirmed the repair range had no remaining finding.
• Builder review then found renamed/deleted welcome recovery defects at 20ec20aa3; both are repaired in 49bd90dc9 and covered by focused database tests.
• Same-context browser acceptance passed on 61dc0d061 in the T3 preview against a fresh auth-disabled disposable SQLite runtime: a fresh user landed on an editable private Personal welcome page; renaming it to Renamed Welcome QA persisted; revisiting / returned to the same document ID with the renamed title. The later changes are server-only collision and malformed-state handling covered by database regressions; the interactive story was not repeated. The earlier acceptance at 20ec20aa3 also confirmed last-page restoration and explicit-link bypass. T3 screenshot capture remained unavailable, so retained evidence is URL/DOM plus runtime and database read-back.

Review focus

• Confirm the resolver's authorization and Personal-space invariants are the right boundary for stale saved IDs.
• Check the CAS-backed welcome claim under concurrent root loads, post-trash replacement, inaccessible deterministic-ID collisions, and malformed stored state.
• Inspect the editor's ordered state-write behavior and the generic fallback/error feedback.

content_product_impact:
  lane: contract_fulfillment
  features:
    - content.feature.find-your-place-again
  capabilities:
    - content.workspace.session-restore
  record_change: included
  proof:
    - pnpm --dir templates/content exec vitest --run actions/resolve-content-landing.db.test.ts parity/__tests__/matrix-action-coverage.test.ts
    - pnpm --dir templates/content typecheck
    - pnpm guards
  rationale: The change fulfills the approved Page-level arrival contract while leaving full View and renderer-state restoration for later work.

[github-actions]

Visual recap — screenshot failed

A recap was published, but the PR-comment screenshot could not be captured or uploaded. Open the interactive recap directly:

Open the full interactive recap

Diagnostic:

light: page.goto: Timeout 45000ms exceeded. Call log: - navigating to "https://plan.agent-native.com/recaps/recap-e1a8e326005d479c?recapScreenshot=1&recapScreenshotTheme=light", waiting until "domcontentloaded"

[builder-io-integration]

Builder reviewed your changes — looks good ✅

Review Details

Incremental Code Review Summary

This update addresses the remaining predictable-ID denial-of-service concern. The resolver now uses the legacy deterministic ID only as a compatibility lookup; when it needs to create or replace a welcome page, it generates a UUID-derived ID and persists that claim with CAS. Subsequent root arrivals reuse the persisted ID, while concurrent callers converge on the winner. The existing ownership, Personal-space, private, top-level, authorization, and soft-delete checks remain in place.

The previous review comment was verified fixed and resolved. Two independent incremental reviewers found no new actionable issues, and the focused landing database suite passes 10/10, covering legacy collision migration, renamed and trashed welcome pages, malformed state, and concurrency.

Risk assessment: Standard risk, due to stateful Content landing and authorization behavior without schema or authentication changes.

🧪 Browser testing: Will run after this review (PR touches UI code)