Skip to content

Add product workflow and API preview - #30

Open
LukasParke wants to merge 2 commits into
mainfrom
agent/finish-openapi-generator
Open

Add product workflow and API preview#30
LukasParke wants to merge 2 commits into
mainfrom
agent/finish-openapi-generator

Conversation

@LukasParke

@LukasParke LukasParke commented Aug 14, 2026

Copy link
Copy Markdown
Owner

Agent: This follow-up completes the product-quality and developer-experience work added after the original editor-completion pull request merged.

What changed

  • add continuous OpenAPI validation, autosave, undo/redo, keyboard shortcuts, and a Ctrl+K quick switcher
  • add a review workspace with live JSON/YAML source and clipboard actions
  • add a lazy-loaded Scalar interactive documentation and API client preview
  • recover unsaved drafts from local storage after crashes or refreshes
  • validate imports before persisting or replacing the active document
  • replace Node-based filename handling with a browser-native implementation
  • replace the 1.3 MB path error image with a lightweight accessible error state
  • document the completed product-quality and developer-experience plans

Verification

  • pnpm check
  • pnpm test — 5 files, 10 tests
  • pnpm lint
  • pnpm build
  • production smoke test: /, /info, /servers, /authentication, /paths, /components, /webhooks, /review, and /preview all returned HTTP 200

Greptile Summary

This change introduces editor-session workflows including autosave, manual save, draft recovery, history controls, validation, review tooling, navigation, and API preview. Two correctness issues were verified: a delayed autosave can overwrite a newer manual save, and invalid local references targeting inherited object properties are not surfaced as diagnostics. These issues should be resolved before merge to prevent lost specification edits and incomplete validation feedback.

Confidence Score: 3/5

Not merge-safe until the two verified P1 correctness issues are fixed.

There are two independent P1 findings and neither is security-related, which results in a score of 3 under the required scoring table.

Files Needing Attention: src/lib/editorSession.ts needs write ordering or stale-write rejection; src/lib/validation.ts needs own-property checks during local reference traversal.

T-Rex T-Rex Logs

What T-Rex did

  • Set up a controlled autosave and manual-save race harness to exercise the P1 finding.
  • Run the autosave race and capture its execution output to support the P1 finding validation.
  • Create a focused inherited local-reference reproduction harness to exercise the P1 finding.
  • Inspect the observed inherited local-reference validation output to confirm the finding behavior.

View all artifacts

T-Rex Ran code and verified through T-Rex

Prompt To Fix All With AI
### Issue 1
src/lib/editorSession.ts:107-108
**Stale autosaves overwrite newer revisions**

An autosave that has already entered `saveSpec(pending)` is not cancelled or prevented from committing when a later manual save completes. If the older request resolves last, it writes its stale snapshot over the newer revision in storage; reopening the document then loses the recent edits. Serialize writes or make persistence reject stale revisions, rather than using `autosaveRevision` only to gate the status indicator.

### Issue 2
src/lib/validation.ts:38-39
**Prototype properties resolve as local references**

`segment in current` follows the prototype chain, so otherwise-invalid local references such as `#/constructor` and `#/toString` are treated as resolved and omitted from diagnostics. Require an own property at each segment, such as with `Object.hasOwn(current, segment)`, before advancing the traversal.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

Reviews (1): Last reviewed commit: "feat: add interactive API preview" | Re-trigger Greptile

Greptile also left 2 inline comments on this PR.

@coderabbitai

coderabbitai Bot commented Aug 14, 2026

Copy link
Copy Markdown

Warning

Review limit reached

@LukasParke, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 14 minutes

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: ff343bc9-063d-4332-8b74-b193eef8fdeb

📥 Commits

Reviewing files that changed from the base of the PR and between a991c8c and d1e9608.

⛔ Files ignored due to path filters (2)
  • pnpm-lock.yaml is excluded by !**/pnpm-lock.yaml
  • src/routes/paths/[index]/error.jpg is excluded by !**/*.jpg
📒 Files selected for processing (22)
  • README.md
  • docs/implementation-plan.md
  • package.json
  • src/app.html
  • src/lib/components/FileManagement/DownloadButtons.svelte
  • src/lib/components/FileManagement/SaveButton.svelte
  • src/lib/components/FileManagement/UploadModal.svelte
  • src/lib/components/QuickSwitcher.svelte
  • src/lib/editorSession.integration.test.ts
  • src/lib/editorSession.ts
  • src/lib/filename.test.ts
  • src/lib/filename.ts
  • src/lib/importSpec.test.ts
  • src/lib/importSpec.ts
  • src/lib/validation.integration.test.ts
  • src/lib/validation.ts
  • src/routes/+layout.svelte
  • src/routes/+page.svelte
  • src/routes/FancyAppRail.svelte
  • src/routes/paths/[index]/+error.svelte
  • src/routes/preview/+page.svelte
  • src/routes/review/+page.svelte

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

Comment thread src/lib/editorSession.ts
Comment on lines +107 to +108
await saveSpec(pending);
if (revision === autosaveRevision) saveStatus.set('saved');

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Stale autosaves overwrite newer revisions

An autosave that has already entered saveSpec(pending) is not cancelled or prevented from committing when a later manual save completes. If the older request resolves last, it writes its stale snapshot over the newer revision in storage; reopening the document then loses the recent edits. Serialize writes or make persistence reject stale revisions, rather than using autosaveRevision only to gate the status indicator.

Artifacts

Controlled autosave and manual-save race harness

  • Vitest harness that holds an older autosave and a newer manual save independently, completes the newer save first, then completes the older autosave to inspect persisted state—the takeaway is that the test deterministically exercises the claimed stale-write ordering.

Autosave race execution output

  • Captured successful Vitest output shows persisted state changing from "Newer manual save" to "Older autosave snapshot" when the older autosave finishes last—the takeaway is that the stale autosave overwrites the later manual save.

View artifacts

T-Rex Ran code and verified through T-Rex

Prompt To Fix With AI
This is a comment left during a code review.
Path: src/lib/editorSession.ts
Line: 107-108

Comment:
**Stale autosaves overwrite newer revisions**

An autosave that has already entered `saveSpec(pending)` is not cancelled or prevented from committing when a later manual save completes. If the older request resolves last, it writes its stale snapshot over the newer revision in storage; reopening the document then loses the recent edits. Serialize writes or make persistence reject stale revisions, rather than using `autosaveRevision` only to gate the status indicator.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

Comment thread src/lib/validation.ts
Comment on lines +38 to +39
if (!current || typeof current !== 'object' || !(segment in current)) return false;
current = (current as Record<string, unknown>)[segment];

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Prototype properties resolve as local references

segment in current follows the prototype chain, so otherwise-invalid local references such as #/constructor and #/toString are treated as resolved and omitted from diagnostics. Require an own property at each segment, such as with Object.hasOwn(current, segment), before advancing the traversal.

Artifacts

Focused inherited local-reference reproduction harness

  • A Vitest harness invokes `validateDocument` with otherwise-valid minimal OpenAPI documents containing `#/constructor` and `#/toString`, establishing the expected unresolved-reference diagnostics.

Observed inherited local-reference validation output

  • Executed Vitest output shows both references returned empty diagnostics and failed the expected unresolved-reference assertions, proving inherited prototype segments are incorrectly accepted.

View artifacts

T-Rex Ran code and verified through T-Rex

Prompt To Fix With AI
This is a comment left during a code review.
Path: src/lib/validation.ts
Line: 38-39

Comment:
**Prototype properties resolve as local references**

`segment in current` follows the prototype chain, so otherwise-invalid local references such as `#/constructor` and `#/toString` are treated as resolved and omitted from diagnostics. Require an own property at each segment, such as with `Object.hasOwn(current, segment)`, before advancing the traversal.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant