AI Vibe Coder

The idea names one user and task, has a small testable benefit, excludes high-impact automation, and records an accountable approver.

Evidence shows use of the approved account, starter, sandbox, synthetic data, and sharing settings, with no prohibited data or unapproved service.

The map correctly shows user input, interface, server, stored synthetic data, AI assistance, output, and the human decision point.

The rules require clear context, one small change, review before acceptance, a reversible checkpoint, and escalation when the learner cannot verify the output.

Core labels and rules are available in clear Arabic and English without changing scope, responsibility, or safety meaning.

The map is supported by approved observation or case evidence and accurately includes actors, inputs, decisions, handoffs, exceptions, and delays.

The brief distinguishes the user problem from a proposed technology and defines one feasible task, owner, user group, boundary, and explicit exclusions.

Criteria are observable and test normal, invalid, unauthorized, bilingual, and failure paths rather than visual completion alone.

High-impact decisions and prohibited data are excluded, assumptions and unresolved exceptions are visible, and a workable manual fallback is retained.

Arabic and English headings, workflow labels, and acceptance statements are consistent and usable by the named internal audience.

A named user can enter, review, correct, submit, and confirm the task without dead ends, hidden requirements, or loss of entered data.

Fields, constraints, validation timing, messages, and loading, empty, error, success, and permission states match the acceptance criteria.

Keyboard order, visible focus, labels, contrast, zoom, error identification, and non-color cues are checked with recorded results and fixes.

The interface makes scope, data status, permissions, uncertain or failed actions, and the safe next step visible without deceptive confirmation.

RTL and LTR layouts, content meaning, control order, validation, and recovery are equivalent and have been reviewed by an Arabic-English reviewer.

Records cover normal, boundary, missing, invalid, duplicate, and unauthorized scenarios, follow the field dictionary, and cannot be mistaken for real people or cases.

Implemented states and transitions match the diagram, reject impossible moves, preserve valid data, and route exceptions to a named human.

Each role can perform only listed actions, forbidden actions fail safely, and evidence covers both allowed and denied cases.

Audit entries answer who did what, when, to which synthetic record, and with what result, while excluding credentials and unnecessary content.

Arabic and English status, validation, permission, and handoff messages are equivalent, actionable, and consistent with the implemented state.

The request supplies enough verified context to implement one criterion, names constraints and exclusions, and does not include prohibited data.

The resulting behavior satisfies the selected criterion for normal and invalid input without breaking the previously demonstrated workflow.

Every changed file and material line is accounted for; unrelated edits, unexplained code, unsafe configuration, and unnecessary dependencies are rejected.

A repeatable check fails before or would detect absence of the change, passes afterward, covers invalid input, and the saved checkpoint restores the prior version.

Any changed labels, messages, validation, or help remain equivalent and usable in Arabic and English.

The plan traces acceptance criteria to repeatable scenarios and records expected, actual, pass or fail, evidence, and defect references for each.

Normal, invalid, unauthorized, interruption, retry, and recovery behavior matches the brief, with no unresolved critical defect.

A documented inspection covers data, prompts, configuration, history, logs, exports, screenshots, and sharing; prohibited information is absent and credentials are managed by the approved workspace.

The decision follows the evidence, distinguishes pass, conditional pass, and stop conditions, and exposes defects, unsupported use, and the manual fallback.

A colleague can use the Arabic-English handover to access, operate, test, stop, recover, and seek support for the prototype without oral instructions.

Observed workflow evidence supports the selected language task, a simpler alternative is compared fairly, and AI is not used for a high-impact decision.

The helper is read-only, accepts bounded synthetic input, follows the stated instruction, and cannot silently update records or trigger workflow actions.

Every factual answer is constrained to the supplied approved sources, displayed citations resolve correctly, and source gaps produce abstention.

Tests cover unsupported, ambiguous, adversarial, confidential-looking, timeout, and service-error cases, preserve human confirmation, and keep the non-AI path available.

Arabic and English answers, citations, refusals, warnings, and fallback messages preserve meaning and are understandable to the target colleague.

The named user can complete the approved workflow from input to confirmed outcome, including role checks, status transitions, and a safe fallback.

Repeatable tests cover acceptance criteria, invalid and denied paths, recovery, regression, and any AI citations and abstention, with critical failures resolved.

The tool uses only synthetic data, enforces least access, exposes uncertainty and known defects, retains the manual path, and has clear stop and support instructions.

Reviewer evidence is categorized by task impact and risk, and the final improve, hold, handover, or stop decision follows that evidence and names an owner.

Arabic RTL and English LTR experiences are equivalent across the complete flow, pass the stated accessibility checks, and are documented for the receiving colleague.