Building RealWorld with an AI agent and Marionette v5

Exact quotation recovered from the development chat.

Use the `marionette:marionette` plugin to build a complete RealWorld/Conduit example application in this project from the base starter.
Use published Marionette `5.0.0-rc.2` and matching RC2 companion packages where needed. Verify installed versions and use their packaged documentation and tools as the authoritative contracts.
The application should teach idiomatic Marionette v5 architecture. Let the RC2 architecture guides and composed examples inform the design. Implement the complete framework-neutral RealWorld specification and markup, including authentication, feeds, tags, articles, profiles, comments, editor, and settings.
Keep a concise, contemporaneous development journal in `docs/development-journal.md`. Record the documentation and examples consulted, significant architectural decisions and their rationale, assumptions, changes made, checks performed and their results, and problems encountered. Link decisions to relevant documentation and source files. When an approach changes, preserve the original decision and explain what evidence prompted the revision. Distinguish verified facts from assumptions. Record useful decision summaries, not private internal reasoning.
Inspect the project before changing it and preserve unrelated user work. Verify installation, build, lint, types, meaningful browser journeys, and lifecycle cleanup. Review architectural clarity separately from functional test results. Report actual test evidence and any remaining limitations.
Leave usable local files and clear run instructions. Do not publish, push, deploy, or use real credentials.

Exact quotations: the request following the review, then its file-organization follow-up. The preceding review supplied the bug context.

async means application is *generally* true, but some async things can be done from a view's model.. but don't over do that..  we definitely need to fix the bugs.. but absolutely whatever we can do to tighten up the implementation.. one note.. you chose extend Application and View\.extend which is fine, but we should add a note as to why.. it's a little funny to use both in my opinion, but it's not necessarily wrong.. but we should probably note somewhere why that choice was made over choosing one or the other.. or maybe we should choose one or the other.. possibly extends View?  app-frontend already does the .extend example..  but I'm ok either either if there's good reasoning

also one other thing to consider: Refactor file organization to make this Marionette teaching example easier to navigate. Give Auth, Editor, and Settings their own Application and View files, replacing the universal conditional FormView with feature-specific Views. Separate Feed, Article, and Comments Applications from their presentation Views; keep small related Views together.
Organize files by feature, preserve behavior and lifecycle ownership, and avoid new generic abstractions. The goal is to make each workflow’s coordination and presentation easy to find and understand. Update architecture docs and the development journal, then run the existing checks.

Exact quotations recovered from the development chat. These separate requests contributed to the third stage; they are not a single prompt.

Concurrent loading

Review and improve avoidable performance costs in the current Marionette v5 RC2 RealWorld implementation, using the installed version-matched docs.

Start with tags blocking feed loading and article loading blocking comments. Request independent data concurrently while preserving clear ownership, cancellation, cleanup, and existing error behavior. Also inspect for duplicate requests, unnecessary rendering or Markdown parsing, and other unjustified sequential work. Change only demonstrated inefficiencies.

Keep this a faithful RealWorld example: preserve the unchanged specification, acceptance tests, required features, starter markup, appearance, and expected behavior. Consult reference implementations where expectations are ambiguous. Do not add UX, caching, prefetching, lazy loading, abstractions, or resilience policies merely to improve benchmark numbers. Do not alter the benchmark workload.

Preserve unrelated user changes. Run appropriate correctness checks, then rerun only Marionette with the existing shared benchmark harness. Keep the other libraries’ results unchanged and update the comparison with the new Marionette snapshot and evidence.

Report the changes, measured effects, and remaining limitations. Make one commit containing only this task’s changes. Do not push or publish.

Presentation fidelity

Review docs/visual-comparison.md and its screenshot evidence, then fix Marionette-specific visual deviations from the standard RealWorld markup and theme.

Focus on the oversized profile heading, article-tag placement/spacing, extra editor heading/help text, and authenticated mobile navigation wrapping. Confirm each change against the framework-neutral templates and reference implementations; the references differ, so do not blindly copy one app or pursue pixel identity everywhere.

Preserve required features, behavior, accessibility, and idiomatic Marionette v5 RC2 ownership. Do not add styling, UX, abstractions, or polish beyond the base RealWorld example. Preserve unrelated work, including concurrent performance changes.

Rebuild the current implementation and repeat the affected desktop/mobile visual checks using the existing harness and fixtures. Inspect the screenshots, run appropriate correctness checks, and update the visual report with the final snapshot, results, and remaining differences. Do not rerun performance benchmarks for presentation-only changes.

Amend the previous commit as if these fixes were included with the last group. Do not push or publish.

Feed loading and cleanup

Review the current Marionette v5 RC2 RealWorld implementation for loading-state fidelity and bounded code cleanup. Use the installed version-matched docs and framework-neutral RealWorld markup.

Fix feed loading presentation: match the base loading block’s spacing and hide previous rows/pagination while the new query loads, as Vue and Angular do. Preserve request cancellation, error handling, and idiomatic Marionette ownership. Do not copy Angular-specific branding, signup styling, or footer policies.

Inspect these cleanup candidates:
- Repeated action handling across Article, Profile, Comments, and forms.
- Redundant typed state access, casts, or bookkeeping.
- Unused state or orchestration for scenarios the app does not expose.
- Template helpers that obscure markup without meaningful benefit.

Change only demonstrated redundancy. Preserve clear feature boundaries, drafts, all required behavior, and unrelated user changes. Do not introduce a generic action framework, universal form schema, new UX, or abstractions merely to reduce lines. No LOC target; keep the single JS bundle.

Run appropriate correctness checks and inspect loading/success/failure states at desktop and mobile sizes. Update relevant documentation and source counts. If runtime code changes, rerun only Marionette’s existing shared benchmarks and update the comparison; preserve other libraries’ results and the workload.

Report what changed, what candidates were left alone and why, test evidence, and the LOC difference. Amend the current commit with only this task’s changes, preserving its existing contents. Do not push or publish.

Ranges use only measured samples from the final run; they are not confidence intervals.