Rssmonster Browser

RSSMonster Browser

Purpose

Use the browser to inspect RSSMonster as an actual running application.

This skill is intended primarily for:

• UX development
• frontend implementation
• responsive design
• visual regression checking
• interaction validation
• frontend/backend integration validation
• reproducing UI bugs
• verifying completed frontend work

Do not judge frontend correctness only from source code when the changed behavior can be validated in the browser.

The rendered application is the source of truth for visual and interaction behavior.

Use Codex's browser capability, such as @Browser, when available.

Core principles

Inspect the real application

For frontend or UX changes, open RSSMonster in the browser and verify the actual rendered result.

Do not conclude that a design is correct merely because:

• the Vue template looks correct;
• the CSS appears correct;
• the component compiles;
• tests pass;
• the intended classes are present.

Visual and interaction changes must be evaluated in the rendered application whenever practical.

Do not assume local ports or URLs

Determine the actual local RSSMonster URLs from the repository and runtime configuration.

Inspect relevant configuration such as:

• package scripts
• Vite configuration
• environment files or templates
• server configuration
• client API configuration
• development proxy configuration
• existing documentation

Do not assume that the frontend runs on a particular port.

Do not assume that the API runs on a particular port.

Use the actual configured runtime values.

Reuse running processes

Before starting additional development processes, determine whether RSSMonster is already running.

Prefer existing running:

• client development server
• Express server
• worker processes
• inference services

when they are sufficient for the requested browser validation.

Do not unnecessarily create duplicate development processes.

If a required process is not running, use the repository's existing scripts to start it.

Do not invent alternative startup commands when existing repository scripts already provide the required behavior.

Preserve the browser session

Reuse the existing browser profile/session where possible.

Preserve:

• cookies
• local storage
• session storage
• authentication state
• application preferences

Do not clear browser storage unless explicitly required for the test.

Do not log the user out as part of ordinary browser validation.

Never store, infer, guess, or hard-code credentials.

If RSSMonster displays the login screen because authentication is required or the session has expired, stop at that point and ask the user to authenticate manually.

After authentication has been completed, continue using the same browser session.

Browser procedure

1. Understand the requested behavior

Before opening the browser, determine what needs to be validated.

Identify:

• the requested feature or bug fix;
• the intended user workflow;
• the relevant page or component;
• important visual states;
• important interaction states;
• required desktop/mobile behavior;
• any explicit design reference provided by the user.

Do not broaden the task into a general UI redesign.

Use the requested design and agreed behavior as the acceptance criteria.

2. Inspect relevant application architecture

Before making assumptions about how to reach the feature, inspect the relevant existing code.

Where applicable inspect:

• Vue routes
• components
• stores
• composables
• API calls
• authentication behavior
• layout components
• responsive CSS
• application settings
• backend routes supporting the UI

Follow existing RSSMonster architecture and conventions.

Do not introduce new frontend architecture merely to make browser validation easier.

3. Determine runtime configuration

Find the actual local application URL and, where relevant, API URL.

Use repository configuration rather than assumptions.

Confirm that the required application processes are running.

If processes must be started:

• use existing package scripts;
• wait until startup has completed;
• confirm that the application responds before continuing.

If the repository exposes a health endpoint or equivalent startup indicator, use it where appropriate.

4. Open the application

Open the actual RSSMonster application in the browser.

Navigate directly to the relevant route when known.

Otherwise open the normal application entry point and navigate through the real UI.

Verify that the expected page actually rendered.

Do not treat a successful HTTP response alone as evidence that the application is usable.

5. Verify authentication state

Confirm that the application is in the expected authenticated state.

If the intended RSSMonster UI is visible, continue.

If the browser shows:

• the login page;
• an expired-session message;
• an authentication redirect;
• another state requiring credentials;

do not attempt to guess or recover credentials.

Ask the user to authenticate manually and preserve the session afterward.

6. Reproduce the real user workflow

Use the application as a user would.

For the feature being reviewed, perform the actual relevant interactions.

Examples include:

• opening an article
• switching folders
• expanding or collapsing UI elements
• clicking tags
• opening menus
• scrolling
• changing filters
• navigating between articles
• marking content read
• bookmarking
• triggering hover/focus states
• resizing the viewport
• opening dialogs
• testing empty/loading/error states

Do not validate only the initial static state when the feature is interactive.

7. Inspect visual quality

For UX work, inspect the actual rendered design.

Evaluate where relevant:

• visual hierarchy
• spacing
• alignment
• typography
• density
• icon sizing
• color emphasis
• borders
• shadows
• whitespace
• wrapping
• truncation
• overflow
• clipping
• scrollbar behavior
• state visibility
• consistency with nearby RSSMonster UI
• whether controls attract the intended amount of attention

Look for unintended changes outside the feature itself.

Pay attention to whether the new design still feels native to the existing RSSMonster interface.

8. Validate responsive behavior

If the changed UI can appear on multiple screen sizes, inspect relevant responsive states.

At minimum, where applicable, validate:

• normal desktop layout
• narrower desktop/tablet layout
• mobile layout

Use representative viewport sizes rather than relying only on CSS inspection.

Check for:

• horizontal overflow
• overlapping controls
• unexpected wrapping
• inaccessible actions
• clipped text
• excessive vertical space
• broken fixed/sticky elements
• incorrect breakpoints
• touch-target problems
• layouts that technically fit but become visually unusable

Do not require every possible viewport width unless the task specifically concerns complex responsive behavior.

9. Validate interaction states

Inspect relevant states beyond the default state.

Depending on the feature, check:

• default
• hover
• focus
• active
• selected
• expanded
• collapsed
• disabled
• loading
• empty
• error
• long-content
• many-items
• few-items

For overflow-related UI, intentionally inspect realistic edge cases.

Examples:

• long article titles
• many tags
• long tag names
• many sources
• unusually long feed names
• narrow viewports

Use actual application data when suitable examples already exist.

Do not fabricate persistent production data merely for visual testing unless explicitly required.

10. Inspect console errors

Inspect the browser console for errors relevant to the changed functionality.

Pay particular attention to:

• uncaught JavaScript exceptions
• Vue warnings
• failed component rendering
• undefined/null property access
• repeated error loops
• failed dynamic imports
• authentication errors
• API failures caused by the changed implementation

Do not fail the review merely because unrelated pre-existing console noise exists.

Distinguish clearly between:

• errors introduced by the implementation;
• relevant existing errors;
• unrelated pre-existing warnings.