AI Collaboration Report – Iteration 2 - snuhcs-course/swpp-2026-project-team-14 GitHub Wiki

AI Collaboration Report – Iteration 2

Document Revision History

Version Date Author Changes
0.1 2026-10-16 Hyeon U Jeong Created the Iteration 2 report for login, account-scoped storage, guest imports, My Profile and onboarding, with prompt revisions, observed errors and human decisions.

1. Where AI Was Used

I used Codex (OpenAI) to develop the login feature across the existing Android app and Django backend, then revise it after testing the connected phone. The work began with requirements on October 14 and continued through implementation, review and documentation on October 16, 2026. This report covers my contribution as Hyeon U Jeong.

The feature was merged into develop through PR #26, squash commit e21d6a4. Codex could inspect/edit the repository, run checks, build/install the app and operate the connected Android device. Image generation was used for approved concept images and onboarding artwork. Body and garment analysis reused the existing implementation.

Area Files / responsibility Evidence
Requirements and design docs/login/README.md, approved concepts, feature instructions 2b9accb; L01–L02, L04, L06–L08
Authentication, ownership and request validation backend/apps/users/; owner foreign keys in apps/wardrobe/models.py and apps/outfits/models.py 81ca2f5; L10
Device persistence and identity separation data/LocalUserStore.kt, BodyProfileStore.kt, ui/StyleMateApp.kt 1373c3a, 7715550; L04, L12
Login UI, encrypted sessions and My Profile data/AuthRepository.kt, AuthSessionStore.kt, ui/profile/AuthScreens.kt, AuthViewModel.kt, MyProfileScreen.kt 1271c3c, 7715550; L02, L15
Explicit guest imports backend/apps/users/imports.py, data/GuestImportRepository.kt, ui/profile/GuestImportViewModel.kt, GuestImportDialog.kt a225c60; L17–L18
Eight-step onboarding and preference drafts ui/profile/OnboardingScreen.kt, BodyProfileViewModel.kt, existing wardrobe editor and local store ea4bbb4, 490fcab; L21–L22, L26–L28
Integration review and documentation Account pagination, outfit/garment integrity, input bounds, tests and Wiki requirements/design aad9b75, Wiki revision

Android paths beginning with data/ or ui/ are relative to frontend/app/src/main/java/com/swpp/stylemate/. Prompt IDs in Iteration 2 – Prompt Log retain their original numbering after selection.

I retained the decisions about required information, account/guest behavior, feature boundaries and acceptable UI. For example, I excluded social login and password recovery, permitted a one-time cleanup of legacy unowned data, rejected unnecessary legacy compatibility layers, and chose manual import instead of a popup at every login. Codex implemented these decisions and prepared changes for my review.

2. Prompt History

The linked Iteration 2 – Prompt Log contains 16 selected requests. The Korean prompts are edited summaries of actual messages, with spelling and informal wording normalized; they are not verbatim quotations. Dates and times come from the session record in KST. Outcomes summarize the resulting work and can include follow-up turns.

Date · KST Stage Edited prompt
10-16 03:08 · L04 Storage boundary 기존 로컬 저장과 신규 DB가 충돌하면 신규 구현을 우선해주세요. 기존 DB 호환성만을 위해 불필요한 파일이나 이중 저장 구조를 추가하지 마세요.
10-16 05:25 · L15 Device-discovered bug 비밀번호 확인 오류를 고친 뒤 가입하면 로그인 응답을 읽지 못한다고 나옵니다. 다시 가입하면 이미 존재하는 아이디라고 하고 로그인도 되지 않습니다. 원인을 확인하고 수정해주세요.
10-16 06:20 · L17 Import behavior 로그인할 때 가져오기 창을 자동으로 띄우지 말고, 로그인한 뒤 사용자가 필요할 때 직접 눌러 가져오도록 바꿔주세요.

3. What AI Did Well

Case Evidence Effect
Connected authentication to the data lifecycle. User, hashed expiring tokens, required garment/outfit owners, AccountAccess, encrypted session storage; 81ca2f5, 7715550 The work covered startup restoration, logout, expiration, old-session responses and account switching, rather than stopping at login forms.
Reused existing storage and feature flows. LocalUserStore, the existing OutfitItem relation, body analysis and garment editor; 1373c3a, ea4bbb4 Guests could save locally and complete optional onboarding without a second app, backend or legacy compatibility store.
Implemented recovery around explicit imports. Account-specific UUID mapping, conflict/version checks and local receipts; a225c60 The user chooses replacements, guest originals remain, and retries can resume unfinished work without duplicating confirmed records.
Converted review findings into regression checks. Datetime-response tests, bounded pagination, invalid UUID handling and category-change restrictions; 7715550, aad9b75 Concrete failures received targeted corrections, including requests that otherwise failed at integration boundaries.

The final feature record reports 111 Django tests, 142 pytest tests and 108 Android unit tests, Android builds/lint and device flows, with GitHub CI passing for feature head 490fcab. These are suite totals, not counts of tests newly added by this feature. Lint still had 23 existing warnings. A local onboarding persistence test failed once, then passed in isolation and on the full rerun without a code change. These checks do not establish a complete security audit or live MySQL concurrency validation; new body/garment AI accuracy and real AR capture were also outside these checks. See the merged validation record.

4. Hallucinations / Errors

The main recorded problems were integration failures and UI mismatches. The following distinguishes observed defects from later changes to my requirements.

What the AI produced or missed Why it mattered How it was caught Correction / cost
The app rejected Django's successful authentication response. The expiry parser used Instant.parse for a timestamp containing +00:00. Registration could create the account on the server while the app reported failure. Retrying registration then found a taken ID. I reported the mismatch/registration/login sequence on the phone (L15). Switched to offset-aware parsing and added tests using the actual Django response format, including correction after a password-confirmation error; 7715550. Existing response tests had not caught this contract mismatch.
Initial account data paths had incomplete bounds and pagination/integrity handling. Larger responses could exceed the app limit; editing a page-boundary item could duplicate or break the next page; a category change could invalidate an outfit link. I requested a codebase review and a second review, then limited corrections to login-related integration. Added bounded pages with stable cursor boundaries, matching request limits, ownership/category checks and regression tests; aad9b75. This required another review/fix cycle after the initial flow worked.
Some concept/implementation choices did not match the interaction I wanted. Headers/skip actions were inconsistent, the fit step initially selected regular, and Step 6's count display was too crowded. Passing functional checks did not make the screen acceptable. I compared the concepts and tried the phone screens (L22, L26–L28). Unified the header and upper-right skip, allowed an empty fit draft with regular applied on continue, and used three equal-width count columns with visual dividers; ea4bbb4, 490fcab.

Moving import to an explicit user action was a product-policy refinement (L17), not evidence that AI ignored an already fixed requirement. No measured time-saving or productivity percentage was recorded.

5. Prompt Revisions

1. Make the import trigger explicit

Edited prompt Result
Before (10-16 03:17 · L06) 기존 데이터는 보존할 필요가 없습니다. 로컬 데이터를 가져오고, 계정과 겹치면 교체 여부를 확인하도록 해주세요. Defined import/conflict behavior, but did not settle the final trigger and placement.
After (10-16 06:20 · L17) 로그인할 때 가져오기 창을 자동으로 띄우지 말고, 로그인한 뒤 사용자가 필요할 때 직접 눌러 가져오도록 바꿔주세요. Login stopped initiating the dialog. Later prompts placed the import icon beside the My Profile title; confirmation precedes upload.

Why it worked: the follow-up separated authentication from a potentially surprising upload and specified who starts it, including use on another phone.

2. Define the fit-selection behavior precisely

Edited prompt Result
Before (10-16 03:23 · L07) 8페이지 온보딩을 로컬 저장에 연결하고 로그인은 선택 사항으로 해주세요. Established the setup flow, while the exact initial fit-selection behavior remained to be refined.
After (10-16 07:29 · L22) Step 2는 처음부터 레귤러를 강제 선택하지 말고 자유롭게 선택하게 하되, 아무것도 고르지 않고 다음을 누르면 레귤러를 적용해주세요. An empty fit draft could be restored; regular was applied on continue rather than shown as a forced initial selection.

Why it worked: the follow-up distinguished an empty editable draft from the default value saved when continuing.

6. Manual Fixes and Why

Implementation corrections in this recorded workflow were made through Codex follow-up prompts. My contributions were product decisions, device feedback and approval of the changes; the record does not establish separate hand-edited fixes by me.

What I did Why it needed my input
Defined ID/password-only accounts, minimum user data, no recovery flow and optional login These decisions set the product scope rather than following automatically from the framework.
Set the data transition policy I allowed cleanup of legacy unowned data while requiring new user data to be preserved, and rejected unnecessary compatibility layers.
Chose manual import and conflict replacement rules The acceptable cross-device experience and overwrite policy needed an explicit user decision.
Tried the registration/onboarding screens and reported failures The successful-server/failed-app registration case and visual layout problems became clear during actual use.
Supplied references, chose the common theme and specified exact UI corrections Automated tests could check selection or navigation, but could not decide that the card was too tall or the count row was visually crowded.
Unlocked the phone, authorized test-data resets, and reviewed publication Device access, destructive resets of disposable data, and commit/merge/Wiki publication were explicit human decisions.

Next Iteration

Test the real response contract early, agree on guest/account and import rules before polishing screens, and include large lists, interrupted requests and account changes in integration checks. Keep implementation status and review scope explicit in shared documentation. See Iteration 2 – Prompt Log for the selected requests and outcomes.