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>
Architecture:
- Create companies table with company_code as unique identifier
- Add company_id foreign key to admin_users for multi-tenant support
- Implement backward compatibility with DEFAULT company for existing users
Core Components:
- Company entity with full CRUD operations
- ICompanyRepository interface following Repository pattern
- CompanyRepository with Dapper implementation
- CompanyService with business logic and validation
- CompanyController with REST API endpoints
Admin UI:
- CompanyForm reusable component (Create/Edit pattern)
- CompanyList.razor with pagination and company overview
- CompanyCreate.razor for registering new companies
- CompanyEdit.razor for managing existing companies with delete
- All pages follow admin-page-hero pattern for consistency
SOLID Principles:
- Single Responsibility: Each component has one reason to change
- Open/Closed: Extensible without modifying existing code
- Interface Segregation: Clean repository and service contracts
- Dependency Inversion: All layers depend on abstractions
Database Migration (V014):
- Creates companies table with active/inactive status
- Assigns existing admin users to DEFAULT company
- Provides foundation for role-based access control
Future Enhancement:
- Admin users can belong to specific companies
- Data filtering based on company_id (multi-tenant isolation)
- Company-based permission model
Core Components:
- Create reusable InquiryForm.razor component following SOLID principles
- Implement InquiryCreate.razor for registering new inquiries (offline, phone)
- Implement InquiryEdit.razor for modifying existing inquiries with delete
- Add DeleteAsync method to InquiryRepository and InquiryService
- Update InquiryList with 'Create' button and Edit link in table
Architecture:
- InquiryForm: Encapsulates form logic, can be reused for create/edit
- Service Layer: All operations go through InquiryService for cache invalidation
- Repository Pattern: Database operations isolated in InquiryRepository
- UI Consistency: Both pages follow admin-page-hero pattern
Features:
- Admin can create inquiries from phone/offline consultations
- Admin can modify inquiry details (name, phone, email, message, status, memo)
- Admin can delete inquiries with confirmation dialog
- All operations update dashboard cache
- Status validation and error handling throughout
Testing:
- Updated FakeInquiryRepository in tests to implement DeleteAsync
**Architecture Refactor (SOLID Principles):**
- Implement AdminDashboardController (REST API)
- Add dashboard summary endpoint
- Add upcoming filings endpoint
- Add recent inquiries endpoint
- Add monthly statistics endpoint
**Database Layer (Repository Pattern):**
- Extend IInquiryRepository with date range queries
- Implement CountByDateRangeAsync
- Implement CountByStatusAndDateAsync
- Extend InquiryRepository with new methods
**Service Layer (Single Responsibility):**
- Extend AdminDashboardService with API methods
- Add GetRecentInquiriesAsync
- Add GetMonthlyStatsAsync with caching
**Test Coverage:**
- Update FakeInquiryRepository mock with new methods
**SOLID Application:**
✓ Single Responsibility: Each class has one reason to change
✓ Open/Closed: Dashboard API can be extended without modifying existing code
✓ Dependency Inversion: Service depends on Repository abstraction
✓ Interface Segregation: API endpoints are focused and specific
Status: ✓ Compiles successfully (0 errors, 0 warnings)
Next phases:
- Add remaining API controllers (Announcement, Client, FAQ, TaxFiling)
- Refactor Blazor components to use API instead of services
- Implement JWT token refresh mechanism
- Add SignalR for change notifications
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- TaxSeason / CurrentSeasonDto에 RelatedCategorySlug 추가
- TaxSeasonCalendar 각 시즌에 카테고리 슬러그 매핑
(income-tax→income-tax, vat-1st/2nd→vat, 종부세→real-estate-tax 등)
- IBlogPostRepository.GetByCategorySlugAsync 추가
- BlogService.GetSeasonalPostsAsync: 시즌 관련 글 2개 우선 + 나머지 최신 글로 채움
- IndexModel: SeasonalPosts / RecentPosts 분리 로드
- Index.cshtml 블로그 섹션: 시즌 중 "이번 시즌 추천" 배지 + 시즌별 전체보기 버튼
- site.css: blog-card--seasonal, seasonal-blog-tag, btn-seasonal 스타일
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- 연간 세무 캘린더(7개 시즌) 기반 자동 Hero 섹션 전환
- 시즌 감지 시 D-Day 카운트다운, 긴박감 배지, 시즌 CTA 표시
- 서비스 카드 순서 시즌 관련 항목 우선 정렬
- 어드민 공지사항 CRUD (등록·수정·삭제, 기간·유형 설정)
- 홈페이지 상단 공지 배너 자동 노출 (일반/배너/긴급)
- CLAUDE.md에 세무 캘린더 및 마케팅 방향 하네스 추가
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
4개 API 컨트롤러 구현:
✅ AuthController: POST /api/auth/login
✅ BlogController: GET/POST/PUT/DELETE /api/blog
✅ CategoryController: GET/POST/PUT/DELETE /api/category
✅ InquiryController: POST/GET/PUT /api/inquiry
아키텍처 개선:
- Application 서비스 레이어 확장 (CategoryService 추가)
- Repository 인터페이스 CRUD 지원 추가
- Program.cs에 MapControllers() 추가
- 비즈니스 로직과 UI 완전 분리
장점:
- 향후 UI 리뉴얼 시 API 변경 불필요
- 모바일 앱, 데스크톱 클라이언트 추가 가능
- 테스트 가능한 API 엔드포인트
테스트 결과:
✅ 블로그 API: 5개 포스트 조회
✅ 카테고리 API: 5개 카테고리 조회
✅ 문의 API: 문의 제출 성공
⚠️ 인증 API: 예정된 수정 대기
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
kjh2064