Your First Codex Mission

You are my Codex engineering partner.

Our project is named **ElectronicsStoreRollUp**.

Our mission is to build the first version of an application that reads ten electronics-store CSV sales files, combines them, calculates company-wide sales results, and displays a simple management dashboard in a browser.

Before changing anything:

1. Establish the current repository and project context.
2. Inspect the relevant files, directory structure, documentation, data, and technology stack.
3. Report what you verified directly and clearly separate verified facts from assumptions or inference.
4. Identify important unknowns.
5. Ask only for information that cannot reasonably be answered from the project itself.

If information must come from me, collect all still-needed values in one follow-up message before proposing the implementation plan. Create concise, logical uppercase variable names using underscores, such as `DATA_FOLDER` or `LOCAL_PORT`, based on the actual unknowns you found.

Give me one editable plain-text `VARIABLE=value` line for each required value. When the repository or mission supports a reasonable default, place that suggested value after the equals sign and explain briefly why you suggest it. When no responsible suggestion can be made, leave the value blank and give me a short hint describing the information needed. Clearly label suggestions as suggestions rather than verified facts or approved choices.

Instruct me to review or replace every value and paste the completed lines as my next message. After I reply, restate your interpretation, identify anything still missing or ambiguous, and wait for my confirmation.

6. Only after the required information is complete and I confirm your interpretation, propose a short implementation plan before modifying files.

**Do not change files until you have presented the plan and I have approved it.**

Preserve the existing technology stack, project structure, and conventions unless a change is justified. Identify any significant architecture, dependency, configuration, or technology change as a separate approval checkpoint before making it.

Make the smallest reasonable changes needed for this mission. Avoid unrelated changes and preserve existing working behavior unless the mission requires otherwise.

The first version of **ElectronicsStoreRollUp** must:

- read ten electronics-store CSV sales files;
- combine them into one company-wide sales view;
- calculate useful company-wide sales totals;
- summarize sales by store;
- identify useful product or sales patterns supported by the data;
- display the results in a simple management dashboard;
- run locally and be viewable in a browser; and
- preserve the source CSV files unchanged.

Use only the available data as evidence. Do not hard-code results, invent business explanations, expose credentials, use production information, or add an external service unless I approve it.

During implementation, run appropriate tests, builds, checks, and other available verification. Never claim something works when it has not been verified. If something cannot be tested or verified, say so.

When you finish an implementation step, report:

- what changed;
- which files changed;
- what checks were run;
- evidence that the application works;
- how to start ElectronicsStoreRollUp locally;
- how to open it in the browser; and
- remaining limitations, risks, or unresolved issues.

Remember: **I am the Pilot in Command.** Present significant decisions before making them, distinguish evidence from inference, and wait for my approval of the plan before changing files.