System Requirements Document for dakrai

1. Introduction

dakrai is an Arabic-first interactive AI-skills academy. It is not a course marketplace and not a video library: it is a place where a learner enters the machine from inside the machine. The product delivers interactive learning experiences built on courses, where every course is constructed from skills, every skill is explained word by word, and every prompt is taught as a craft — how to read it, how to use it, and how to write it correctly with AI.

The product intent, derived from the authoritative requirement thread, is:

• Build a website that delivers interactive experiences through courses.
• Build the courses and prepare the project, producing strong interactive teaching and explanations that the learner actually trains on.
• Ground the courses in skills, with an explanation of every word, of prompts, of how to use a prompt, and of how to write a prompt correctly with AI.
• Provide powerful interactive interfaces (واجهات تفاعلية قوية).
• After a user subscribes, give them an access link; when they activate it, they become able to learn the course interactively.
• Include detailed tasks and precise explanations that make understanding easy, with deep logic.
• Explain in Arabic; write in English.
• Explain the most important skills and how to use them.
• Make the explanation itself built with design.

Audience. Gulf and MENA learners who want to feel they are entering a serious, futuristic technical institution. They read Arabic explanation prose and work with English technical terms, prompts, and code. They are joined by the people who author that curriculum and the person who controls who gets in.

2. System Overview

dakrai is a first-party web application with application-owned identity. It has three accepted human actors: the subscribed learner, the course and educational-content creator, and the access administrator who manages subscriptions and activation. A public, unauthenticated surface explains the academy and its courses; a learner can browse courses before subscribing; enrollment and access activation gate the protected learning surfaces; and the creator and administrator work behind returning verification.

The current delivery is a custom first-party UI with a backend. The learning experience is bilingual by construction: Arabic explanation prose paired with English technical writing, prompts, and code, presented on a shared baseline grid so the two halves of every lesson are read together rather than sequentially.

Narrow exclusions. This document does not add adjacent capabilities that the source did not accept: no social feed, no discussion forum, no certificate issuance, no payment-gateway specification, no mobile application, no third-party course marketplace, and no account-management surface beyond establishing and verifying identity. Where the source is silent, this document stays silent or labels a coherent default.

2a. Product Interpretation and Delivery Boundary

What dakrai owns. dakrai owns the public entry surface, the course catalogue, the enrollment step, the access-activation step, the protected lesson and practice surfaces, the course-building surfaces, and the access-administration surface. It also owns the identity that binds a learner's progress, a creator's authored content, and an administrator's issued access links to the correct person. Identity is application-owned because a subscription, an issued access link, and a learner's durable progress must remain bound to the correct participant across visits.

How access works. The public entry and the course catalogue are reachable without identity. Enrollment is the point at which a learner commits to a course; the access link is issued after that commitment and must be activated before the protected learning surfaces open. The creator and administrator surfaces are reached through returning verification. The interaction that establishes identity is anonymous by design — a person cannot be required to already be inside the thing they are trying to enter.

Current versus future. Everything described in this document is current. No future-horizon requirements were accepted in the authoritative thread; section 11 records the boundaries this document deliberately did not cross.

Delivery shape. Custom first-party UI, backend-integrated, bilingual Arabic/English, with a real-time generative visual system as the product's own subject matter rendered as its interface.

2c. Page Content and Component Coverage

The page inventory below is the accepted final page contract. Each page appears exactly once.

Landing

• Information and state. The public entry surface. Presents the academy's identity, its promise of interactive AI-skills learning, and the shape of what a course contains. No identity required. No protected state is visible here.
• Primary actions. Enter the course catalogue; begin the path toward enrollment.
• Supporting actions. Read the academy's explanation of what a course is made of (skills, word-by-word explanation, prompts, detailed tasks); read the explanation of how prompts are used and written correctly with AI.
• Domain entities. Academy identity, course summary, skill category summary, enrolled-learner count.
• Component responsibilities. Full-bleed generative field as the hero backdrop, driven by curriculum data; oversized Arabic headline with an English uppercase kicker; a single wide primary call to action with a live enrolled-learner counter in tabular numerals; numbered section rules carrying mono index labels; course and skill summary blocks occupying the asymmetric text columns.
• States. Loading: the generative field initializes while the headline and call to action render immediately. Empty: not applicable — the entry surface always has content. Success: the visitor understands the academy and moves to the catalogue. Error: if the generative field fails to initialize, the page renders on the flat ink ground with all text and controls intact. Recovery: the field retries on next visit; no content is ever gated behind it.

Courses

• Information and state. The catalogue of available courses. Each course shows its title, its skill categories, its lesson count, and a summary of what the learner will be able to do. Reachable without identity.
• Primary actions. Open a course's detail view; proceed toward enrollment for a chosen course.
• Supporting actions. Filter or scan by skill category; compare lesson counts.
• Domain entities. Course, skill category, lesson, lesson count, course summary.
• Component responsibilities. Course cards as flat panels with hairline borders and a top-edge data line that lights when active; per-course generative sculpture whose parameters derive from that course's curriculum data; tabular numerals for lesson counts; the numbered section rule separating catalogue sections.
• States. Loading: card skeletons on the ink ground with hairline borders. Empty: a clear statement that no courses are published yet, with no fabricated courses. Success: the learner finds a course and opens it. Error: a retry affordance with the catalogue's last known content preserved. Recovery: retry reloads the catalogue without losing the learner's position.

Enrollment

• Information and state. The commitment step for a chosen course. Shows the course being enrolled in, what the subscription grants, and the fact that an access link will follow. Requires an established identity.
• Primary actions. Complete the subscription for the chosen course.
• Supporting actions. Return to the course detail; review what the subscription includes.
• Domain entities. Enrollment, subscription, learner, course, access-link issuance.
• Component responsibilities. Course summary panel; subscription confirmation control as a wide rectangle with an ember underline; explicit statement that access is granted by an activated link; state indicator showing enrollment pending, confirmed, or failed.
• States. Loading: the enrollment summary loads against the selected course. Empty: if no course is selected, the learner is directed back to the catalogue rather than shown a blank form. Success: enrollment is confirmed and the learner is told an access link will be issued. Error: a failed enrollment states the failure plainly and preserves the learner's course selection. Recovery: the learner can retry enrollment without re-selecting the course.

Access Activation

• Information and state. The surface where an issued access link is activated. Shows the link's status — issued, activated, expired, or invalid — and, once activated, confirms that the course is open. Reachable by the learner holding the link and by the access administrator.
• Primary actions. Activate the access link.
• Supporting actions. For the administrator: inspect the link's state and reissue or correct it when activation fails.
• Domain entities. Access link, activation state, learner, course, subscription.
• Component responsibilities. Link-state panel; activation control; clear success confirmation naming the course that is now open; failure panel that distinguishes an expired link from an invalid one; administrator-side reissue control.
• States. Loading: the link's state is resolved. Empty: no link supplied — the surface explains that activation requires the link issued after subscription. Success: the link is activated and the learner is told the course is open, with a direct continuation into the lessons. Error: expired or invalid links are named as such, with the recovery path stated. Recovery: the learner can request a corrected link; the administrator can reissue it from the access-management surface.

Lessons

• Information and state. The protected interactive lesson surface. Presents each lesson's Arabic explanation alongside its English technical writing, prompts, and code on a shared baseline grid. Shows the learner's position in the course and which lessons are complete.
• Primary actions. Move through lessons; mark a lesson complete; open the practice tasks for a lesson.
• Supporting actions. Hover any English technical term in the Arabic explanation to raise an in-place lexicon panel with the word, its transliteration, and a one-line Arabic definition; hover a token in a prompt to highlight the exact token being explained.
• Domain entities. Course, lesson, skill, prompt, prompt token, lexicon entry, completion state, progress.
• Component responsibilities. Mirrored prompt-and-explanation split with the English prompt or code panel on one side and the Arabic deep-logic explanation on the other, sharing one baseline grid; per-word lexicon interaction; token-highlight link between prompt and explanation; circular progress arc; completion control; the numbered section rule marking lesson boundaries.
• States. Loading: the lesson's explanation and prompt panels load together so the baseline grid never renders half-empty. Empty: a course with no published lessons states that plainly rather than showing an empty reader. Success: the lesson is read and marked complete, and the learner's progress advances. Error: if a lesson fails to load, the learner's position is preserved and a retry is offered. Recovery: retry restores the lesson at the same position; completion state is never lost by a load failure.

Practice

• Information and state. The protected practice surface where the learner executes the detailed tasks attached to a lesson. Presents the task, its requirements, and the learner's submitted work or response.
• Primary actions. Work through a detailed task; submit the task's result; mark the task done.
• Supporting actions. Re-read the linked lesson explanation without leaving practice; consult the lexicon for a term encountered in the task.
• Domain entities. Task, task requirement, submission, learner, lesson, skill, completion state.
• Component responsibilities. Task statement panel; requirement checklist; the learner's working area for the task; submission control; completion control; the same lexicon primitive available inside task text.
• States. Loading: the task and its requirements load together. Empty: a lesson with no tasks states that plainly. Success: the task is submitted and marked done, and the learner's progress advances. Error: a failed submission preserves the learner's work and states the failure. Recovery: the learner can resubmit without retyping; the work is retained across the failure.

Course Builder

• Information and state. The creator's surface for building a course and preparing it for publication. Shows the course's structure — its lessons, their order, and its publication state.
• Primary actions. Create a course; add and order lessons; attach skills to the course; publish the course.
• Supporting actions. Open a lesson into the content editor; open a skill into the skills editor; preview the course as a learner would see it.
• Domain entities. Course, lesson, lesson order, skill, publication state, creator.
• Component responsibilities. Course structure panel with reorderable lessons; publication-state control; entry points into the content editor and skills editor; preview control; the numbered section rule marking builder sections.
• States. Loading: the course structure loads with its lessons in order. Empty: a new course with no lessons yet, with a clear first action to add one. Success: the course is published and becomes visible in the catalogue. Error: a failed publish states the reason and leaves the course in its prior state. Recovery: the creator corrects the stated problem and republishes; no authored content is lost.

Content Editor

• Information and state. The creator's surface for authoring the explanation of every word and every prompt, how the prompt is used, and how it is written correctly with AI. Shows the lesson's content in its bilingual structure: Arabic explanation paired with English technical writing.
• Primary actions. Author or edit the Arabic explanation for a lesson; author or edit the English prompt and code; define the lexicon entry for a term; link a prompt token to the explanation that covers it.
• Supporting actions. Preview the mirrored prompt-and-explanation layout as the learner will see it; verify that every English technical term in the explanation has a lexicon entry.
• Domain entities. Lesson content, Arabic explanation block, English prompt, prompt token, lexicon entry, token-to-explanation link, creator.
• Component responsibilities. Bilingual authoring panels sharing one baseline grid; lexicon entry editor; token-linking control; coverage indicator showing terms still lacking a definition; preview control.
• States. Loading: the lesson's existing content loads into both panels. Empty: a lesson with no content yet, with a clear first action. Success: the content is saved and the coverage indicator shows every term defined. Error: a failed save states the failure and preserves the creator's edits in place. Recovery: the creator retries the save; unsaved edits are not discarded.

Skills Editor

• Information and state. The creator's surface for preparing the explanation of the most important skills and how to use them. Shows the skill catalogue and each skill's explanation and usage guidance.
• Primary actions. Create or edit a skill; author its explanation and its usage guidance; attach the skill to courses and lessons.
• Supporting actions. Review which courses and lessons already use a skill; keep a skill's explanation consistent wherever it is attached.
• Domain entities. Skill, skill explanation, usage guidance, course attachment, lesson attachment, creator.
• Component responsibilities. Skill list panel; skill explanation editor; usage-guidance editor; attachment control showing where the skill is used; the numbered section rule marking editor sections.
• States. Loading: the skill catalogue loads. Empty: no skills defined yet, with a clear first action. Success: the skill is saved and its attachments are reflected. Error: a failed save states the failure and preserves the edit. Recovery: retry the save; the skill's prior version remains intact until the save succeeds.

Access Management

• Information and state. The administrator's surface for following subscriptions and issuing and activating access links. Shows each subscriber, their subscription state, and the state of their access link.
• Primary actions. Issue an access link for a subscriber; activate a link; reissue a link that failed activation.
• Supporting actions. Inspect a link's state; confirm that an activated subscriber can reach the course.
• Domain entities. Subscriber, subscription, access link, link state, activation, course, administrator.
• Component responsibilities. Subscriber list with subscription and link state; issue control; activate control; reissue control; state indicators distinguishing issued, activated, expired, and invalid links.
• States. Loading: the subscriber list loads with current link states. Empty: no subscribers yet, stated plainly. Success: a link is issued or activated and the subscriber's state updates. Error: a failed issuance or activation states the reason and leaves the subscriber's prior state unchanged. Recovery: the administrator reissues the link; the subscriber's subscription is unaffected.

Login

• Information and state. The returning-verification surface for learners, creators, and administrators. Anonymous by design — it is reachable without identity, because it is the surface that establishes it.
• Primary actions. Verify returning identity and continue to the person's own protected work.
• Supporting actions. Move to sign-up for a person who does not yet have identity.
• Domain entities. Identity, verification attempt, session.
• Component responsibilities. Verification form; clear failure messaging; link to sign-up; no protected state rendered before verification succeeds.
• States. Loading: the verification attempt is processed. Empty: not applicable. Success: the person reaches their own protected surface. Error: failed verification is stated without revealing whether an identity exists. Recovery: the person can retry verification immediately.

Sign Up

• Information and state. The self-service identity-establishment surface for a learner beginning the product. Anonymous by design. States clearly that educational access remains conditional on subscription and activation.
• Primary actions. Establish identity.
• Supporting actions. Move to login for a person who already has identity.
• Domain entities. Identity, learner, verification state.
• Component responsibilities. Identity-establishment form; explicit statement that access to learning follows subscription and activation; link to login.
• States. Loading: the establishment attempt is processed. Empty: not applicable. Success: identity is established and the learner continues toward the catalogue or enrollment. Error: a failed attempt states the failure without discarding entered information. Recovery: the learner retries; entered information is preserved.

3. Functional Requirements

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

FR-01 — Interactive course-based learning experiences (explicit) As a subscribed learner, I should learn through interactive experiences built on courses, so that the course is something I do rather than something I watch.

• Trigger/input: the learner opens an activated course.
• Observable result: the learner works through interactive lesson and practice surfaces rather than passive content.
• Access state: protected; requires activated access.
• Failure/recovery: if a lesson or task fails to load, the learner's position is preserved and a retry is offered.
• Continuation: the learner advances to the next lesson or task.

FR-02 — Courses built and prepared for training (explicit) As a course creator, I should build courses and prepare the project so that learners have strong interactive teaching and explanations to train on.

• Trigger/input: the creator opens the course builder.
• Observable result: a course exists with its lessons, skills, and content prepared and publishable.
• Access state: protected; creator surface.
• Failure/recovery: a failed publish states the reason and leaves the course in its prior state; no authored content is lost.
• Continuation: the creator corrects the problem and republishes.

FR-03 — Skills-based courses with word-by-word and prompt explanation (explicit) As a course creator, I should build courses on skills and author an explanation of every word, of prompts, of how to use a prompt, and of how to write a prompt correctly with AI, so that the learner understands the craft rather than memorizing outputs.

• Trigger/input: the creator authors lesson content in the content editor.
• Observable result: each lesson carries an Arabic explanation of every term and prompt, with the English prompt and code alongside it.
• Access state: protected; creator surface.
• Failure/recovery: a failed save states the failure and preserves the creator's edits in place.
• Continuation: the creator retries the save and continues authoring.

FR-04 — Powerful interactive interfaces (explicit) As a subscribed learner, I should use powerful interactive interfaces, so that the learning surface itself responds to what I am learning.

• Trigger/input: the learner interacts with a lesson, a course card, or a completion control.
• Observable result: the interface visibly reacts — the generative field shifts with the course, the active lesson marker lights, the progress arc advances.
• Access state: public surfaces react on the entry and catalogue; protected surfaces react inside lessons and practice.
• Failure/recovery: if the generative layer fails, all text and controls remain fully usable on the flat ground.
• Continuation: the learner continues the lesson without interruption.

FR-05 — Subscription followed by an access link (explicit) As a learner, I should subscribe to a course and then receive an access link, so that my access is granted deliberately rather than assumed.

• Trigger/input: the learner completes enrollment for a chosen course.
• Observable result: the enrollment is confirmed and an access link is issued to that learner for that course.
• Access state: enrollment requires established identity; the link is bound to the correct learner.
• Failure/recovery: a failed enrollment states the failure plainly and preserves the learner's course selection.
• Continuation: the learner proceeds to activate the issued link.

FR-06 — Activation opens the course (explicit) As a learner, I should activate my access link, so that I become able to learn the course interactively.

• Trigger/input: the learner opens the access-activation surface with the issued link.
• Observable result: the link is activated and the course opens for that learner.
• Access state: the activation surface is reachable by the learner holding the link and by the access administrator.
• Failure/recovery: an expired or invalid link is named as such, with the recovery path stated; the administrator can reissue it.
• Continuation: the learner continues directly into the lessons.

FR-07 — Detailed tasks (explicit) As a subscribed learner, I should complete detailed tasks inside the course, so that I train on what I have been taught.

• Trigger/input: the learner opens the practice surface for a lesson.
• Observable result: the task and its requirements are presented, the learner works through them, and the task is marked done.
• Access state: protected; requires activated access.
• Failure/recovery: a failed submission preserves the learner's work and states the failure; the learner can resubmit without retyping.
• Continuation: the learner returns to the lesson or advances to the next task.

FR-08 — Precise explanations with deep logic (explicit) As a subscribed learner, I should receive precise explanations that make understanding easy and carry deep logic, so that I understand why something works, not only what to type.

• Trigger/input: the learner reads a lesson's Arabic explanation.
• Observable result: the explanation states the reasoning behind the prompt or technique, paired with the English prompt it explains.
• Access state: protected; requires activated access.
• Failure/recovery: if the lesson fails to load, the learner's position is preserved and a retry is offered.
• Continuation: the learner moves to the next lesson.

FR-09 — Arabic explanation, English writing (explicit) As a subscribed learner, I should read explanation in Arabic while the technical writing, prompts, and code are in English, so that I understand in my language and work in the language of the field.

• Trigger/input: the learner opens any lesson.
• Observable result: Arabic explanation prose and English technical content are presented together on a shared baseline grid.
• Access state: applies to all lesson and practice surfaces.
• Failure/recovery: if one panel fails to load, the lesson does not render half-empty; the learner is offered a retry.
• Continuation: the learner reads both halves together.

FR-10 — Explanation of the most important skills and how to use them (explicit) As a course creator, I should prepare an explanation of the most important skills and how they are used, so that the learner knows which skill to reach for and when.

• Trigger/input: the creator authors a skill in the skills editor and attaches it to courses and lessons.
• Observable result: the skill carries an explanation and usage guidance, and appears attached wherever it is used.
• Access state: protected; creator surface.
• Failure/recovery: a failed save states the failure and preserves the edit; the prior version remains intact until the save succeeds.
• Continuation: the creator continues attaching the skill or moves to another.

FR-11 — Explanation built with design (explicit) As a subscribed learner, I should receive explanation that is built with design, so that the structure of the explanation itself carries meaning.

• Trigger/input: the learner reads a lesson.
• Observable result: the explanation is laid out as a designed structure — mirrored prompt-and-explanation panels on one baseline grid, numbered section rules, and the lexicon primitive — rather than as undifferentiated prose.
• Access state: protected; requires activated access.
• Failure/recovery: if the layout's generative layer fails, the designed structure of text and controls remains intact.
• Continuation: the learner continues through the lesson.

FR-12 — Per-word lexicon interaction (explicit) As a subscribed learner, I should hover any English technical term in the Arabic explanation and see the word, its transliteration, and a one-line Arabic definition, so that "شرح لكل كلمة" is available exactly where I meet the word.

• Trigger/input: the learner hovers or focuses an English technical term inside Arabic explanation text.
• Observable result: an in-place panel raises with the word, its transliteration, and a one-line Arabic definition.
• Access state: available on lesson and practice surfaces.
• Failure/recovery: if a term has no entry, the panel states that no definition is recorded rather than showing an empty panel.
• Continuation: the learner dismisses the panel and continues reading.

FR-13 — Prompt token highlighting (explicit) As a subscribed learner, I should hover a token in a prompt and see the exact part of the explanation that covers it, so that the connection between the English prompt and the Arabic reasoning is visible.

• Trigger/input: the learner hovers a token in the English prompt panel.
• Observable result: the corresponding explanation is highlighted.
• Access state: available on lesson surfaces.
• Failure/recovery: if a token has no linked explanation, no highlight is shown and the lesson remains readable.
• Continuation: the learner continues reading the prompt.

FR-14 — Identity establishment for the learner (required_inference) As a learner, I should establish my identity before enrolling, so that my subscription, my access link, and my progress stay bound to me.

• Trigger/input: the learner begins enrollment without an established identity.
• Observable result: identity is established and the learner continues to enrollment.
• Access state: the identity-establishment surface is anonymous; protected state remains unavailable until identity exists.
• Failure/recovery: a failed attempt states the failure without discarding entered information.
• Continuation: the learner retries or continues to enrollment.

FR-15 — Returning verification (required_inference) As a learner, creator, or administrator, I should verify my returning identity, so that I reach my own protected work and no one else's.

• Trigger/input: the person returns to a protected surface.
• Observable result: the person reaches their own protected surface.
• Access state: the verification surface is anonymous; no protected state renders before verification succeeds.
• Failure/recovery: failed verification is stated without revealing whether an identity exists; the person can retry immediately.
• Continuation: the person continues into their protected work.

FR-16 — Creator and administrator provisioning (required_inference) As a course creator or access administrator, I should receive provisioning before using my restricted functions, so that authoring and access control are not self-granted.

• Trigger/input: the person attempts to reach a creator or administrator surface.
• Observable result: the person reaches their restricted surface only after provisioning and returning verification.
• Access state: protected; restricted to the provisioned role.
• Failure/recovery: an unprovisioned attempt does not reach the restricted surface and states that access is not granted.
• Continuation: the person continues into their restricted work once provisioned.

FR-17 — Access administration (required_inference) As an access administrator, I should follow subscriptions and issue and activate access links, so that every activated subscriber can enter and learn.

• Trigger/input: the administrator opens the access-management surface.
• Observable result: each subscriber's subscription and link state is visible, and links can be issued, activated, or reissued.
• Access state: protected; administrator surface.
• Failure/recovery: a failed issuance or activation states the reason and leaves the subscriber's prior state unchanged; the administrator reissues.
• Continuation: the administrator confirms the subscriber can reach the course.

FR-18 — Course publication (required_inference) As a course creator, I should publish a prepared course, so that it becomes available in the catalogue for learners to find and enroll in.

• Trigger/input: the creator publishes a course from the course builder.
• Observable result: the course appears in the catalogue with its title, skill categories, and lesson count.
• Access state: protected; creator surface.
• Failure/recovery: a failed publish states the reason and leaves the course in its prior state.
• Continuation: the creator corrects the problem and republishes.

FR-19 — Progress and completion as a data event (required_inference) As a subscribed learner, I should see my progress and completion recorded, so that I can resume where I stopped and see what I have finished.

• Trigger/input: the learner marks a lesson or task complete.
• Observable result: completion is recorded, the progress arc advances, and the course's generative field gains a brighter filament.
• Access state: protected; requires activated access.
• Failure/recovery: if completion fails to record, the learner is told and can retry; the lesson remains readable.
• Continuation: the learner resumes at the recorded position on return.

4. User Personas

المتعلّم المشترك (Learner)

Product context. The learner arrives at dakrai to learn AI skills — prompt engineering above all — in Arabic, while working in the English that the field actually uses. They may arrive from the public entry surface without any identity, browse the catalogue, and only then commit.

Primary goal. Complete the interactive course tasks and understand the skills and prompts step by step, with deep logic rather than surface instruction.

Distinct accepted responsibilities. The learner browses courses before subscribing; establishes identity; enrolls in a chosen course; receives and activates an access link; reads lessons where Arabic explanation and English prompts sit side by side; uses the per-word lexicon to resolve any English technical term in place; follows prompt tokens into the explanation that covers them; executes the detailed tasks; marks lessons and tasks complete; and resumes at their recorded position on return.

Relevant inputs and decisions. Which course to enroll in; whether to complete enrollment; whether to activate the issued link; which lesson to read next; whether a task is done.

Interactions with other accepted participants. The learner's enrollment is what causes the access administrator to have a subscription to follow and a link to issue. The learner's activation is the event the administrator confirms. The learner consumes the curriculum the course creator authored, and the learner's completion is the outcome the creator's work is measured by.

Observable success. The learner's access link is activated, the course opens, lessons and tasks are completed, and progress is recorded and resumable.

What makes this role different. The learner is the only actor whose access is conditional on a two-step gate — subscription, then activation — and the only actor whose durable state is progress rather than authored content or issued access.

منشئ الكورسات والمحتوى التعليمي (Course Creator)

Product context. The creator is the person who makes the academy's promise real. The source requires that courses be built and the project prepared, with strong interactive teaching and explanations that learners train on, grounded in skills, with an explanation of every word and every prompt.

Primary goal. Have courses that are ready, interactive, and trainable — with every term defined and every prompt explained.

Distinct accepted responsibilities. The creator builds a course and orders its lessons; authors the Arabic explanation and the English prompt and code for each lesson; defines the lexicon entry for each English technical term and links prompt tokens to the explanation that covers them; authors the most important skills and how to use them; attaches skills to courses and lessons; previews the course as a learner will see it; and publishes the course.

Relevant inputs and decisions. What the course contains; which skills it is built on; how a prompt is explained; whether every term is defined; whether the course is ready to publish.

Interactions with other accepted participants. The creator's published course is what the learner browses and enrolls in. The creator's authored content is what the learner reads and trains on. The creator does not control who gets access — that belongs to the access administrator.

Observable success. A published course appears in the catalogue with its skills, lessons, and content, and its coverage indicator shows every English technical term defined.

What makes this role different. The creator is the only actor who produces durable authored content, and the only actor whose work is judged by whether a learner can understand it — the bilingual authoring constraint and the lexicon-coverage obligation are unique to this role.

المشرف على الاشتراكات وتفعيل الوصول (Access Administrator)

Product context. The source states that access is granted after subscription through an access link that is activated for the subscriber. The administrator is the person who makes that gate work.

Primary goal. Every activated subscriber can enter and learn the course.

Distinct accepted responsibilities. The administrator follows subscriptions; issues access links for subscribers; activates links; inspects a link's state; reissues a link that failed activation; and confirms that an activated subscriber can reach the course.

Relevant inputs and decisions. Which subscriber needs a link; whether a link is issued, activated, expired, or invalid; whether to reissue.

Interactions with other accepted participants. The administrator acts on the learner's enrollment and produces the link the learner activates. The administrator does not author curriculum — that belongs to the course creator.

Observable success. Each subscriber's link state is correct and every activated subscriber can reach their course.

What makes this role different. The administrator is the only actor who controls the access gate, and the only actor whose success is measured by another person's ability to get in.

5. Core User Flows

Flow A — A learner discovers dakrai and enrolls

1. The learner arrives at Landing without identity. The generative field renders as the hero backdrop, the Arabic headline and English kicker are readable, and the enrolled-learner counter shows in tabular numerals.
2. The learner reads what a course is made of — skills, word-by-word explanation, prompts, detailed tasks — and selects the primary call to action.
3. The learner lands on Courses and scans the catalogue. Each course card shows its title, skill categories, and lesson count, and each card's generative sculpture differs because it derives from that course's curriculum data.
4. The learner opens a course and decides to enroll. Because enrollment requires identity, the learner is directed to Sign Up.
5. On Sign Up, the learner establishes identity. The surface states plainly that educational access remains conditional on subscription and activation.
6. The learner continues to Enrollment for the chosen course. The enrollment summary shows the course and what the subscription grants.
7. The learner completes the subscription. Enrollment is confirmed and the learner is told an access link will be issued.
8. Failure path: if enrollment fails, the failure is stated plainly and the learner's course selection is preserved; the learner retries without re-selecting the course.
9. Continuation: the learner proceeds to activate the issued link.

Flow B — A learner activates access and enters the course

1. The learner receives the access link issued after enrollment and opens Access Activation.
2. The surface resolves the link's state and shows it as issued.
3. The learner activates the link. The surface confirms success and names the course that is now open.
4. Failure path — expired or invalid link: the surface names the state as expired or invalid rather than as a generic failure, and states the recovery path. The learner requests a corrected link.
5. Recovery: the access administrator reissues the link from Access Management (see Flow E), and the learner returns to Access Activation and activates it.
6. Continuation: the learner continues directly into Lessons.

Flow C — A learner reads a lesson and trains on its tasks

1. The learner opens Lessons inside the activated course. The lesson renders with the Arabic explanation and the English prompt and code on one shared baseline grid, so neither half renders alone.
2. The learner reads the Arabic explanation. Meeting an English technical term, the learner hovers it and an in-place lexicon panel raises with the word, its transliteration, and a one-line Arabic definition.
3. The learner hovers a token in the English prompt. The exact part of the explanation covering that token is highlighted.
4. The learner marks the lesson complete. A 400ms ember wipe crosses the panel, the progress arc advances, and a brighter filament is seeded into that course's generative field.
5. The learner opens Practice for the lesson. The task and its requirements are presented together.
6. The learner works through the detailed task and submits it. The task is marked done and progress advances.
7. Failure path: if the submission fails, the learner's work is preserved and the failure is stated; the learner resubmits without retyping.
8. Continuation: the learner returns to the lesson or advances to the next task, and on a later visit resumes at the recorded position.

Flow D — A course creator builds and publishes a course

1. The creator reaches Login and verifies their returning identity. No protected state renders before verification succeeds.
2. The creator opens Course Builder and creates a course. The structure panel shows the course with no lessons yet and a clear first action.
3. The creator adds lessons and orders them.
4. The creator opens a lesson into Content Editor. Both authoring panels load together: the Arabic explanation and the English prompt and code.
5. The creator authors the Arabic explanation of every word and the English prompt, defines the lexicon entry for each English technical term, and links prompt tokens to the explanation that covers them. The coverage indicator shows which terms still lack a definition.
6. The creator opens Skills Editor, authors the most important skills and how to use them, and attaches each skill to the courses and lessons that use it.
7. The creator previews the course as a learner will see it, confirming the mirrored prompt-and-explanation layout reads correctly.
8. The creator publishes the course. It appears in Courses with its title, skill categories, and lesson count.
9. Failure path: if a save or publish fails, the failure is stated and the creator's edits are preserved in place; the course stays in its prior state. The creator retries.
10. Continuation: the creator returns to the builder to extend the course or begin another.

Flow E — An access administrator issues and activates access

1. The administrator reaches Login and verifies their returning identity.
2. The administrator opens Access Management. The subscriber list loads with each subscriber's subscription state and link state.
3. The administrator issues an access link for a subscriber whose enrollment is confirmed. The subscriber's state updates to show the link as issued.
4. The administrator activates the link, or the subscriber activates it from Access Activation; the state updates to activated.
5. The administrator confirms the subscriber can reach the course.
6. Failure path: if issuance or activation fails, the reason is stated and the subscriber's prior state is unchanged. If a subscriber reports an expired or invalid link, the administrator inspects its state and reissues it.
7. Continuation: the administrator moves to the next subscriber. The subscriber's subscription is unaffected by a reissue.

Flow F — A returning person verifies identity

1. A learner, creator, or administrator returns to a protected surface and is directed to Login.
2. The person submits their verification. No protected state is rendered before it succeeds.
3. On success, the person reaches their own protected surface — lessons and practice for the learner, builder and editors for the creator, access management for the administrator.
4. Failure path: failed verification is stated without revealing whether an identity exists, and the person can retry immediately.
5. Continuation: the person continues into their protected work.

6. Visuals Colors and Theme

The creative direction is authoritative for this section. The muse is Refik Anadol: data made physical, a living neural field as the classroom.

Headline. Data made physical — a living neural field as the classroom. dakrai's subject is AI, so the hero artefact is a generative data field that behaves like a living model. The generative canvas is the interface, not decoration.

Palette — dark mode.

The generative field is the only place multi-hue appears: a slow flow of #FF5A1F (ember) → #FF2E88 (magenta) → #5CE1C6 (data teal) → #7A5CFF (violet) particles at 20–40% opacity, never as a gradient behind text. Ember orange is the single interactive signal: primary CTA, active lesson marker, progress arc. Data teal marks verified and completed states and English technical terms inline. No blue-indigo anywhere.

Typography.

• Headings: Archivo Expanded (Archivo, width axis 125–150) — uppercase for English display, weight 600–700, tracking -0.01em on display and +0.14em on micro-labels.
• Arabic headlines: IBM Plex Sans Arabic at weight 700, normal tracking — never negative tracking on Arabic script.
• Body: IBM Plex Sans Arabic.
• Display scale, deliberately oversized: hero headline clamp(40px, 9vw, 132px).
• Modular scale 1.333 — display 132/88/56/40; heading 40/32/24; body 19/17/16; micro-label 12 uppercase mono-ish.
• Line-height: 1.02 for display, 1.7 for Arabic body, 1.6 for English body.
• Tabular numerals (font-feature-settings: 'tnum') for lesson counts, timers, and progress.

Shape language. Museum-like: square corners everywhere (0–4px radius), thin 1px luminous rules, and the only curves are the generative flow lines and the circular progress arcs. Cards are flat panels with a hairline border and a 1px top-edge data line that lights ember when active. No blobs, no pill buttons — CTAs are wide rectangles with a 2px ember underline that extends on hover.

Layout. Full-bleed generative canvas as the fixed hero backdrop, with content in a 12-column grid over it at max-width 1280px. Asymmetric: text blocks occupy columns 1–6, the interactive field occupies 7–12 and bleeds off the right edge. Sections are separated by full-width 1px rules with a small mono label sitting on the rule (e.g. 01 / SKILLS). Lesson pages use a two-column code-and-explanation split: the English code/prompt panel on the right in RTL reading order, the Arabic explanation on the left, aligned to the same baseline grid.

Imagery. No stock photography and no people. The imagery is the generative render: a WebGL particle/flow field whose parameters are literally derived from the curriculum data — number of lessons, skill categories, prompt tokens — so each course page renders a visibly different sculpture. Supporting imagery is schematic: token diagrams, embedding-space plots, and prompt-diff views drawn as thin luminous line art on the dark ground.

Avoid. Blue/indigo primaries on white grounds and any #0057FF / #2563EB / #6366F1 family colour; Inter, Roboto, Arial, Helvetica, Open Sans, Lato, Poppins, or system-ui as heading or body fonts; gradient-blob heroes, glassmorphism cards, and grids of identical hover-lift cards; centred headline-plus-subtext-plus-button SaaS hero composition; stock photography of people, laptops, or team-collaboration imagery; HUD/cyberpunk clichés — scanlines, hexagon grids, glowing wireframe globes, neon outlines on every element; decorative motion not tied to curriculum data or user progress; Arabic display type set with negative letter-spacing or in a font without a proper Arabic cut.

Readable text and controls stay whole at every viewport. Headlines, wordmarks, labels, numbers, and cards' 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 follow the creative direction and may be cropped, bled off an edge, rotated, overlapped, or cut — as long as they cover no readable text or control. Moving and scrollable content may cross the viewport or container edge by design and is judged by whether it actually moves or scrolls and whether every item becomes fully readable as it passes. With prefers-reduced-motion, provide a usable static arrangement: wrap items into rows or allow horizontal scrolling so each item can be brought fully into view.

7. Signature Design Concept

The field is the classroom.

The public entry is a full-bleed #07070B viewport. A WebGL generative particle field fills the right 60% of the screen and bleeds off the top and right edges; its flow lines run ember → magenta → teal at low opacity. The field is not a background image — it is a live render whose parameters are derived from the academy's actual curriculum data: the number of lessons, the skill categories, the prompt tokens. Change the curriculum and the sculpture changes.

Over the left 40% — flush to the right margin in RTL, carrying the Arabic headline — sits an oversized two-line Arabic headline «تعلّم الذكاء الاصطناعي من داخل النموذج» at clamp(40px, 9vw, 132px) in #F2F0EA, with a small uppercase English kicker DAKRAI — INTERACTIVE AI ACADEMY in data teal above it. Beneath the headline, one 60ch Arabic paragraph at 19px, then a single wide ember CTA «ابدأ الكورس» with a live counter of enrolled learners in tabular numerals.

There is no centred stack, no gradient blob, and no floating card mockup. The field is the only visual subject, and the type sits directly on top of it with a subtle 60px radial scrim for legibility. The composition is asymmetric by construction: the machine occupies the right, the learner's language occupies the left, and the two meet on the same baseline.

This concept recomposes only accepted content, states, and controls — the academy's identity, its course and skill summaries, the enrolled-learner count, and the single entry action. It introduces no new behaviour, page, or destination.

8. Interaction Model & Motion Direction

Interaction Model: Animated Motion Tempo: cinematic Hero Dimensionality: webgl

Landing Hero Motion Brief

Focal subject. A real-time WebGL particle/flow field whose parameters are derived from the academy's curriculum data — lesson counts, skill categories, and prompt tokens — rendered as a living neural field on the #07070B ground.

Input → transformation → outcome thesis. As the visitor scrolls through the curriculum, the field's density increases; as the pointer moves across a course card, the field's hue shifts locally toward that course's accent. The input is the visitor's attention over the curriculum; the transformation is a change in the field's density and hue; the outcome is that the interface visibly reacts to the data it represents, so the visitor understands the academy's subject by watching it behave.

Motion vocabulary. Continuous slow generative flow at roughly 0.15× speed with no user-triggered jumps; scroll-linked morphing of field density; a 400ms ember ignite wipe when a lesson is marked complete; hover-driven local hue shift on course cards. Nothing bounces. Easing is cubic-bezier(0.16, 1, 0.3, 1).

Composed first frame. The field already flowing at rest, filling the right 60% and bleeding off the top and right edges, ember → magenta → teal filaments at low opacity. The Arabic headline sits flush to the right margin over the left 40%, the teal English kicker above it, the 60ch Arabic paragraph beneath, and the single wide ember CTA with its live counter at the baseline. A 60px radial scrim sits behind the type for legibility.

Reduced-motion state. With prefers-reduced-motion, the field renders as a single static composed frame of the same sculpture — no flow, no scroll-linked morphing, no hover hue shift. The headline, kicker, paragraph, CTA, and counter remain fully readable and operable, and the page's numbered section rules and content blocks wrap into a static arrangement in which every item can be brought fully into view.

Landing Hero 3D Scene Brief — DIRECTION-DERIVED

The direction's hero dimensionality is webgl, so a crafted real-time scene is expected.

The object. A single generative particle/flow field — a compact, self-contained real-time sculpture that shows the product's defining state: a curriculum rendered as a living model. It is one crafted object, not a scene of many props.

What it shows. The field's particle count, flow density, and hue distribution are driven by the academy's curriculum data, so the sculpture is a truthful visualisation of the courses it represents. Each course page renders a visibly different sculpture because its data differs.

Behaviour. Slow continuous flow at rest; density increases with scroll through the curriculum; local hue shifts toward a course's accent on card hover; a brighter filament is permanently seeded into the field when a lesson is completed, so progress literally changes the artwork.

Constraints. The field never renders as a gradient behind text; it occupies the right 60% and bleeds off the top and right edges; a 60px radial scrim protects type legibility; and if the WebGL context fails to initialize, the page falls back to the flat ink ground with all text and controls intact.

9. Non-Functional Requirements

NFR-01 — Bilingual correctness (explicit) Arabic explanation prose and English technical writing must both render correctly, including right-to-left Arabic layout alongside left-to-right English prompts and code, on a shared baseline grid. Arabic display type must never be set with negative letter-spacing or in a font without a proper Arabic cut. Rationale: the source requires Arabic explanation and English writing as a hard constraint.

NFR-02 — Readable text and controls at every viewport (explicit) Headlines, wordmarks, labels, numbers, and cards' text and controls must stay entirely inside the viewport and their container at 375px, 768px, and 1280px, wrapping or scaling to fit, with no other element covering any part of them. Rationale: stated as a hard readability constraint in the creative direction.

NFR-03 — Reduced-motion usability (explicit) With prefers-reduced-motion, the product must provide a usable static arrangement in which every item can be brought fully into view, and all text and controls remain readable and operable. Rationale: stated in the creative direction.

NFR-04 — Generative layer is never load-bearing (required_inference) If the WebGL generative layer fails to initialize or loses its context, every page must remain fully usable on the flat ink ground, with all text, controls, and states intact. Rationale: the generative field is the product's visual subject, but no accepted capability may depend on it.

NFR-05 — Access gate integrity (explicit) Protected learning surfaces must not be reachable before the learner's access link is activated, and creator and administrator surfaces must not be reachable before provisioning and returning verification. Rationale: the source states that access to learning follows subscription and activation.

NFR-06 — Identity continuity (required_inference) A learner's progress, a creator's authored content, and an administrator's issued links must remain bound to the correct person across visits. Rationale: required to make the accepted journeys executable without adding a product capability.

NFR-07 — Contrast (explicit) Body text #F2F0EA on #07070B measures 17.6:1 and muted #8A8A99 on #07070B measures 6.0:1; both pass AA at body size. Rationale: stated in the creative direction.

NFR-08 — No blue-indigo (explicit) No #0057FF / #2563EB / #6366F1 family colour may appear anywhere in the product. Rationale: stated as a prohibition in the creative direction.

NFR-09 — Failure preserves work (required_inference) A failed save, submission, enrollment, or publish must preserve the actor's in-progress work and state the failure plainly, so the actor can retry without redoing it. Rationale: required for the accepted journeys to have usable recovery.

10. Tech Stack

The source specifies no technology choices, so the following are coherent defaults labeled as such.

• Frontend: React with a component-based UI, TypeScript. [Default — not specified by user]
• Generative hero: WebGL via React Three Fiber and Drei for the particle/flow field, with a static fallback path. [Default — not specified by user]
• Backend: Python with FastAPI, exposing the course, lesson, skill, enrollment, access-link, and identity endpoints. [Default — not specified by user]
• Storage: a relational database for courses, lessons, skills, lexicon entries, enrollments, access links, identities, and progress records; object storage for any authored media. [Default — not specified by user]
• Containerization: Docker with docker-compose for local and single-host deployment. [Default — not specified by user]
• Orchestration: Kubernetes only if deployment scale requires it; not required by any accepted requirement. [Default — not specified by user]

11. Assumptions and Constraints

Constraints (binding).

• C-01 (explicit) — Access to learning a course follows subscription and is granted through an access link that is activated for the subscriber.
• C-02 (explicit) — Explanation is in Arabic; technical writing, prompts, and code are in English.
• C-03 (explicit) — The palette, typography, shape language, layout, motion, and imagery of the creative direction are authoritative for the visual system, including the prohibition on blue-indigo and on the listed font families.

Assumptions (narrow, labeled).

• A-01 (required_inference) — Identity is application-owned, because a subscription, an issued access link, and durable learner progress must remain bound to the correct participant across visits.
• A-02 (required_inference) — The interaction that establishes identity is anonymous, because a person cannot be required to already be inside the thing they are trying to enter.
• A-03 (required_inference) — Creator and administrator access is provisioned rather than self-granted, because authoring and access control are restricted functions.
• A-04 (required_inference) — Enrollment is the commitment that causes an access link to be issued; the link is bound to the enrolling learner and the chosen course.
• A-05 (required_inference) — Completion and progress are recorded per learner per lesson and task, so a learner can resume at their recorded position.
• A-06 (required_inference) — A course must be published before it appears in the catalogue.

Boundaries deliberately not crossed.

• No social feed, discussion forum, or peer interaction was accepted.
• No certificate or credential issuance was accepted.
• No payment-gateway specification was accepted; enrollment is the accepted commitment step.
• No mobile application was accepted.
• No third-party course marketplace was accepted.
• No account-management surface beyond establishing and verifying identity was accepted.
• No future-horizon requirements were accepted; everything in this document is current.

12. Glossary

• dakrai — The Arabic-first interactive AI-skills academy described by this document.
• Course — A structured learning unit built from skills and lessons, authored by a course creator and published to the catalogue.
• Lesson — A unit inside a course presenting Arabic explanation alongside English technical writing, prompts, and code.
• Skill — A capability the course teaches, carrying an explanation and usage guidance, attachable to courses and lessons.
• Prompt — The English instruction text taught in a lesson, including how it is used and how it is written correctly with AI.
• Prompt token — A discrete piece of a prompt that can be linked to the exact part of the explanation covering it.
• Lexicon entry — The record for an English technical term: the word, its transliteration, and a one-line Arabic definition, surfaced in place when the term is hovered.
• Task — A detailed practice exercise attached to a lesson, with requirements the learner works through and submits.
• Enrollment — The learner's commitment to a course, which causes an access link to be issued.
• Access link — The link issued to a learner after enrollment, which must be activated before the course opens.
• Activation — The act of activating an access link, after which the learner can learn the course interactively.
• Generative field — The real-time WebGL particle/flow sculpture whose parameters derive from curriculum data, serving as the product's hero artefact and visual subject.
• Learner — The subscribed learner persona: المتعلّم المشترك.
• Course Creator — The course and educational-content creator persona: منشئ الكورسات والمحتوى التعليمي.
• Access Administrator — The subscription and access-activation administrator persona: المشرف على الاشتراكات وتفعيل الوصول.