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.