System Requirements Document for padr-es

1. Introduction

padr-es is a Portuguese-language AI analysis tool for screenshots of game results. The user submits a screenshot; the system independently analyzes the visible result colours and structure, records the analysis and subsequent observed outcomes, and uses prediction errors and accumulated history to improve future analyses. It also retains recurring winning patterns and distinguishes alternation from sequence.

The intended audience is the Analista de padrões, who wants to use screenshot-based analysis to guide the next entry and review how predictions and patterns perform over time. The supplied screenshot is an authoritative reference for the game structure and visible result colours to analyze—not a request to reproduce the betting site or its unrelated controls.

2. System Overview

padr-es provides a custom web interface with five destinations, in the supplied order: Landing, Análise, Histórico, Padrões, and Login. Landing is public. Login is the anonymous identity-verification entry. Análise, Histórico, and Padrões require login.

The application owns user identity and persistent analysis data. A user can sign up independently, then verify their identity when returning to access or continue persisted work. The accepted current behavior is limited to submitting a screenshot for automatic analysis, viewing the resulting guidance, recording the subsequent observed result, reviewing saved analysis history, and consulting saved winning patterns classified as alternation or sequence. The system must not imply that predictions guarantee wins.

The screenshot’s recognizable result structure informs the analysis and visual presentation: blue Player, red Banker, gold Tie, and a compact bead-road history. The screenshot also contains a game-provider interface, account and betting controls, and other site content; these are not accepted padr-es capabilities.

2a. Product Interpretation and Delivery Boundary

The product begins with a user-provided screenshot. The AI analyzes the visible game-result colours and structure on its own after submission. The user can then consult the analysis and its guidance for the next entry. To make learning from errors possible, the user records the subsequent observed result; the system associates it with the relevant analysis, retains it in history, and uses it to improve future analyses and identify recurring winning patterns.

Persistent work is private to the verified user. First use begins at the public Landing page, where the user can proceed to Login to establish identity; returning users verify identity at Login before accessing protected destinations. This identity flow supports continuity of the accepted work and does not imply additional account-management or differentiated-permission features.

The product does not place bets, control the referenced game, or guarantee a winning result. The game and its outcomes remain external; the user supplies screenshots and observed results.

2b. Page Content and Component Coverage

Landing

• Information and state: Public entry explaining screenshot-based analysis, retained history, learning from observed errors, and saved alternation and sequence patterns. It introduces the blue, red, and gold result roles without promising prediction accuracy.
• Primary action: Continue to Login to establish or verify identity before using protected work.
• Supporting content: A concise visual explanation of the screenshot structure being analyzed. Do not reproduce unrelated game-site controls or invent game imagery.
• Components: Compact product introduction; result-colour legend for blue Player, red Banker, and gold Tie; clear entry action.
• States: Loading is not applicable to static explanatory content. If the entry content fails to load, show a readable error and a way to retry or continue when available. Success is reaching Login.

Análise

• Access: Login required.
• Information and state: Submitted screenshot, its captured game region, extracted visible results, AI analysis, guidance for the next entry, and the subsequent observed result associated with that analysis.
• Primary actions: Submit a screenshot for automatic analysis; review the analysis and next-entry guidance; record the subsequent observed result so the prediction can be evaluated and learning can occur.
• Supporting actions: Review the captured game region and extracted result representation, including the blue Player, red Banker, and gold Tie roles where visible.
• Domain entities: Screenshot, captured game region, extracted result, analysis, next-entry guidance, observed result, prediction outcome, and associated history record.
• Components: Screenshot submission and preview; analysis instrument with a prominent current-result readout; three-part blue/red/gold outcome panel; percentage strip when analysis provides percentages; bead-road result history; next-entry guidance; observed-result input and outcome feedback.
• States: Show a clear submission/loading state while analysis runs. On success, show the captured region and analysis. If the image cannot be read or analysis fails, explain that no reliable analysis was produced and allow the user to retry with a screenshot; do not fabricate a result. After an observed result is recorded, show its association with the analysis and whether the prediction was correct or an error. If recording fails, preserve the analysis and allow the user to retry recording. An empty state prompts the user to submit a screenshot.

Histórico

• Access: Login required.
• Information and state: The user’s persisted screenshots, analyses, extracted results, next-entry guidance, and observed outcomes, including prediction errors and their later results.
• Primary actions: Consult saved analysis and result history; open a saved record to review its screenshot, analysis, and associated observed outcome.
• Supporting actions: Resume the relevant analysis context by reviewing its persisted record. Do not imply editing, deletion, export, or filtering capabilities.
• Domain entities: User-owned history record, screenshot, analysis, prediction, observed result, and prediction outcome.
• Components: Chronological history entries; record detail with captured game region and analysis/result relationship.
• States: Show loading while history is retrieved. An empty state explains that records appear after analysis. On success, show persisted records. If retrieval fails, explain the problem and allow retry. A record whose image or analysis cannot be displayed must retain its available result information and show a recoverable error.

Padrões

• Access: Login required.
• Information and state: Persisted recurring winning patterns identified from accumulated results, classified as alternância or sequência, with their associated result history sufficient to understand the pattern’s observed performance.
• Primary actions: Consult saved winning patterns and distinguish alternation from sequence.
• Supporting information: Show the relevant colour sequence and its observed historical context. Do not present a pattern as a guaranteed future win.
• Domain entities: Winning pattern, pattern type, colour sequence, and associated observed results.
• Components: Pattern entries grouped or labelled by alternation and sequence; readable colour markers and sequence representation.
• States: Show loading while patterns are retrieved. An empty state explains that patterns appear as recurring winning patterns are identified from recorded results. On success, show saved patterns and their type. If retrieval fails, explain the problem and allow retry.

Login

• Access: Public identity-entry destination.
• Information and state: Sign-up for first use and identity verification for returning access to persisted work.
• Primary actions: Establish identity through self-service sign-up; verify identity when returning.
• Supporting actions: Continue to the protected destination after successful identity establishment or verification.
• Domain entities: Application-owned identity and authenticated session.
• Components: Sign-up and returning-user verification forms; clear success and error feedback.
• States: Show form submission progress. On success, continue to the protected work. On invalid or failed verification, explain the failure and allow retry. If identity establishment fails, retain the entry context and allow retry. Do not add unrelated account-management functions.

3. Functional Requirements

1. As an Analista de padrões, I should be able to submit a screenshot of the referenced game-result structure for automatic analysis.
   Provenance: explicit for screenshot submission and automatic analysis; required_inference for associating the analysis with persistent history.
   Lifecycle and access: From Análise, after Login, the user submits a screenshot. The system analyzes the visible colours and results independently and associates the screenshot and analysis with the user’s persisted work.
   Observable acceptance: The user sees the submitted image or captured game region and the analysis result. If the image cannot be interpreted or analysis fails, the system reports that no reliable result is available and permits retry; it does not invent extracted results. The user can continue by reviewing the analysis and its next-entry guidance.

2. As an Analista de padrões, I should be able to review analysis of the visible game-result colours and structure and use its guidance for the next entry.
   Provenance: explicit for analysis and guidance about the next colour to enter; required_inference for presenting the result in a usable form.
   Lifecycle and access: From Análise, after Login, the user reviews the AI’s analysis of the submitted screenshot. The analysis represents visible blue Player, red Banker, and gold Tie results where present, and provides the next-entry guidance produced by the analysis.
   Observable acceptance: The user can distinguish the analyzed results and guidance. If the screenshot does not support a reliable analysis, the system communicates that limitation and offers screenshot retry rather than presenting a fabricated prediction. The user can continue by recording the subsequent observed result.

3. As an Analista de padrões, I should be able to record the result observed after an analysis so that the system can evaluate its guidance and learn from errors.
   Provenance: explicit for learning from errors when the predicted colour is not correct and improving over time; required_inference for the user’s observed-result input and its association with the relevant analysis.
   Lifecycle and access: From Análise, after Login, the user supplies the subsequent observed result for the relevant analysis. The system associates it with that analysis, determines whether the guidance was correct or an error, and retains the result for future learning.
   Observable acceptance: The user sees the recorded outcome and its relationship to the prediction. An incorrect prediction is retained as an error and its observed result is available to improve future analyses. If recording fails, the analysis remains available and the user can retry. The user can continue to Histórico to review the record or Padrões to consult saved patterns.

4. As an Analista de padrões, I should be able to consult and resume review of my saved analysis and result history over time.
   Provenance: explicit for saving history for consultation and learning over time; required_inference for user-owned persistence and revisiting records.
   Lifecycle and access: From Histórico, after Login, the user reviews persisted screenshots, analyses, and observed results, including errors and their later outcomes. The system retains the association between each analysis and its recorded result.
   Observable acceptance: The user can open a saved record and see its available screenshot, analysis, and associated outcome. Empty history is clearly indicated. If retrieval or record display fails, the system reports the failure and allows retry while preserving available record information. The user can continue to Análise for a new screenshot or Padrões to review recurring patterns.

5. As an Analista de padrões, I should be able to consult saved recurring winning patterns and distinguish alternation from sequence.
   Provenance: explicit for retaining winning patterns and distinguishing alternation and sequence; required_inference for presenting the patterns with their observed historical context.
   Lifecycle and access: From Padrões, after Login, the user reviews patterns identified from accumulated observed results. The system retains the pattern type and associated colour sequence.
   Observable acceptance: Saved patterns are identifiable as alternation or sequence and are presented as historical observations, not guaranteed predictions. If no qualifying pattern is available, the user sees an empty state; if retrieval fails, the user can retry. The user can continue to Histórico to inspect the underlying records or Análise to submit another screenshot.

6. As an Analista de padrões, I should be able to establish identity on first use and verify identity when returning to persisted work.
   Provenance: required_inference, based on the accepted application-owned identity and durable user-specific history.
   Lifecycle and access: From public Landing, the user proceeds to Login and establishes identity through self-service sign-up. On return, the user verifies identity at Login before accessing Análise, Histórico, or Padrões.
   Observable acceptance: Successful first-use establishment or returning verification enables access to protected work; failure is explained and can be retried. The user continues to the requested protected destination. No additional account-management or differentiated-permission behavior is implied.

4. User Personas

Analista de padrões

Provenance: required_inference, as specified by the accepted Planning Scope persona catalog.

The Analista de padrões submits screenshots of game results and relies on the system to identify visible colours and structure without requiring manual analysis of the image. Their distinct responsibility is to connect each analysis to the result that follows: they consult the next-entry guidance, record the observed result, and use the retained history to understand prediction errors and recurring winning patterns. They distinguish patterns of alternation from sequences and review their performance over time without treating an analysis as a guarantee.

Their inputs are screenshots and subsequent observed results. Their success is being able to revisit persisted analyses and outcomes and consult saved winning patterns that are clearly classified as alternation or sequence.

5. Core User Flows

1. First use and identity establishment

1. The Analista de padrões opens public Landing and reviews the screenshot-analysis purpose and the blue, red, and gold result roles.
2. The user proceeds to Login and completes self-service sign-up.
3. On success, the user continues to Análise. If sign-up fails, the user sees an error and can retry.
4. The user can begin a screenshot analysis. Identity establishment does not add unrelated account-management tasks.

2. Submit a screenshot, review analysis, and record the observed result

1. The verified Analista de padrões opens Análise and submits a screenshot of the game-result structure.
2. The system analyzes the visible results independently and associates the screenshot and analysis with the user’s persisted work.
3. The user reviews the captured game region, extracted colour results, and next-entry guidance. Where visible, blue represents Player, red Banker, and gold Tie.
4. If the screenshot cannot be read or analysis fails, the user sees that no reliable analysis is available and can retry with a screenshot. No result is fabricated.
5. After the next result is observed, the user records it against the relevant analysis.
6. The system shows whether the guidance was correct or an error and retains the observed result. If recording fails, the user can retry without losing the analysis.
7. The user continues to Histórico to review the saved record or Padrões to consult saved patterns.

3. Return to persisted work

1. The returning Analista de padrões opens public Landing and proceeds to Login.
2. The user verifies identity.
3. On success, the user continues to Histórico, Análise, or Padrões as needed. If verification fails, the user sees an error and can retry.
4. Protected history, analyses, and patterns remain unavailable until identity is verified.

4. Review analysis history

1. The verified user opens Histórico.
2. The system retrieves the user’s saved screenshots, analyses, and observed results.
3. The user opens a record to review its captured game region, analysis, guidance, and associated observed outcome, including a recorded prediction error where applicable.
4. If there are no records, the page explains that history appears after analysis. If retrieval or display fails, the user sees an error and can retry; available record information remains visible.
5. The user continues to Análise for another screenshot or Padrões to review recurring patterns.

5. Review saved patterns

1. The verified user opens Padrões.
2. The system presents saved recurring winning patterns identified from accumulated results, distinguishing alternância from sequência.
3. The user reviews the colour sequence and its observed historical context. The presentation does not promise future wins.
4. If no qualifying pattern has been identified, the user sees an empty state. If retrieval fails, the user can retry.
5. The user continues to Histórico to inspect saved outcomes or Análise to submit another screenshot.

6. Visuals Colors and Theme

The visual direction is Instrumental clarity for reading the next pattern, with MARQ by Garmin as its muse. The interface should feel like a precise, dependable instrument for reading game-result colours and patterns, not a generic analytics dashboard.

Colour tokens

Use blue, red, and gold for their respective result roles. Gold is a restrained highlight and divider colour as well as the Tie result colour; it must not replace the blue or red outcome coding. Maintain readable contrast on graphite surfaces.

Typography

• Headings and result numerals: Barlow Condensed, strong compact weights.
• Body: Source Sans 3, clear medium-weight text.
• Technical labels: restrained uppercase micro-labels.
• Numerals: tabular numerals for histories, counts, and timestamps.
• Scale: display 40px on mobile to 76px on desktop; section headings 28–40px; result labels 18–24px; body 16–18px; technical labels 12–14px. Use responsive clamp() sizing and wrapping so text fits at 375px, 768px, and 1280px.

Shape, layout, and imagery

Use graphite instrument panels with precise ruled edges, compact rounded rectangles, and a few dial-inspired circular markers. Keep the screenshot’s recognizable hierarchy and result roles: compact status header, prominent current result, three-part blue Player / gold Tie / red Banker outcome area, percentage strip when available, and dense bead-road history. In the analysis experience, screenshot submission and analysis are the clear working actions; history and saved patterns remain direct destinations.

Use the user-provided screenshot as the analysis input and show its captured game region in the analysis record. Do not add unrelated stock photography or invented game imagery. Use high-contrast colour markers and grid lines for extracted outcomes. On narrow screens, the bead road may scroll horizontally so every result can be brought fully into view.

Responsive and accessibility requirements

At 375px, stack the analysis regions in the same order as desktop, scale the readout and dial to fit, and allow the bead road to scroll horizontally. At 768px and 1280px, preserve the readable hierarchy and keep all labels, controls, and result text within their containers. Do not let dials, arcs, imagery, or scrolling content cover readable text or controls. Ensure every scrollable result can be brought fully into view.

7. Signature Design Concept

Build the Análise destination as a dark, left-aligned instrument console using the screenshot’s result structure. A compact header leads into a large condensed current-result numeral with a small gold recency arc that does not cover the numeral. Beneath it, a broad three-zone instrument places blue Player and red Banker fields around a gold circular Tie readout, with labels and values fully contained at mobile and desktop sizes.

Place the next-entry guidance control below the outcome instrument, followed by a slim three-colour percentage rail with each percentage centered in its own segment when percentages are available. Finish with the ruled bead-road grid, using the screenshot’s colour-token structure and horizontal scrolling on narrow screens. Keep screenshot submission and analysis as the clear working action. This concept recomposes accepted analysis content and controls only; it does not add a new behavior or destination.

8. Interaction Model & Motion Direction

Interaction Model: Animated
Motion Tempo: restrained
Hero Dimensionality: dimensional_css

Landing Hero Motion Brief

• Focal subject: The screenshot-derived result instrument: blue Player, gold Tie, red Banker, and the bead-road colour history.
• Input → transformation → outcome thesis: A user submits a screenshot; the system analyzes its visible result colours and structure; the user receives analysis and next-entry guidance that can later be compared with the observed result.
• Motion vocabulary: Precise, restrained instrument feedback. When a new analysis arrives, use a short needle-like sweep or number count, then settle to a static result. State changes are immediate and must not interfere with reading or uploading.
• Composed first frame: A dark, left-aligned console with a compact header, prominent result readout, three-part outcome instrument, percentage strip when available, and bead-road history. Keep the screenshot submission action clear and visible.
• Reduced-motion state: Show a static result with no sweep or count animation. Keep history usable through horizontal scrolling so each result can be brought fully into view.

9. Non-Functional Requirements

1. Readable responsive presentation — explicit in the Creative Direction. Readable text and controls must remain whole and unobscured at 375px, 768px, and 1280px. Use wrapping or responsive scaling where needed.
2. Scrollable result history — explicit in the Creative Direction. On narrow screens, the bead road may scroll horizontally; every result must be fully readable when brought into view.
3. Reduced-motion usability — explicit in the Creative Direction. Respect prefers-reduced-motion by presenting a static result and retaining usable scrollable history.
4. Persistent user-owned work — explicit for saving history and patterns; required_inference for identity-bound continuity. Persist screenshots, analyses, and observed outcomes so the user can consult them over time and the system can learn from them. Keep each user’s persisted work associated with the verified identity.
5. Truthful analysis presentation — explicit in the Creative Direction. Do not imply guaranteed winning predictions. Distinguish analysis, observed outcomes, and historical pattern performance.

10. Tech Stack

• Frontend: React. [Default — not specified by user]
• Backend: Python with FastAPI, using one shared backend for analysis, identity, history, and pattern APIs. [Default — not specified by user]
• Persistence: PostgreSQL for user identity and durable analysis, result, and pattern records; object storage for submitted screenshots and captured game regions. [Default — not specified by user]
• AI analysis: An image-analysis component integrated with the shared backend to extract visible results and produce analysis. The specific model or provider is not specified.
• Deployment: Docker and docker-compose for the application services. [Default — not specified by user]

11. Assumptions and Constraints

• The supplied screenshot is authoritative as a reference for the game structure and visible result colours the AI should analyze. It is not a request to reproduce the referenced site’s betting, account, or game controls.
• The user submits screenshots and records subsequent observed results; the referenced game and its outcomes remain external.
• The user’s request to learn from errors requires associating an observed result with the relevant analysis. This is a required_inference needed for the accepted learning outcome.
• The Planning Scope’s application-owned identity and durable-state requirements apply to the accepted history and patterns. Login is the public identity-entry destination; Análise, Histórico, and Padrões require login.
• The current page inventory and access are fixed by the supplied versioned page contract: Landing (public), Análise (login), Histórico (login), Padrões (login), Login (public).
• No future requirements were supplied. No additional betting, game-control, account-management, export, deletion, or permission-management capabilities are included.

12. Glossary

• Alternância: A recurring pattern in which result colours alternate.
• Análise: The AI’s interpretation of visible game results in a submitted screenshot and its guidance for the next entry.
• Bead road: A compact grid-like history of colour-coded game results, based on the supplied screenshot’s structure.
• Banker: The red result role shown in the reference screenshot.
• Empate / Tie: The gold result role shown in the reference screenshot.
• Histórico: Persisted screenshots, analyses, and observed results available for later consultation.
• Player: The blue result role shown in the reference screenshot.
• Sequência: A recurring ordered sequence of result colours that is not classified as alternation.
• Observed result: The result the user records after an analysis, used to evaluate its guidance and support learning.