## 오류 분석
### 문제
ClientList.razor Line 96-108에서 Razor 코드 블록 내에서
MudChip 마크업을 직접 렌더링하려고 함.
### 원인
Razor 코드 블록 (@{ ... })은 C# 코드만 실행하고,
HTML 마크업은 블록 밖에서만 렌더링 가능.
### 해결
코드 블록을 변수 선언만 하도록 제한하고,
MudChip 마크업을 블록 밖으로 이동.
### 영향
- ClientList.razor: 상태 칩 렌더링 정상화
- 런타임 오류 제거
- 빌드: 0 오류, 0 경고
## 검증
✅ 빌드 성공
✅ 모든 컴포넌트 정상
✅ E2E 준비 완료
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
## 변경사항
- Program.cs: app.UsePathBase('/taxbaik') 제거
- Blazor 컴포넌트: /taxbaik/admin/* → ./* 상대 경로로 변경
- 모든 내부 링크 절대 경로 → 상대 경로로 전환
## 현황
✅ 빌드: 0 오류, 0 경고
✅ 헬스체크: HTTP 200
✅ 로그인 페이지: 로드 정상
❌ 로그인 API: 400 오류 (DB 오류 - 조사 중)
## 다음 단계
- LoginEndpoint에서 발생하는 DB 오류 원인 파악 필요
- Razor Pages 절대 경로도 상대 경로로 변경 (보류 중)
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
All Page components now use:
@rendermode @(new InteractiveWebAssemblyRenderMode(prerender: true))
Attempted solution based on observation that Login.razor (prerender: true)
works correctly while Dashboard.razor (prerender: false) fails WASM init.
Result: blazor.boot.json still not generated, WASM bootstrap still fails.
Indicates deeper SDK issue with ASP.NET Core 10 Preview Blazor WASM
initialization mechanism, not fixable by render mode configuration alone.
Changed files:
- All 30+ admin Page components: prerender: false → true
- Program.cs: MapRazorComponents added (required for WASM)
Status: WASM bootstrap blocked at fundamental SDK level.
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
- Restore admin/index.html to working state (relative script paths)
- Ensure MapRazorComponents + MapFallbackToFile combination
- Fix admin page routes to use relative paths (without /admin prefix)
- Add password reset API endpoint for admin account management
- Verify WASM bootstrap and login form rendering works correctly
- All admin pages now properly routed through WASM rendering pipeline
Server verification:
✅ HTML renders with login form correctly
✅ blazor.webassembly.js loads successfully
✅ admin-session.js binds form events
✅ No server-side errors in logs
Note: Client-side caching may require browser refresh (Ctrl+Shift+Delete)
to see latest WASM updates.
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
BREAKING CHANGE: Removed TaxBaik.Web.Client project (separate WASM app)
Changes:
- Migrated all Blazor components to TaxBaik.Web/Components/Admin
- Migrated all Browser Client services to Components/Admin/Services
- Updated Program.cs to use integrated components (same assembly)
- Removed AddAdditionalAssemblies (no longer needed)
- Updated _Imports.razor with correct namespaces
Architecture:
✅ API-First: REST endpoints in TaxBaik.Web (ASP.NET Core)
✅ Client-Side: Blazor WASM components in TaxBaik.Web/Components
✅ Unified: Both API and UI served from single web server
✅ No separation: No separate client project
Result:
- Single deploy unit (TaxBaik.Web)
- API served only from web server
- Blazor renders client-side (prerender: false for protected pages)
- Monolithic web app architecture
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
Symptoms: After login, admin pages showed loading spinner forever. Root cause:
OnInitializedAsync in 11 admin pages (Dashboard, Blog, Inquiries, Clients,
Announcements, FAQs, TaxProfiles, ConsultingActivities, TaxFilingSchedules,
Contracts, RevenueTrackings) checked AuthStateTask and loaded data only if
authState.User.Identity?.IsAuthenticated == true. If that condition was ever
false (e.g., transient auth state resolution timing), the page never reset
its data collection from null → []. AdminDataPanel uses "Loading={item == null}"
as its loading predicate, so null persisted indefinitely.
Fix: Always reset the data collection, whether the auth check passes or fails:
- AuthStateTask != null && IsAuthenticated == true: load data (existing)
- AuthStateTask != null && IsAuthenticated == false: set data = [] (new else)
- AuthStateTask == null: set data = [] (new else)
This ensures AdminDataPanel's "Loading" condition becomes false on all code
paths, not just the success case.
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
Groups the repo root into src (buildable source), docs (already existed),
and everything else (db/, scripts/, tests/, deploy/ - deployment/ops/test
assets that aren't compiled, already organized as their own folders). CI
now only needs src/ to build: dotnet restore/build/test/publish all point
at src/TaxBaik.sln, src/TaxBaik.Web/, src/TaxBaik.Proxy/.
- git mv every project (Domain, Infrastructure, Application,
Application.Tests, Web, Web.Client, Proxy) and TaxBaik.sln into src/ as a
unit, so relative ProjectReference/.sln paths stay valid unchanged.
- .gitea/workflows/deploy.yml: 6 dotnet restore/clean/build/test/publish
invocations now point at src/. db/migrations and scripts/ stay at root
(deploy_gb.sh and browser-e2e.yml only touch published output and the
deployed URL, not source paths - verified, no changes needed there).
- scripts/validate_admin_render.sh: admin render-mode file paths now
src/TaxBaik.Web.Client/...
- scripts/validate_kst_timestamps.sh: dropped deploy.sh from its target
list - that script was removed in the prior cleanup commit (dead, no
CI workflow referenced it) but this validator still expected it to exist.
- CLAUDE.md, docs/ENGINEERING_HARNESS.md, docs/ADMIN_PATTERN_CRITIQUE_WBS.md:
updated project-structure diagram, dotnet run/build commands, and grep
targets to the new src/ paths (also fixed a pre-existing stale path in
ADMIN_PATTERN_CRITIQUE_WBS.md that still said TaxBaik.Web/Components/Admin
from before that ever moved to TaxBaik.Web.Client).
- Added a Repo Root harness rule + Architecture Guardrail entries: new files
belong under src/docs/tests/scripts/db/deploy, not loose at root; temp
work stays outside the repo (or under a gitignored .scratch/) and is
never committed.
Verified locally: dotnet build/test src/TaxBaik.sln (26/26 tests), and all
three scripts/validate_*.sh pass against the new layout.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
kjh2064