Read the original meeting minutes from meeting-notes-raw.md, remove unnecessary conversation context and context between speakers, and write information about service users, functional requirements, system policies, and undecided reservations in the form of a compact, unstructured summary memo of about 15 lines. Please do not arbitrarily add fictitious content that is not in the original text.

Compare and analyze the three documents ‘meeting-notes.md’, ‘requirements.md’, and ‘screen-specification.md’ in the project folder. Find and organize items that are contradictory or inconsistent between each document, or items that exist in one document but are missing from the other. Organize the results in the form of a Markdown table with the following columns: 'Classification (function/screen/policy/terminology, etc.)', 'Findings and contradictions', 'Impact level (high/medium/low)', 'Highest authority standard document', and 'Recommended action'. When entering development and testing, indicate the impact as 'high' for matters that cause fatal rework.

Compare changes in requirements-before.md and requirements-after.md. After that, analyze which part of the 'screen-specification-v2.md' and 'api-specification.md' documents, which remain at the v1.0 level, and output them in the form of a Markdown table with columns 'Change Items', 'Before Change', 'After Change', 'Scope of Impact (Screen/API)', 'Importance', and 'Actions (Specific Modification Guide)'.

Read the 'messenger-chat.md' conversation log in the project folder, and fill out the Decision Log (decision items, content, background, decision date, person in charge, status) and Pending Items (pending items, follow-up actions, person in charge, scheduled due date) tables for project management and tracking. Please do not make up fictitious data that is not in the chat log.

Analyze the provided meeting minutes from a data structure perspective to derive key entities and relationships, and write a data structure definition and Mermaid ERD code. Don't make up random entities, but write them based on the provided meeting minutes text facts.

Analyze all terms such as 'Member/User/Customer/Member' and 'Counselor/Expert/Teacher/Counselor' that are used interchangeably throughout the project, and create a dictionary of project standard terms in the form of a Markdown table, including standard Korean names, standard English names, data types, usage definitions, existing mixed words, and recommended DB column names.

As the reservation confirmation process is changed to 'waiting for approval' status and changed to 'payment after expert approval', please fill out the affected API specifications, DB schema, screen, and change sharing report in the form of a table with the impact area, change details, risk level, and action target document columns.

Extract normalization and database structure design decisions from the meeting and create a Design Decision Log that includes decision items, background reasons, alternative reviews, approvers, and possible future changes.

Derive data consistency violation edge case exception scenarios that may occur in the currently defined User, Expert, Reservation, and Payment table structures and suggest improvement measures. (Must include simultaneous payment errors, foreign key reference collapse upon membership withdrawal, etc.)

Based on the provided requirements definition and screen definition, derive a list of required APIs and create a standard API contract by defining the types of Request and Response fields and English variable names.

Cross-check the provided day4_requirements.md, day4_screen_definition.md, and day4_api_specification_v1.md files to find API endpoints and fields that are inconsistent or missing from planning requirements or screen UI design, and create a review report. (Please detect missing expert rating star_rating and absence of reservation approval API)

Analyze the contents of the provided API change request (day4_api_change_request.md) to derive a list of other system areas and documents affected when modifying the reservation request API, and prepare an API impact analysis report that can be immediately shared with team members.

Review the provided API specification of day4_api_specification_v1.md, analyze improvements based on REST API design standards (HTTP Method usage, URL naming), consistent error handling structure, and extensibility, and write an API review report. (Includes improvement plan for applying RFC 7807 standard error schema)

Based on the currently defined reservation and payment API specifications, create an API test scenario and verification checklist that includes both the normal registration flow (Happy Path) and exception cases such as missing required parameters, date format errors, limit exceeded, and permission expiration.

Based on the screen specifications of the provided reservation application details form, review whether the information structure is clear from the perspective of a novice user who is new to the service, point out elements that impede usability, and write a UX Review Report in the form of a column table with review areas, impediments, user impact, and improvement plans.

Compare the design details of each screen in the provided day5_signup_flow.md, analyze elements that lack consistency in button placement rules, terms used, and feedback messages, and create a screen comparison report. (Including confusion over ID vs. customer ID name and contrast of main button full width)

Analyze the reservation detailed scenario flow of the provided day5_signup_flow.md and prepare a user journey improvement report (User Journey Report) that includes the AS-IS flow (9 steps) and TO-BE improvement flow (approximately 4 steps) that can minimize the click steps and screen movement until the user completes the consultation reservation.

You are a self-employed person in your 50s who is somewhat unfamiliar with using digital smartphone apps. While looking at the membership registration and first screen UI specifications written in the provided day5_signup_flow.md specification, please write down your emotional reaction and improvement requirements about what is most confusing and difficult when signing up from your perspective. (Including confusion over ID duplication, reduced visibility in font size, and anger at resetting the format of written content in the event of a password validity error)

Based on the provided day5_signup_flow.md specification, score out of 5 for each item such as 1) information readability, 2) operation accessibility, 3) error resilience, and 4) movement efficiency, and build a service quality evaluation (Usability Evaluation) that points out strengths and painful areas of improvement along with a comprehensive evaluation score.

Based on the layout specifications provided, please create a draft HTML markup and CSS grid style for a responsive dashboard screen where reservation status can be viewed. Please suggest an initial project structure, including a left navigation bar and waiting/approved/completed card components to indicate booking status.

The error 'TypeError: Cannot read properties of undefined (reading 'map')' occurred in the code you wrote. Please compare the provided source code day6_debug_source.js with the console error log to explain why the error occurred from a beginner's perspective, and provide a modified source with defense code that can completely control the error.

Please analyze the source of the provided day6_dirty_code.js file and refactor it into an improved version of clean code by 1) separating the duplicate markup binding logic into a common utility function, 2) correcting ambiguous variable names (ex: a, temp, fn) with practical words, and 3) writing appropriate one-line comments to facilitate future maintenance.

We are trying to connect a JavaScript feature to the sign-up screen code in day7_unconnected_feature.html provided. Please write an integration script that 1) checks the validity of input values ​​when the sign-up complete button is clicked, 2) saves the information in the browser's local storage, and 3) moves to the dashboard screen when successful. Please also suggest missing cancellation button response or duplicate subscription check logic.

By analyzing the step-by-step call sequence of the provided day7_user_flow.md specification (Sign up ➔ Expert search ➔ Detailed reservation ➔ Virtual payment), diagnose the two core sections where information loss is most likely to occur when a user takes this route, and suggest a state preservation logic structure as an alternative code to prevent this. (maintaining SessionStorage filters, etc.)

Please review the reservation request logic in the provided day7_feature_validation.js file. Please suggest a final verification code that detects 1) the vulnerability of duplicate reservation requests (button pressing) and 2) the possibility of application errors in the past of the reservation date, and adds the disabled state processing and date validity period check to prevent these.

Based on the provided service overview (day8_service_intro.md), brainstorm a list of membership management features you need in your booking platform. Please organize the list by dividing it into 1) essential basic functions and 2) optional extended functions, and return the priority implementation checklist in table form to check development progress.

By analyzing the provided membership sign-up specification day8_signup_spec.md, please point out three usability impediments that regular users signing up for the first time will encounter. Also, please suggest an improvement report (User Flow Report) to reduce the number of input forms and prevent password resets in case of errors.

Please audit the provided day8_user_service.js membership registration and login script to identify defects such as 1) risk of missing duplicate registration checks, 2) immediate discarding of existing passwords when password is lost, and suggest a final JavaScript improvement with reinforced effective guards to increase service stability. (Includes login error failure message integration and supplementation)

Read the current multi-step checkout flow (day9_current_checkout_flow.md) and find two barriers that may cause users to run away due to fatigue before clicking checkout. Also, please derive an improved payment user flow (TO-BE Flow) that is reduced to 3 steps or less by merging unnecessary steps so that email sign-up users can complete the purchase as quickly as possible.

Based on the PG company's raw error log specification day9_raw_payment_errors.json provided, please create a friendly 'Korean guidance phrasebook for each error situation' that never causes anxiety to users and a 'double authorization prevention response guideline (Mitigation Playbook)' that blocks duplicate payment attempts.

Please review the usability and reliability of the provided day9_payment_ui.html payment UI layout. Find a place where users may feel anxious due to information opacity, and derive a final CSS/HTML structure supplemented with 1) separate display of price details and discount receipts, 2) placement of 24-hour secure payment security phrase, and 3) simple cancellation/refund link prescription.

Please write a service introduction so that users who use our service for the first time can understand our core values ​​within 5 seconds. Please include the service name, three core functions, target users, and differences. Also, create a banner at the top of the homepage and an email newsletter opening notice. Please write the terms and conditions easily instead of using legal terms.

Create the 20 most common questions asked by first-time users of this service in FAQ format. Divide into five categories: membership registration, service use, payment, error resolution, and other. Also, please write a customer response script for complaints that are not activated if there is a 10-minute delay after payment.

Based on the project progress and results, write a project results report that can be delivered to investors and stakeholders. Include sections for background, goals, key features, accomplishments, and areas for improvement. Also, write a Keep/Problem/Try retrospective and a MoSCoW (Must/Should/Could/Won't) roadmap.