Disclaimer
Purpose: This platform serves as an independent project constructed exclusively for the advancement of educational exploration and dedicated artificial intelligence research. It aims to foster a deeper understanding of modern technology without any external influence. Users can utilize this secure environment to study complex systems, test innovative ideas, and learn safely.
Non-Commercial: There is absolutely no underlying business model associated with this independent project. It is strictly not intended to generate financial revenue, monetary profit, or any tangible commercial value. Our core focus remains purely on academic development, ensuring that access remains completely free from hidden costs, corporate sponsorships, or advertising schemes.
No Guarantees: Because this platform operates as an educational tool utilizing experimental artificial intelligence, generated outputs may occasionally be inaccurate, misleading, or entirely incomplete. All provided content is strictly offered on an as is basis, completely without any express or implied warranties, guarantees of factual correctness, or promises regarding overall reliability whatsoever.
Table of Content
Part 1: Design The Practice Engine Around URL State This section explains how exam, chapter, and question query parameters make every practice state shareable, testable, and easy to debug without a backend or account system.
Part 2: Use One JSON Shape For Many Exams This section explores the reusable exam-bank schema and why consistent fields let one renderer support data, ML, networking, cloud operations, FSI, and AI development practice sets.
Part 3: Make Submit Feedback The Learning Loop This section breaks down the answer-checking pattern: selected answers, sorted correct answers, result text, per-option explanations, and no distracting red or green effects.
Part 4: Treat Mobile Buttons As Product Quality This section shows why larger mobile question, submit, and next buttons matter, and how small responsive changes can make the demo feel usable instead of merely complete.
Part 5: Debug With Contracts, Not Guesswork This section turns common vibe-coding errors into checks: failed fetches, missing JSON files, inconsistent answers, bad query strings, and page states that need predictable fallbacks.
Design The Practice Engine Around URL State
Goal
Make a question screen that can be shared, reloaded, bookmarked, debugged, and opened directly from a marketing page.
Prompt
The prompt said the URL query string should include the exam name, chapter, and question, and the page should go to the related question.
Result
practice-room.html reads exam, chapter, and question from URLSearchParams. It derives the JSON filename, fetches it, finds the requested chapter and question, renders the page, and updates the URL on navigation.
Tips
- A URL is a product interface, not just browser decoration.
- Default values should make local testing easy.
- Use replaceState when navigation should update context without leaving the page.
- Keep the query parameter names human-readable.
- Make every card link open a meaningful first question.
The URL contract is the smallest possible routing system. It creates deep links without a router, server, database, or authentication layer.
Use One JSON Shape For Many Exams
Goal
Let many exam topics use the same renderer by enforcing one stable content shape.
Prompt
The prompt repeatedly said to follow aws_certified_data_exam_questions.json as the template when adding new practice sets.
Result
All exam banks expose chapters and questions with options, answers, and explanations. That lets the UI support data, machine learning, networking, cloud operations, FSI trading, generative AI, and AI development banks.
Tips
- Do not let each content import invent its own schema.
- Keep answer as an array so single-choice and multi-select use one model.
- Keep explanations keyed by option letter.
- Store display titles in JSON so the UI can label itself.
- Count questions with tooling before claiming scale.
Exam-bank inventory from the folder:
- aws_ai_development_exam_questions.json: 20 questions in 1 chapter.
- aws_generative_ai_dev_organization_exam_questions.json: 80 questions in 4 chapters.
- aws_netowrking_core_exam_questions.json: 98 questions in 2 chapters.
- aws_fsi_trading_desk_design_exam_questions.json: 680 questions in 34 chapters.
- aws_certified_cloud_operations_exam_questions.json: 520 questions in 5 chapters.
- aws_fsi_macro_trading_exam_questions.json: 380 questions in 23 chapters.
- aws_certified_machine_learning_exam_questions.json: 460 questions in 4 chapters.
- aws_certified_data_exam_questions.json: 82 questions in 5 chapters.
- aws_certified_data_exam_questions_v1.json: 82 questions in 5 chapters.
Make Submit Feedback The Learning Loop
Goal
Turn a simple quiz into a learning experience by showing why each option is right or wrong after submission.
Prompt
The prompt asked for submit to show correct and wrong answer explanation and explicitly said no red or green UI effect was needed.
Result
The implementation sorts selected answers and correct answers, compares them, prints the result, prints the correct answer, and then renders one explanation block per option.
Tips
- Text feedback is enough for a first learning loop.
- Avoid flashy correctness UI until the explanation quality is strong.
- Keep selected and correct state visible in the result.
- Use the same submit path for radio and checkbox questions.
- Make no-explanation fallbacks obvious so content gaps can be fixed.
This is important for vibe coding because it stops the AI from over-designing. The requested behavior was not a gamified scoreboard. It was a study room. The UI should serve recall and review.
Treat Mobile Buttons As Product Quality
Goal
Make the practice room usable on phones, where many builders will study between meetings, on transit, or during quick review sessions.
Prompt
The prompt asked for mobile layout with the question and answer area on top, the question list below, larger question buttons, and larger submit and next buttons.
Result
The CSS uses media queries to change layout order, increase button hit areas, and keep the question list usable when the screen narrows.
Tips
- Mobile usability is not a polish pass; it is core behavior.
- Button size is a learning feature when people study on phones.
- Ordering content matters more than decoration.
- Keep the current question highlighted.
- Use simple grids and flex layouts before reaching for complex components.
A practice product fails if users mis-tap answers. A larger button is not cosmetic; it protects attention.
Debug With Contracts, Not Guesswork
Goal
Make failures explain themselves by validating assumptions at the boundary between HTML, URL, and JSON.
Prompt
The build asked for direct JSON loading by query string and later added many exam filenames. That means typos and missing files are the likely failure mode.
Result
The player catches load failures and shows a clear message asking the user to check the exam query parameter and JSON file.
Tips
- When fetch fails, show the filename that failed.
- When a chapter is missing, fall back predictably.
- When a question is missing, start at the first question.
- When adding a card, verify the JSON file exists.
- When adding an exam bank, inspect answer arrays and explanation keys.
The debugging lesson is simple: if the AI creates a link, the next prompt should verify the file behind the link. Vibe coding needs a validation reflex.
Field Note 1: URL state
Background
The practice player needed shareable links that open a specific exam, chapter, and question without server routing.
Goal
Make every learning state addressable from a URL.
Prompt
Use exam, chapter, and question query parameters to go to the related question.
Result
The page reads URLSearchParams, resolves the JSON file, finds the chapter, and highlights the current question.
Tips
- Use stable parameter names.
- Default to a known practice set.
- Update the URL on navigation.
- Make cards link into real states.
- Test copy-pasted URLs.
Evidence from the demo
The page reads URLSearchParams, resolves the JSON file, finds the chapter, and highlights the current question. This is the part a reviewer can check directly. The field note should stay connected to that evidence instead of drifting into generic advice about vibe coding.
Review check
For URL state, confirm three things: the background describes a real project pressure, the goal names the intended behavior, and the result points to something visible in the files or browser. If one of those three pieces is missing, rewrite the note before publishing.
Field Note 2: JSON loading
Background
The app loads static JSON files directly from the same folder. That keeps deployment simple but makes filenames important.
Goal
Load many exam banks through one player without bundling or backend code.
Prompt
HTML page load the JSON of URL query string.
Result
The player derives the filename from the exam parameter and fetches it before rendering.
Tips
- Match card exam names to filenames.
- Show a helpful fetch error.
- Keep JSON in the same schema.
- Avoid hidden transformations.
- Validate the first question renders.
Evidence from the demo
The player derives the filename from the exam parameter and fetches it before rendering. This is the part a reviewer can check directly. The field note should stay connected to that evidence instead of drifting into generic advice about vibe coding.
Review check
For JSON loading, confirm three things: the background describes a real project pressure, the goal names the intended behavior, and the result points to something visible in the files or browser. If one of those three pieces is missing, rewrite the note before publishing.
Field Note 3: answer checking
Background
Single-choice and multi-select questions both appear in AWS-style practice material.
Goal
Use one answer-checking path for radio buttons and checkboxes.
Prompt
Submit should show correct and wrong answer explanation.
Result
The code collects selected inputs, sorts them, compares them with the sorted answer array, and prints a result.
Tips
- Store answers as arrays.
- Sort before comparing.
- Do not assume one answer.
- Keep selected state readable.
- Test a select-two question.
Evidence from the demo
The code collects selected inputs, sorts them, compares them with the sorted answer array, and prints a result. This is the part a reviewer can check directly. The field note should stay connected to that evidence instead of drifting into generic advice about vibe coding.
Review check
For answer checking, confirm three things: the background describes a real project pressure, the goal names the intended behavior, and the result points to something visible in the files or browser. If one of those three pieces is missing, rewrite the note before publishing.
Field Note 4: multi-select logic
Background
A multiple-answer item should not need a separate data model from a single-answer item.
Goal
Let answer count determine input type while preserving the same rendering flow.
Prompt
A multiple-choice item has one key; a select-two item has multiple keys.
Result
The renderer uses radio inputs when the answer array has one value and checkboxes when it has more than one.
Tips
- Derive UI from data.
- Avoid duplicate renderers.
- Keep input names consistent.
- Compare full answer sets.
- Mention select-two in question text.
Evidence from the demo
The renderer uses radio inputs when the answer array has one value and checkboxes when it has more than one. This is the part a reviewer can check directly. The field note should stay connected to that evidence instead of drifting into generic advice about vibe coding.
Review check
For multi-select logic, confirm three things: the background describes a real project pressure, the goal names the intended behavior, and the result points to something visible in the files or browser. If one of those three pieces is missing, rewrite the note before publishing.
Field Note 5: explanation rendering
Background
The learning value is in the rationale, not only the score.
Goal
Show feedback for every option after submit.
Prompt
When user clicks submit, show correct and wrong answer explanation without red or green UI effect.
Result
The result box lists selected state, answer state, and explanation text for each option.
Tips
- Explain distractors.
- Keep correct answer visible.
- Use text before color effects.
- Provide no-explanation fallbacks.
- Review explanation quality.
Evidence from the demo
The result box lists selected state, answer state, and explanation text for each option. This is the part a reviewer can check directly. The field note should stay connected to that evidence instead of drifting into generic advice about vibe coding.
Review check
For explanation rendering, confirm three things: the background describes a real project pressure, the goal names the intended behavior, and the result points to something visible in the files or browser. If one of those three pieces is missing, rewrite the note before publishing.
Field Note 6: chapter navigation
Background
Large exam banks have multiple chapters and hundreds of questions, so navigation must remain simple.
Goal
Render chapter groups and question buttons from the JSON structure.
Prompt
Left area shows all chapters and questions horizontally.
Result
The question list groups buttons by chapter and highlights the current question.
Tips
- Generate navigation from data.
- Keep chapter labels compact.
- Highlight current state.
- Reset result when changing questions.
- Avoid manual button markup.
Evidence from the demo
The question list groups buttons by chapter and highlights the current question. This is the part a reviewer can check directly. The field note should stay connected to that evidence instead of drifting into generic advice about vibe coding.
Review check
For chapter navigation, confirm three things: the background describes a real project pressure, the goal names the intended behavior, and the result points to something visible in the files or browser. If one of those three pieces is missing, rewrite the note before publishing.
Field Note 7: error states
Background
A static player fails mainly when a query string points to a missing JSON file or malformed content.
Goal
Make the failure obvious to the person testing links.
Prompt
Please check exam query parameter and JSON file.
Result
The catch block changes the title, shows the error message, and displays a clear empty-state instruction.
Tips
- Fail in the UI, not the console only.
- Name the likely fix.
- Keep the page usable after failure.
- Test bad exam values.
- Do not hide fetch errors.
Evidence from the demo
The catch block changes the title, shows the error message, and displays a clear empty-state instruction. This is the part a reviewer can check directly. The field note should stay connected to that evidence instead of drifting into generic advice about vibe coding.
Review check
For error states, confirm three things: the background describes a real project pressure, the goal names the intended behavior, and the result points to something visible in the files or browser. If one of those three pieces is missing, rewrite the note before publishing.
Field Note 8: data contract reuse
Background
The same renderer supports Data, ML, Networking, Cloud Operations, FSI, Generative AI, and AI Development practice sets.
Goal
Protect reuse by keeping every bank aligned to the same fields.
Prompt
Follow aws_certified_data_exam_questions.json as template.
Result
New banks became content additions rather than code additions.
Tips
- Use a golden sample.
- Check answer and explanations fields.
- Keep chapter arrays consistent.
- Avoid per-exam UI branches.
- Count questions after import.
Evidence from the demo
New banks became content additions rather than code additions. This is the part a reviewer can check directly. The field note should stay connected to that evidence instead of drifting into generic advice about vibe coding.
Review check
For data contract reuse, confirm three things: the background describes a real project pressure, the goal names the intended behavior, and the result points to something visible in the files or browser. If one of those three pieces is missing, rewrite the note before publishing.
Field Note 9: result reset
Background
If a learner moves to a new question after submitting, stale feedback can confuse the next answer.
Goal
Clear result state whenever navigation changes.
Prompt
Next should go to next question and show the new question cleanly.
Result
The player hides and clears the result box when moving between questions.
Tips
- Reset on next.
- Reset on question-button click.
- Keep answers unselected after render.
- Avoid carrying old correctness text.
- Make state transitions obvious.
Evidence from the demo
The player hides and clears the result box when moving between questions. This is the part a reviewer can check directly. The field note should stay connected to that evidence instead of drifting into generic advice about vibe coding.
Review check
For result reset, confirm three things: the background describes a real project pressure, the goal names the intended behavior, and the result points to something visible in the files or browser. If one of those three pieces is missing, rewrite the note before publishing.
Field Note 10: next behavior
Background
A practice room needs a fast path through questions without forcing users back to the list.
Goal
Advance within a chapter, then move to the first question of the next chapter.
Prompt
Next: go to next question.
Result
The goNext function increments the question index or advances chapter index when the current chapter ends.
Tips
- Disable next on the final question.
- Update the query string.
- Reset feedback.
- Render after state changes.
- Test chapter boundaries.
Evidence from the demo
The goNext function increments the question index or advances chapter index when the current chapter ends. This is the part a reviewer can check directly. The field note should stay connected to that evidence instead of drifting into generic advice about vibe coding.
Review check
For next behavior, confirm three things: the background describes a real project pressure, the goal names the intended behavior, and the result points to something visible in the files or browser. If one of those three pieces is missing, rewrite the note before publishing.
Field Note 11: desktop layout
Background
The desktop prompt separated navigation from answering: left for questions, right for the active item.
Goal
Use screen width to reduce cognitive switching for desktop learners.
Prompt
Desktop page layout: left list of questions button area; right question and answer select area.
Result
The page grid gives a stable sidebar and a larger content panel.
Tips
- Make the sidebar scrollable.
- Keep content panel focused.
- Avoid modal navigation.
- Use predictable columns.
- Increase desktop text size.
Evidence from the demo
The page grid gives a stable sidebar and a larger content panel. This is the part a reviewer can check directly. The field note should stay connected to that evidence instead of drifting into generic advice about vibe coding.
Review check
For desktop layout, confirm three things: the background describes a real project pressure, the goal names the intended behavior, and the result points to something visible in the files or browser. If one of those three pieces is missing, rewrite the note before publishing.
Field Note 12: mobile layout
Background
On mobile, a sidebar-first layout would force learners past navigation before seeing the question.
Goal
Reorder the page so the current question appears first.
Prompt
Mobile page layout: top question and answer select area, down list of questions button area.
Result
CSS order rules put the right panel above the left panel on smaller screens.
Tips
- Put the task first.
- Move navigation below.
- Increase spacing.
- Keep buttons large.
- Test with long questions.
Evidence from the demo
CSS order rules put the right panel above the left panel on smaller screens. This is the part a reviewer can check directly. The field note should stay connected to that evidence instead of drifting into generic advice about vibe coding.
Review check
For mobile layout, confirm three things: the background describes a real project pressure, the goal names the intended behavior, and the result points to something visible in the files or browser. If one of those three pieces is missing, rewrite the note before publishing.
Field Note 13: question button sizing
Background
Tiny numbered buttons are frustrating on phones, especially when a bank has many questions.
Goal
Improve tap accuracy for mobile review sessions.
Prompt
Mobile version: list of question button larger button size.
Result
The mobile media query increases question button width, height, padding, and font size.
Tips
- Design for thumbs.
- Avoid dense tap targets.
- Keep numbers legible.
- Use wrapping rows.
- Preserve current highlight.
Evidence from the demo
The mobile media query increases question button width, height, padding, and font size. This is the part a reviewer can check directly. The field note should stay connected to that evidence instead of drifting into generic advice about vibe coding.
Review check
For question button sizing, confirm three things: the background describes a real project pressure, the goal names the intended behavior, and the result points to something visible in the files or browser. If one of those three pieces is missing, rewrite the note before publishing.
Field Note 14: submit and next sizing
Background
Submit and next are the core interaction buttons. If they feel small, the whole app feels unfinished.
Goal
Make primary actions comfortable on mobile.
Prompt
Mobile version: submit, next button larger button size.
Result
The action buttons receive larger min-height, padding, and font size on mobile.
Tips
- Prioritize action buttons.
- Use consistent height.
- Avoid cramped rows.
- Make disabled state visible.
- Test one-handed use.
Evidence from the demo
The action buttons receive larger min-height, padding, and font size on mobile. This is the part a reviewer can check directly. The field note should stay connected to that evidence instead of drifting into generic advice about vibe coding.
Review check
For submit and next sizing, confirm three things: the background describes a real project pressure, the goal names the intended behavior, and the result points to something visible in the files or browser. If one of those three pieces is missing, rewrite the note before publishing.
Field Note 15: option rendering
Background
Options need enough spacing for multi-line AWS scenario answers.
Goal
Render each option as a label so clicking text selects the input.
Prompt
Responses are possible answers; options should be similar in length and complexity.
Result
Each option uses a label wrapper with input and text, improving accessibility and click behavior.
Tips
- Wrap input and text together.
- Use option letters.
- Allow long text to wrap.
- Keep gap consistent.
- Avoid tiny radio targets.
Evidence from the demo
Each option uses a label wrapper with input and text, improving accessibility and click behavior. This is the part a reviewer can check directly. The field note should stay connected to that evidence instead of drifting into generic advice about vibe coding.
Review check
For option rendering, confirm three things: the background describes a real project pressure, the goal names the intended behavior, and the result points to something visible in the files or browser. If one of those three pieces is missing, rewrite the note before publishing.
Field Note 16: query update
Background
A learner should be able to share the current question after clicking through the app.
Goal
Keep browser URL synchronized with app state.
Prompt
When user clicks a question, go to related question.
Result
The updateQueryString function writes exam, chapter, and question into the current URL.
Tips
- Update after every navigation.
- Use replaceState for quiet updates.
- Keep exam names extension-free.
- Avoid full reloads.
- Validate shared links.
Evidence from the demo
The updateQueryString function writes exam, chapter, and question into the current URL. This is the part a reviewer can check directly. The field note should stay connected to that evidence instead of drifting into generic advice about vibe coding.
Review check
For query update, confirm three things: the background describes a real project pressure, the goal names the intended behavior, and the result points to something visible in the files or browser. If one of those three pieces is missing, rewrite the note before publishing.
Field Note 17: no framework decision
Background
The app only needs fetch, DOM creation, state, and a few event listeners.
Goal
Avoid a framework until the interaction model demands it.
Prompt
Create a simple dark-mode page without decoration.
Result
The practice room stays readable as one HTML file.
Tips
- Use plain JavaScript for small demos.
- Keep state object tiny.
- Create DOM from data.
- Avoid build steps.
- Refactor only when pain appears.
Evidence from the demo
The practice room stays readable as one HTML file. This is the part a reviewer can check directly. The field note should stay connected to that evidence instead of drifting into generic advice about vibe coding.
Review check
For no framework decision, confirm three things: the background describes a real project pressure, the goal names the intended behavior, and the result points to something visible in the files or browser. If one of those three pieces is missing, rewrite the note before publishing.
Field Note 18: content quality gate
Background
The question guide says distractors must be plausible and rationales must prove the key.
Goal
Make content review part of the engineering workflow.
Prompt
Follow question guide and upgrade practice sets to professional level.
Result
The JSON structure preserves option-level explanations that can be audited later.
Tips
- Review distractors.
- Check key uniqueness.
- Avoid obsolete facts.
- Use active voice.
- Keep rationales current.
Evidence from the demo
The JSON structure preserves option-level explanations that can be audited later. This is the part a reviewer can check directly. The field note should stay connected to that evidence instead of drifting into generic advice about vibe coding.
Review check
For content quality gate, confirm three things: the background describes a real project pressure, the goal names the intended behavior, and the result points to something visible in the files or browser. If one of those three pieces is missing, rewrite the note before publishing.
Field Note 19: public link testing
Background
Every landing-page card depends on a matching practice-room URL.
Goal
Treat each card as a test case for the player.
Prompt
Add exam card with link exam_name&chapter=1&question=1.
Result
The library became a set of ready-made deep links into the app.
Tips
- Click every new card.
- Check JSON filename spelling.
- Check first chapter number.
- Check first question number.
- Confirm title loads.
Evidence from the demo
The library became a set of ready-made deep links into the app. This is the part a reviewer can check directly. The field note should stay connected to that evidence instead of drifting into generic advice about vibe coding.
Review check
For public link testing, confirm three things: the background describes a real project pressure, the goal names the intended behavior, and the result points to something visible in the files or browser. If one of those three pieces is missing, rewrite the note before publishing.
Field Note 20: learning loop ownership
Background
The practice player owns learning behavior; the landing page owns discovery.
Goal
Keep responsibilities separated so changes stay simple.
Prompt
Use index.html for catalog and practice-room.html for questions.
Result
The system can grow the catalog without touching answer checking, and improve the player without rewriting marketing copy.
Tips
- Separate discovery from practice.
- Keep content in JSON.
- Use links as boundaries.
- Avoid cross-file coupling.
- Document who owns each behavior.
Evidence from the demo
The system can grow the catalog without touching answer checking, and improve the player without rewriting marketing copy. This is the part a reviewer can check directly. The field note should stay connected to that evidence instead of drifting into generic advice about vibe coding.
Review check
For learning loop ownership, confirm three things: the background describes a real project pressure, the goal names the intended behavior, and the result points to something visible in the files or browser. If one of those three pieces is missing, rewrite the note before publishing.