System Requirements Document for instagram-account-recovery

1. Introduction

Product intent. This product helps one anxious individual recover a hacked or locked Instagram account. The immediate, concrete case is Deepika Batwal's own account, deep_sardarni712, which was hacked. The product exists to take a frightening, opaque situation — losing control of an account — and turn it into a calm, legible, numbered recovery process: report the hack, verify the claim, and recover the account.

Audience. The product serves two accepted human roles:

• The Account Recovery Seeker — an individual (not a business or creator account manager) whose Instagram account has been hacked or locked and who has lost access. Their goal is to regain access to the compromised account.
• The Recovery Case Reviewer — a support-side human who reviews submitted hacked-account recovery requests, verifies the claim, and guides or approves the recovery path so the seeker regains access.

Scope boundary. Scope is limited to Instagram account recovery for hacked or locked accounts, with the user's own account being deep_sardarni712. The product is not a general social-media management tool, not a business/creator account manager, and not a hacking-prevention or account-security-hardening suite.

2. System Overview

The product is a first-party web application with application-owned identity. It delivers a self-service recovery lifecycle for an individual whose Instagram account was hacked:

1. An anonymous visitor lands on a public entry surface that explains, plainly, that the product helps individuals recover hacked or locked Instagram accounts.
2. The seeker establishes their own identity (self-service enrollment) or verifies it on return, then submits a focused recovery request naming the affected Instagram account and describing the situation.
3. The seeker can independently revisit their submitted requests to track status and see the outcome.
4. A reviewer works a reviewer-side destination to view submitted recovery requests and update their status or outcome.
5. The seeker sees the updated status and outcome on their own tracking surface.

Actors.

Ownership. All six destinations are application-owned custom pages. Identity is application-owned and is required for continuity of durable, actor-specific recovery state: a seeker must privately own and resume their own recovery requests, and a reviewer must access the reviewer case queue. The Landing, Sign Up, and Login surfaces are anonymously reachable; the Submit Recovery Request, My Recovery Requests, and Recovery Cases surfaces require an established identity.

Narrow exclusions. No account-security-hardening, password-management, two-factor, or hacking-prevention capability is in current scope. No business or creator account management. No provider-owned Instagram login or credential handling is part of this product's accepted behavior.

2a. Product Interpretation and Delivery Boundary

Delivery. The product is delivered as a first-party web application with its own backend for durable recovery-request state. The seeker's and reviewer's work happens entirely inside this product's own pages; the product does not hand the user off to an external recovery console, and it does not perform the Instagram-side account restoration itself. What the product owns is the recovery request lifecycle: capturing the hack report, holding its status, letting the seeker track it, and letting the reviewer triage and update it.

Access ownership. Identity is application-owned. A seeker establishes identity on first use through self-service enrollment and verifies it on return; a reviewer verifies identity on return to reach the reviewer case queue. The Landing, Sign Up, and Login surfaces are reachable without an established identity. The three working surfaces — Submit Recovery Request, My Recovery Requests, and Recovery Cases — require an established identity, because each holds durable, actor-specific state that must remain bound to the correct participant: a seeker's own requests must not be visible to another seeker, and the reviewer queue must not be reachable by a seeker.

Current vs. future. Everything described in this document is current. No future-horizon capabilities are accepted in the authoritative requirement thread; the only forward-looking material in the source is the general framing of "account security and hacking prevention," which is not an accepted current capability and is therefore not built here.

2c. Page Content and Component Coverage

Landing

• Information/state. Anonymous public entry. States the product's purpose in plain language: this product helps an individual recover a hacked or locked Instagram account. Names the concrete situation (an account was taken) without exposing any private recovery data.
• Primary action. A single most-urgent call to action that begins the recovery path (leading to identity establishment and then the recovery request). Exactly one accent-marked key on this view.
• Supporting actions. A secondary path for someone who already has an identity to verify it and continue.
• Domain entities. None persisted; purely explanatory.
• Component responsibilities. Hero statement; a single accent CTA key; a secondary "I already have an account" path; a numbered, icon-led step system (1 Report, 2 Verify, 3 Recover) that anchors the promise; a pixel pictogram as the hero's only illustration.
• States. Loading: static content, no data fetch. Empty: not applicable. Success: visitor proceeds to Sign Up or Login. Error: not applicable. Recovery: if a visitor arrives with an expired session, they are returned here and can re-enter through Login.

Sign Up

• Information/state. Anonymous first-use enrollment for an individual who independently begins a recovery request. Collects only what is needed to establish an application-owned identity for continuity.
• Primary action. Create the identity and continue into the recovery request.
• Supporting actions. Move to Login if the person already has an identity.
• Domain entities. Account identity (the seeker's own).
• Component responsibilities. Enrollment form; inline validation messaging; the single accent key for the primary action; a link to Login.
• States. Loading: submit in progress, control disabled. Empty: blank form. Success: identity established, seeker continues to Submit Recovery Request. Error: invalid or incomplete input is shown inline with a plain-language explanation and the form is preserved. Recovery: a failed submission keeps entered values so the seeker does not retype them.

Login

• Information/state. Anonymous returning verification. Serves both the seeker (to reach their own recovery requests) and the reviewer (to reach the reviewer case queue). The destination after verification depends on which accepted role the verified identity belongs to.
• Primary action. Verify identity and continue to the correct working surface.
• Supporting actions. Move to Sign Up if the person has no identity yet.
• Domain entities. Account identity.
• Component responsibilities. Verification form; inline error messaging; the single accent key for the primary action; a link to Sign Up.
• States. Loading: verification in progress, control disabled. Empty: blank form. Success: seeker continues to My Recovery Requests; reviewer continues to Recovery Cases. Error: unrecognized or incorrect credentials are shown inline in plain language without revealing which part failed. Recovery: the form is preserved after a failed attempt so the person can correct and retry.

Submit Recovery Request

• Information/state. Identity-required, seeker-only working surface. Focused owner where the hacked-account owner identifies the affected Instagram account and describes the situation. Shows the recovery progress strip so the seeker can see where they are in the numbered flow.
• Primary action. Submit the recovery request.
• Supporting actions. Review and correct entered details before submitting; return to the seeker's request list after submission.
• Domain entities. Recovery request (affected Instagram account handle, situation description, submission timestamp, status).
• Component responsibilities. Affected-account field (the handle, e.g. deep_sardarni712); situation description field; the numbered step system (1 Report, 2 Verify, 3 Recover) with the current step marked; the persistent progress strip of 8px squares; the single accent key for submission; a confirmation state after submission.
• States. Loading: submit in progress, control disabled. Empty: blank form with the affected-account field ready. Success: the request is created and the seeker sees a confirmation with the request's initial status, then continues to My Recovery Requests. Error: missing or invalid input is shown inline with a plain-language explanation and the entered content is preserved. Recovery: a failed submission does not lose the seeker's description; they can correct and resubmit.

My Recovery Requests

• Information/state. Identity-required, seeker-only, independently revisitable owner where the seeker tracks submitted recovery request status and sees the outcome. Shows only the seeker's own requests.
• Primary action. Open a request to see its current status and outcome detail.
• Supporting actions. Start another recovery request; return to a request after leaving.
• Domain entities. Recovery request (handle, description, submission timestamp, status, outcome).
• Component responsibilities. A list of the seeker's own requests, each row carrying a pixel status square plus a word (never colour alone) and the affected handle in tabular type; a status detail view; the single accent key for the most urgent action on the view (for example, an action-needed item); the progress strip reflecting the seeker's flow position.
• States. Loading: request list is being fetched. Empty: no requests yet, with a clear path to start one. Success: requests and their current statuses are listed; a recovered request shows its outcome. Error: the list fails to load, with a plain-language message and a retry. Recovery: retry reloads the list without losing the seeker's place.

Recovery Cases

• Information/state. Identity-required, reviewer-only working destination. Shows submitted recovery requests as a ruled table of case rows, each with a pixel status square, the account handle in tabular type, and a single update key.
• Primary action. Update a case's status or outcome.
• Supporting actions. Open a case to read the seeker's description and verify the claim; move between cases.
• Domain entities. Recovery case (affected handle, seeker's description, submission timestamp, status, outcome, reviewer update).
• Component responsibilities. Ruled case table; per-row pixel status square plus word; per-row update key; case detail with the seeker's description; status/outcome update control; the single accent key for the most urgent action on the view.
• States. Loading: case list is being fetched. Empty: no cases submitted yet. Success: cases are listed and an update is reflected immediately in the row's status square and word. Error: the list or an update fails, with a plain-language message and a retry that preserves the reviewer's in-progress update. Recovery: a failed update can be retried without re-entering the outcome.

3. Functional Requirements

Each requirement is a distinct story point with provenance, lifecycle facts, and observable acceptance.

FR-1 — Anonymous product explanation (explicit) As an Account Recovery Seeker, I should see, before establishing any identity, a plain explanation that this product helps an individual recover a hacked or locked Instagram account, so that I understand what the product does and that my situation is solvable.

• Trigger/input: visiting the Landing surface with no established identity.
• Observable result: the Landing surface presents the product's purpose and a single most-urgent call to action to begin recovery.
• Access state: anonymous; no identity required.
• Failure/recovery: not applicable (static content).
• Continuation: the seeker proceeds to Sign Up, or to Login if they already have an identity.

FR-2 — Self-service first-use enrollment (required_inference) As an Account Recovery Seeker, I should be able to establish my own identity on first use, so that my recovery request and its outcome remain privately bound to me and I can return to them.

• Trigger/input: choosing to begin recovery from the Landing surface without an existing identity.
• Observable result: an application-owned identity is created for the seeker and they continue into the recovery request.
• Access state: anonymous entry; the enrollment interaction itself is reachable without an established identity.
• Failure/recovery: invalid or incomplete input is shown inline in plain language and the entered values are preserved for correction.
• Continuation: the seeker continues to Submit Recovery Request.

FR-3 — Returning verification for the seeker (required_inference) As an Account Recovery Seeker, I should be able to verify my identity on return, so that I can reach my own recovery requests and see their outcome.

• Trigger/input: returning to the product and choosing to verify identity.
• Observable result: the seeker reaches My Recovery Requests and sees only their own requests.
• Access state: anonymous entry to the verification interaction; protected state remains unavailable until identity is established.
• Failure/recovery: an unrecognized or incorrect credential is reported inline in plain language without revealing which part failed, and the form is preserved for retry.
• Continuation: the seeker lands on My Recovery Requests.

FR-4 — Returning verification for the reviewer (required_inference) As a Recovery Case Reviewer, I should be able to verify my identity on return, so that I can access and update submitted recovery cases.

• Trigger/input: returning to the product and choosing to verify identity.
• Observable result: the reviewer reaches Recovery Cases and sees the submitted case queue.
• Access state: anonymous entry to the verification interaction; the reviewer case queue remains unavailable until identity is established.
• Failure/recovery: an unrecognized or incorrect credential is reported inline in plain language without revealing which part failed, and the form is preserved for retry.
• Continuation: the reviewer lands on Recovery Cases.

FR-5 — Submit a recovery request (explicit) As an Account Recovery Seeker, I should be able to identify the affected Instagram account and describe the situation, so that my hacked-account recovery request is recorded and can be worked.

• Trigger/input: the seeker, with an established identity, opens Submit Recovery Request and enters the affected Instagram account handle (deep_sardarni712 in the immediate case) and a description of the situation.
• Observable result: a recovery request is created with the affected handle, the description, a submission timestamp, and an initial status; the seeker sees a confirmation.
• Access state: identity required; seeker-only.
• Failure/recovery: missing or invalid input is shown inline in plain language and the seeker's entered description is preserved so they can correct and resubmit.
• Continuation: the seeker continues to My Recovery Requests, where the new request appears.

FR-6 — Track submitted requests and see the outcome (explicit) As an Account Recovery Seeker, I should be able to revisit my submitted recovery requests and see their current status and outcome, so that I know where my recovery stands.

• Trigger/input: the seeker, with an established identity, opens My Recovery Requests.
• Observable result: the seeker's own requests are listed, each with a status shown as a pixel status square plus a word, and any outcome is visible on the request.
• Access state: identity required; seeker-only; only the seeker's own requests are shown.
• Failure/recovery: if the list fails to load, a plain-language message and a retry are offered, and retry reloads without losing the seeker's place.
• Continuation: the seeker can open a request for detail, or start another recovery request.

FR-7 — Review submitted recovery cases (required_inference) As a Recovery Case Reviewer, I should be able to view submitted recovery requests as cases, so that I can triage incoming hacked-account recovery work.

• Trigger/input: the reviewer, with an established identity, opens Recovery Cases.
• Observable result: submitted cases are listed as ruled rows, each with a pixel status square, the account handle in tabular type, and a single update key; opening a case shows the seeker's description for verification of the claim.
• Access state: identity required; reviewer-only.
• Failure/recovery: if the case list fails to load, a plain-language message and a retry are offered.
• Continuation: the reviewer opens a case to read it and decide on its status.

FR-8 — Update a case's status or outcome (required_inference) As a Recovery Case Reviewer, I should be able to update a submitted case's status or outcome, so that the seeker's recovery path is guided or approved and the seeker can see the result.

• Trigger/input: the reviewer opens a case and sets its status or outcome.
• Observable result: the case's status or outcome is updated and reflected immediately in the case row's status square and word.
• Access state: identity required; reviewer-only.
• Failure/recovery: a failed update shows a plain-language message and can be retried without re-entering the outcome.
• Continuation: the reviewer moves to the next case; the seeker sees the updated status on My Recovery Requests.

FR-9 — See the reviewer's update as the seeker (required_inference) As an Account Recovery Seeker, I should see the status or outcome the reviewer set on my request, so that I know whether my recovery is in review, needs action from me, or has been recovered.

• Trigger/input: the seeker opens My Recovery Requests after the reviewer has updated the case.
• Observable result: the request shows the reviewer-set status as a pixel status square plus a word (for example, in review, action needed, or recovered), and any outcome detail is visible.
• Access state: identity required; seeker-only; only the seeker's own requests are shown.
• Failure/recovery: if the status cannot be loaded, a plain-language message and a retry are offered.
• Continuation: the seeker acts on an action-needed status, or considers the request complete when it reads recovered.

4. User Personas

Account Recovery Seeker

Product context. An individual whose Instagram account — deep_sardarni712 in the immediate case — has been hacked and who has lost access to it. This is a personal account, not a business or creator account, and the person is not a professional account manager. They arrive in a state of fear, urgency, and loss of control: something they own has been taken, and the process to get it back is normally opaque.

Primary goal. Regain access to the compromised Instagram account.

Distinct accepted responsibilities. The seeker is the only actor who can describe their own situation: they identify the affected Instagram account handle and describe what happened, creating the recovery request. They are also the only actor who tracks their own request and receives its outcome. Their work is reporting and following — they initiate the case and then wait on and respond to the reviewer's decision.

Relevant inputs or decisions. The affected Instagram account handle (deep_sardarni712); a description of the situation; the decision to submit the request; the decision to return and check status; and, when a status reads action needed, the decision to act on it.

Interactions with other accepted participants. The seeker hands their case to the Recovery Case Reviewer by submitting the request. The reviewer verifies the claim and sets the status or outcome, which the seeker then sees on their own tracking surface. The seeker never sees the reviewer's queue, and the reviewer never sees another seeker's requests.

Observable success. The seeker's request exists with the correct affected handle and description; the seeker can return at any time and see its current status; and the request eventually reads recovered with the outcome visible.

What makes this role different. The seeker is the subject of the loss and the source of the claim — their work is emotional, one-off, and personal, and their only lever is an accurate, honest description of what happened. They do not triage, verify, or decide anything about anyone else's case.

Recovery Case Reviewer

Product context. A support-side human who works a queue of submitted hacked-account recovery requests. Their context is a ruled list of cases rather than a single personal situation; they see many claims and must judge each one.

Primary goal. Verify submitted claims and guide or approve the recovery path so the seeker regains access.

Distinct accepted responsibilities. The reviewer is the only actor who reads submitted cases as a queue, opens a case to read the seeker's description and verify the claim, and sets or updates the case's status or outcome. Their recurring work is triaging incoming recovery cases and communicating status back to the seeker through the case's status.

Relevant inputs or decisions. The submitted case's affected handle and the seeker's description; the decision of whether the claim is verified; and the decision of what status or outcome to set (for example, in review, action needed, or recovered).

Interactions with other accepted participants. The reviewer receives cases created by Account Recovery Seekers and returns a decision to them by updating the case status, which the seeker sees on their own tracking surface. The reviewer does not create recovery requests and does not see the seeker's private tracking view as the seeker sees it.

Observable success. Cases are listed and readable; the reviewer can open a case, verify the claim from the seeker's description, and set a status or outcome that is immediately reflected in the case row and visible to the seeker.

What makes this role different. The reviewer's work is comparative and repetitive rather than personal: they judge many claims against each other, hold the authority to change a case's state, and are the only actor whose action moves a case forward. They are not the person who lost the account, and they do not experience the outcome as a personal recovery.

5. Core User Flows

Flow A — Account Recovery Seeker reports a hacked account and tracks it to outcome

1. Starting context. Deepika has lost access to her Instagram account, deep_sardarni712, and has been hacked. She has no identity in this product yet.
2. Landing. She arrives at Landing anonymously. She reads the plain statement that this product helps an individual recover a hacked or locked Instagram account, and sees the numbered promise: 1 Report, 2 Verify, 3 Recover.
3. Begin. She presses the single accent key to start her recovery.
4. Enrollment. Because she has no identity, she lands on Sign Up and establishes her own identity. If she mistypes, the form explains the problem inline and keeps what she entered so she can correct it.
5. Report. She lands on Submit Recovery Request. She enters the affected Instagram account handle, deep_sardarni712, and describes the situation — what happened and that the account was hacked. The progress strip shows her at step 1, Report.
6. Submit. She presses the single accent key to submit. A recovery request is created with her handle, her description, a submission timestamp, and an initial status. She sees a confirmation.
7. Track. She continues to My Recovery Requests, where her new request appears with its status shown as a pixel status square plus a word. She can leave and come back at any time.
8. Handoff to the reviewer. Her submitted request becomes a case in the reviewer's queue. She does not see the queue; she waits on the outcome.
9. Return and verify. Later she returns and verifies her identity on Login. She lands back on My Recovery Requests and sees only her own requests.

10. See the outcome. The request now shows the status the reviewer set. If it reads action needed, she acts on it and resubmits or responds as directed. If it reads in review, she waits. When it reads recovered, the outcome is visible on the request and her goal is met.
11. Failure and recovery. If her request list fails to load, she sees a plain-language message and a retry; retrying reloads the list without losing her place. If her submission failed earlier, her description was preserved and she could correct and resubmit.
12. Continuation. She can open the request for detail, or start another recovery request if needed.

Flow B — Recovery Case Reviewer triages and updates a case

1. Starting context. A recovery request has been submitted by an Account Recovery Seeker and is waiting in the queue. The reviewer has an identity in this product.
2. Verify. The reviewer opens Login and verifies their identity. They land on Recovery Cases.
3. Read the queue. They see submitted cases as ruled rows, each with a pixel status square, the affected account handle in tabular type, and a single update key.
4. Open a case. They open the case for deep_sardarni712 and read the seeker's description to verify the claim.
5. Decide. They judge whether the claim is verified and decide what status or outcome to set — for example, in review while they work it, action needed if the seeker must supply or do something, or recovered when the recovery path is approved and complete.
6. Update. They set the status or outcome. The case row's status square and word update immediately.
7. Handoff back to the seeker. The updated status becomes visible to the seeker on My Recovery Requests; the reviewer does not need to contact the seeker outside the product for the status to be seen.
8. Failure and recovery. If the case list fails to load, they see a plain-language message and a retry. If an update fails, they see a plain-language message and can retry without re-entering the outcome.
9. Continuation. They move to the next case in the queue and repeat.

Flow C — Account Recovery Seeker acts on an action-needed status

1. Starting context. The seeker has an existing request that the reviewer has set to action needed.
2. Return. The seeker verifies their identity on Login and lands on My Recovery Requests.
3. Notice. The request shows a coral pixel status square plus the word action needed — status is never colour alone.
4. Act. The seeker opens the request, reads what is needed, and supplies or corrects the requested information.
5. Result. The request returns to the reviewer's queue with the seeker's response, and the seeker's view reflects the updated state.
6. Continuation. The seeker waits for the reviewer's next update, or sees recovered when the recovery path completes.

6. Visuals, Colors, and Theme

Muse and headline. The visual language follows Susan Kare: small, legible symbols with personality, tidy grids you can feel, and monochrome-plus-crisp-accent on light grounds. The register is charming clarity for a hacked account — pixel-perfect reassurance. The interface must feel calm, legible, human, and unfailingly clear: warm enough to reassure someone in distress, structured enough to feel competent, and never corporate, sterile, or cold-technical.

Color tokens (light mode).

The accent is used on no more than one element per view. The supporting status palette appears only as 8px status squares and never as large fills, so the page stays warm and quiet while status reads instantly. Status is always an icon plus a word, never colour alone.

Typography.

• Headings: VT323, weight 400 only, sentence case, tracking normal. Hierarchy comes purely from size jumps. Used for the single hero statement and section openers.
• Body and functional text: Space Grotesk at 400/500/600, with slightly loosened tracking for calm readability. All functional labels, statuses, buttons, and body copy.
• Micro-labels: uppercase, letterspaced 0.12em, in Space Grotesk, naming each recovery step.
• Scale: 1.5 modular on a 4/8-pt grid. Hero clamp(2.5rem, 7vw, 6rem) (40px mobile → 96px desktop); section openers 28 → 44; step titles 22 → 28; body 16 → 18 with line-height 1.6; micro-labels 12; numerals tabular.

Shape language. Chunky pixel-adjacent geometry: 2px ink borders on white tiles with a hard 4px offset shadow instead of soft blur; 6px radii (crisp, not pillowy); 8px status squares; a 24px pixel-grid motif as a decorative corner rule. Buttons are rectangular with a 4px pressed-in bottom edge so they read as physical keys. Iconography is drawn on a visible 16×16 pixel grid — a key, a shield, a padlock, a paper plane, a checkmark — each with one pixel of personality.

Layout. Tidy centered single column capped at 720px for reading and forms, with a wider 1120px grid for the landing hero and the reviewer case list. Recovery is laid out as a numbered, icon-led step system (1 Report, 2 Verify, 3 Recover), each step a white tile with a pixel icon, a rule between steps, and a persistent slim progress strip of 8px squares at the top of the flow that fill as the seeker advances. The reviewer case list is a ruled table of rows, each row a case with a pixel status square, account handle in tabular type, and a single update key.

Imagery. No photography and no stock people. The visual language is pixel pictograms and simple symbols drawn on a 16×16 grid — a padlock with a broken shackle, a shield, a key, an envelope, a phone, a checkmark — used at 48–96px as the hero's only illustration, plus a small pixel-grid pattern used as a decorative rule or corner motif. Everything is reduced to symbols.

Avoid. Blue–indigo primary or accent on white, or any bootstrap-blue button; soft blurred drop shadows, glassmorphism, or frosted panels; gradient-blob heroes or abstract gradient backgrounds; Inter, Roboto, Arial, Helvetica, Open Sans, Lato, or Poppins for headings or body; photography of people, stock imagery, or 3D renders; status conveyed by colour alone without an icon and a word; identical hover-lift card grids; playful bounce or springy easing that undercuts the reassurance. The generic indigo/blue-on-white SaaS template is forbidden for this project.

Readable text and controls. Headlines, wordmarks, labels, numbers, card text, and controls stay entirely inside the viewport and their container at 375px, 768px, and 1280px, wrapping or scaling (for example font-size: clamp(...) with its mobile size) to fit, and no other element covers any part of them. Imagery, decoration, and motion may be cropped, bled off an edge, rotated, overlapped, or cut exactly as the direction asks, as long as they cover no readable text or control.

7. Signature Design Concept

The first screen is a promise, not a form.

The public entry — Landing — is a warm paper-white (#F4F1E8) full-bleed first screen with no gradient and no photograph. On the left, occupying roughly seven of twelve columns, a huge VT323 statement — "Your account was taken. Let's get it back." — is set at clamp(2.5rem, 7vw, 6rem) in ink black (#1B1B1D), stacked over a solid ink-black block that holds the single coral CTA key "Start my recovery". Above the headline, a small uppercase micro-label reads HACKED ACCOUNT RECOVERY with a coral 8px square.

On the right, a large 96px pixel padlock-with-broken-shackle glyph sits on a white tile with a hard 4px offset shadow, tilted 2 degrees, with a decorative pixel-grid rule running off the right edge. Below the fold edge, a horizontal strip of three numbered step tiles — Report → Verify → Recover — anchors the promise.

Nothing is centred, no blue, no blob. The composition recomposes only accepted content and controls: the product's purpose, the single most-urgent action, the numbered recovery promise, and a pixel pictogram. It introduces no new behavior, page, or destination.

8. Interaction Model & Motion Direction

Interaction Model: Static Motion Tempo: restrained Hero Dimensionality: flat

Landing Hero Motion Brief.

• Focal subject. The 96px pixel padlock-with-broken-shackle glyph on its hard-shadow white tile, paired with the oversized VT323 statement and the single coral CTA key.
• Input → transformation → outcome thesis. On entry, the pixel pictogram blinks once — a single discrete frame change, not a fade — and the coral CTA key sits as a physical key with a 4px hard offset shadow. When the visitor presses the key, it depresses 2px and the visitor moves into the recovery flow. The transformation is fear → a graspable, numbered process: the broken padlock is shown as a known, solvable object rather than an opaque security event.
• Motion vocabulary. Frame-by-frame micro animation only: pixel icons blink once on entry; the progress squares fill in discrete steps rather than smoothly; buttons depress 2px on press; a checkmark stamps in on submit. No easing theatrics, no floats, no parallax. Transitions are 120ms and functional.
• Composed first frame. Warm paper-white ground; micro-label with coral 8px square; huge ink-black VT323 statement; solid ink-black block holding the single coral CTA key; the tilted 96px pixel padlock on a white tile with a hard 4px offset shadow; a pixel-grid rule running off the right edge; the three numbered step tiles below the fold edge.
• Reduced-motion state. With prefers-reduced-motion, every animation resolves instantly to its final state: the pictogram is shown fully drawn, the progress squares are shown filled to the current step, and the CTA key is shown in its resting position. All content and controls remain fully readable and usable.

9. Non-Functional Requirements

• NFR-1 — Durable recovery state (required_inference). Recovery requests, their statuses, and their outcomes must persist durably so that a seeker can leave and return to see the current state, and so that a reviewer's update is not lost. Rationale: the accepted seeker journey requires independently revisitable tracking and an outcome that survives between visits.
• NFR-2 — Actor-bound state isolation (required_inference). A seeker's recovery requests must be visible only to that seeker, and the reviewer case queue must be reachable only by a reviewer. Rationale: the accepted lifecycle binds a personal loss and its outcome to the correct participant; a seeker must not see another seeker's requests.
• NFR-3 — Anonymous reachability of entry surfaces (explicit). Landing, Sign Up, and Login must be reachable without an established identity. Rationale: the accepted first-use journey begins anonymously and the enrollment interaction cannot require the identity it establishes.
• NFR-4 — Plain-language error and recovery messaging (required_inference). Material failures (failed submission, failed list load, failed update, failed verification) must be reported in plain language and must preserve the user's entered content so they can correct and retry. Rationale: the audience is an anxious individual in distress; losing entered content would compound the harm the product exists to reduce.
• NFR-5 — Status never conveyed by colour alone (explicit). Every status must be shown as a pixel status square plus a word, with a 16×16 pixel icon. Rationale: explicit creative-direction requirement; also an accessibility constraint.
• NFR-6 — Readable text and controls at all target viewports (explicit). Headlines, labels, numbers, card text, and controls must remain entirely inside the viewport and their container at 375px, 768px, and 1280px. Rationale: explicit creative-direction requirement.

• NFR-7 — Reduced-motion support (explicit). With prefers-reduced-motion, every animation must resolve instantly to its final state while all content and controls remain usable. Rationale: explicit creative-direction requirement.
• NFR-8 — Single accent per view (explicit). The coral accent #E8552F may appear on no more than one element per view. Rationale: explicit creative-direction requirement; it keeps the single most urgent action unmistakable.

10. Tech Stack

• Frontend: React (web), single-page application with the six accepted pages as routes.
• Backend: Python with FastAPI, providing the recovery-request API, identity establishment and verification, and case status updates.
• Storage: a relational database for durable recovery requests, statuses, outcomes, and account identities.
• Packaging and local run: Docker with docker-compose.yml running the frontend and the backend as the runnable services.
• Deployment: Kubernetes only if deployment requires it; not otherwise.

No source-specified technology was overridden; the stack above is the practical minimum for the accepted durable-state and identity-continuity requirements.

11. Assumptions and Constraints

Constraints (explicit, binding).

• Scope is limited to Instagram account recovery for hacked or locked accounts; the user's own account is deep_sardarni712.
• The user is an individual whose account was hacked, not a business or creator account manager.
• The generic indigo/blue-on-white SaaS template is forbidden for this project.
• The palette, fonts, surfaces, tone, layout, and product context specified in the creative direction are preserved as given.

Assumptions (narrow, labeled).

• Assumption — identity is application-owned. Application-owned identity is assumed because the accepted seeker journey requires privately owned, resumable, actor-specific recovery state, and the accepted reviewer journey requires a reviewer-only case queue. This is labeled required_inference and is limited to first-use enrollment and returning verification; no adjacent account-management capability (password reset flows, profile editing, social login, role administration) is included.
• Assumption — the reviewer is a distinct accepted human role. The Recovery Case Reviewer is carried from the accepted persona catalog; the product does not define how reviewers are provisioned, because the source does not.
• Assumption — the product does not perform Instagram-side restoration. The product owns the recovery request lifecycle; the actual restoration of the Instagram account is outside this product's accepted behavior and is not modeled.
• Assumption — no hacking-prevention capability is in scope. The orientation note about "account security and hacking prevention" is not an accepted current capability in the authoritative requirement thread; it is therefore not built, and no prevention, hardening, or monitoring feature is added.

Presentation defaults.

• [Default — not specified by user] Exact spacing values beyond the stated 4/8-pt grid, exact breakpoint pixel values beyond the three named target widths, and exact database engine choice are filled by implementation convention and do not change product behavior.

12. Glossary

• Account Recovery Seeker — the accepted human persona whose Instagram account has been hacked or locked and who reports the hack, tracks the request, and receives the outcome.
• Recovery Case Reviewer — the accepted human persona who reviews submitted recovery requests, verifies claims, and updates case status or outcome.
• Recovery request — the durable record a seeker creates, holding the affected Instagram account handle, the seeker's description of the situation, a submission timestamp, a status, and an outcome.
• Recovery case — the reviewer-side view of a submitted recovery request, worked from the Recovery Cases queue.
• Affected Instagram account — the hacked or locked Instagram account named in a recovery request; deep_sardarni712 in the immediate case.
• Status — the current state of a recovery request or case, always shown as a pixel status square plus a word (for example, in review, action needed, recovered).
• Outcome — the result recorded on a recovery request when the reviewer's recovery path completes.
• Progress strip — the persistent slim strip of 8px squares at the top of the recovery flow that fills discretely, one square per completed step.
• Step system — the numbered, icon-led recovery flow: 1 Report, 2 Verify, 3 Recover.
• Pixel status square — the 8px coloured square that accompanies a status word; never used alone.