[태그:] Project documentation

Imagine adding a “Low stock only” filter to an inventory app you built with an AI yesterday. If you give a fresh session the project folder, can it find the startup instructions, understand the data, and make the change without breaking the existing save feature?

Materials and checking tools were prepared for a comparison, but no measured AI continuation run took place (NOT RUN). Several prerequisites remained open: checking isolation—whether the AI could access earlier records, memories, or files outside the supplied materials—and confirming usage allowance and a route without extra charges. The October 26 record says Claude’s command-line tool (the Claude CLI) was logged out; login status was not rechecked for this manuscript. On November 5, 2026, the coordinator changed the scope to an article about the method. The answer is still unknown. This article explains what to record and check, how the comparison was designed, what preparation established, and why measurement stopped.

A comparison design stopped before measurement, with proposed checks—not performance results.

What should travel with the project?

GitHub's README guidance recommends including information needed to get started with a project. AGENTS.md is a convention for agent-facing instructions, including build and test guidance. Neither establishes that documentation improved performance on this app. These descriptions rely on public documentation checked on October 8, 2026. GitHub README guidance, AGENTS.md guidance

The untested suggestion is to leave short notes on how to start the app, what the data means, what behavior to check, and known limits, then add the current request and a check date. These six lines are neither a proven minimum nor a tested template. They are a reader aid, distinct from the four P documents described below, and were not an input to any planned cell. README and AGENTS.md conventions themselves were not the intervention either.

Startup: which folder and command? What should a working screen show?
Data: where is it stored? What do the fields and calculations mean?
Checks: which actions and expected results should be re-checked before and after changes?
Limits: what uses have been checked, and what remains unverified?
This request: what should change, and what must stay the same?
Checked on: when were these notes compared with the actual files and behavior?

There is no need to copy the whole old conversation. Keep passwords, secrets, and old chat exports out of the folder and notes you hand over. We suggest comparing documented commands and rules with the actual files and marking unknowns explicitly. The effect of outdated notes was outside the planned comparison.

A new conversation does not necessarily exclude earlier information. As of the research date (October 8, 2026), Claude's documentation described routes for loading project instructions and automatic memory. Separately from that documentation description, this design required checking access to files and saved information in the actual environment instead of treating a folder or session name as proof of isolation. Claude memory documentation

The planned comparison: the same app, with and without explanatory files

Using synthetic data only, the prepared materials are two variants of a local, single-user inventory app. A represents studio supplies (Korean label “작업실 물품”); B represents workshop parts (“공방 부품”). Each contains 12 fictional items. Labels and field names differ, but quantities and rules match. In both, an item is low on stock only when physical stock minus reserved stock is strictly below its threshold. An item exactly at its threshold is not low on stock, and inactive items are excluded.

P's files are START-HERE.md, DATA-DICTIONARY.md, ACCEPTANCE.md, and KNOWN-LIMITS.md. They were designed as ordinary documents for the AI to open instead of automatic instructions. Actual loading behavior remained a question for the unrun preliminary trial. Both conditions receive the same change request and a command list inside the project files. This is not a comparison of bare code with helpful instructions. P’s notes repeat commands supplied in C and explain rules already present in code. The startup command was to be found in the project files, not supplied in the request itself. Supplying a file also does not establish that the AI read or used it.

The common request, written in English, was to reuse the existing low-stock badge rule in an “All / Low stock only” filter. All must remain the default, and switching back must restore the original items and order. Viewing or filtering must not change the saved data. Stock editing, rejection of invalid inputs, and persistence after restarting must still work. The design also restricts page structure and editable files, so it is not a test of unrestricted app development.

The planned order was A-C → A-P → B-P → B-C: four runs with the same model and settings, each with a fresh session and an unmodified copy of the project. C would come first for A, and P first for B. A would still always precede B, and the variants share a rule; balancing condition order alone would not eliminate carryover or effects of provider-side state. Even a completed set would be a small comparison of two related apps, an English request, and one model. It could not establish performance across AI products, handoff to a person or your future self, or Korean-language instructions. All four runs remain unexecuted.

Check behavior, not just “I understand”

The design calls for checking startup before editing, then checking the new feature separately from existing behavior. Under the amended strict-below rule, the predetermined expected items are 01, 02, 05, 11, and 12 in each variant—not an AI-produced result. To catch a shortcut that merely returns that fixed list, change quantities and check that the list updates and that an item exactly at its threshold stays off it. Compare stored data before and after, and inspect the complete code change.

The AI’s findings were to be recorded in six factual fields: startup command, data location and structure, available-stock calculation, low-stock rule, check command, and usage limits. The first five are explicit in files or inferable from code and tests in both conditions; only P explicitly states the single-user design limit. Reporting a shared command means locating supplied information. A correct answer citing the wrong file would still lack support, but content accuracy and evidence quality would be recorded separately. Actual code or relevant tests can support an answer; a note does not take precedence just because it is prose. Wrong, unknown, and omitted answers are separate categories. C lacks an explicit statement of single-user design intent that P supplies; treating “unknown” in C as automatically wrong would be unfair. These fields should not be simply totaled into a P advantage. If the AI asked no questions, that alone would not show understanding; a justified question would not be a failure either. Fact reporting and functional checks remain separate.

A time comparison would need to record note preparation, safety review, and external verification separately, as well as waiting for AI responses. There are no measurements here from which to calculate task speed or time saved. An AI's completion claim is also separate from passing checks of the screen, storage, and actual changes.

What offline preparation established

The component connecting to the AI tool and the component managing execution and shutdown were checked separately. On October 26, 2026, records from October 17 were inspected, not rerun. Result files showed passes for 23 connection-component tests and 21 execution-management tests, without calling the AI model under test. The app evaluator matched expected pass/fail outcomes in 22 cases. Those include rejecting faulty implementations, so this does not mean “22 successful apps.” The shared files also matched between conditions. That match alone does not establish the accuracy of all four added P documents. This article does not present a complete document-by-document reconciliation result.

Separately, browser records for the original apps and reference implementations prepared in advance were reviewed. The records showed passes for 16 checklist items covering lists, rejected input, saving, restarting, and the reference implementations’ filters. The original apps had no new filter; filter checks applied to the prepared references. This was calibration within the preparation process, not independent performance validation. They are not scores for changes produced by a fresh AI session. The agent checking the prepared materials operated the browser; this was not a human handoff study.

The records have limitations. The coordinator log omitted exit codes—the programs’ termination status—for the connection, execution-management, and app-evaluator steps. Success for the first two was inferred from result files; the evaluator’s separate result file included an exit code. Which traffic came from the browser was partly inferred, without observing all outgoing traffic from the computer. This also prevents a claim that the browser checks had no external traffic. A Python runtime differing from the one previously recorded was accepted only for checks that did not use the AI model, not as approval of the live AI route. These preparation results cannot establish isolation of the live AI route or readiness of the whole experiment.

Why measurement stopped, and what remains open

Before measurement, a small preliminary trial was needed: could the AI read and edit inside its allowed folder, be denied when trying to read a harmless marker file outside it, and complete the command-request, feedback, and shutdown sequence through the actual Claude CLI? Checks using simulated responses cannot validate that live route. Even a passing trial would not prove that all provider-side state or caches had been erased.

The October 26 record reports that the Claude CLI was logged out. The working agents were not permitted to log in or reauthenticate on their own, so the trial was not launched. Evidence of remaining subscription usage and a route without additional charges, live isolation checks, and independent review of their records also remained outstanding then. There was also no outer safeguard to force the entire preliminary-trial program to stop at a time limit. The November 5 decision changed the scope to a methods article without treating this state as a performance result.

It therefore remains unknown whether explanatory files make continuation faster, improve task completion, or outperform the basic project. No difference or interference from the added explanations remain possible too.

Checks to try on your app—an untested suggestion

1. Compare the notes above with the actual app and mark unknowns.
2. Open the app before editing and define the screen, input, and saving behavior to preserve.
3. Check the new feature and existing features separately afterward. In the inventory example, change quantities to check that the list updates and excludes items exactly at the threshold.
4. Inspect changes to stored data and code, and distinguish the AI’s completion claim from actual execution results.

This sequence and the template above are suggestions to try, not methods whose effectiveness this preparation proved.

AI assisted with research and drafting. The author reviewed the final manuscript and directed the revisions.