qingsongping-AIDevelop/docs/phase-b-company-verification-gate-implementation-report.md

Phase B：已认证企业业务门禁实施报告

日期：2026-09-23 范围：仅 Phase B；未暂存、未提交、未推送、未部署。

结论

Phase B 门禁已在服务层实施并通过全量验证。mvn test 与 mvn clean verify 均为 2880 / 0 failures / 0 errors / 0 skipped；真实 MySQL/Testcontainers 用例实际运行。OpenAPI 检查为 182 paths / 220 operations，All checks passed。API 路径和 operation 集合未改，docs/openapi-rc.json 无差异。

本轮没有启动应用部署或连接生产 RabbitMQ。拒绝路径的事件/通知调用通过测试中的 mock never() 断言验证；本机 RabbitMQ 容器当时为停止状态，因此不报告未经测量的 broker 队列深度。没有数据库迁移，也没有新增业务状态字段。

1. 开工核查与基线

• 分支：master
• HEAD：8c9429108cbd5d85e5245f6c404b2172bf6dd7f3（Phase A 已交付基线）
• 暂存区：空；git diff --check：exit 0
• 工作区：除本轮明确列出的改动外，原有历史未跟踪文件全部保留；未运行 reset、restore、checkout、clean 或任何目录级 git add。
• git status 曾将 CandidateOverviewStatusPolicy.java 与 JobPreferenceScoreCalculator.java 标成修改；逐文件 git hash-object 与 HEAD blob 相同，且 git diff --quiet，确认是 Windows stat 缓存假阳性，内容未改。
• 迁移库存最高为 V46；V1–V46 未改、无 V47。
• 上线健康接口可见版本仅为 0.0.1-SNAPSHOT，不能据此映射出精确线上 commit。Phase B 未部署，线上版本未改变。
• Docker 可用；最终全量验证中的 MySQL/Testcontainers 测试真实执行，Skipped=0。

2. 权威设计和门禁语义

以 docs/company-onboarding-admin-user-management-design.md §7 及独立评审为准：企业认证事实只读 companies.verified；users.is_verified 不用于企业认证判断。

检查顺序保持为：现有认证/活动账号校验 → user_roles 的 COMPANY 身份 → 当前企业资料存在及 owner 归属 → 仅对受限招聘业务检查 companies.verified=true。认证门禁不能取代任何角色、归属、资源可见性判断。资源查询前优先校验调用者所属企业；按资源授权的入口仍保留其原归属检查，避免跨企业数据探测。

未认证、审核中、已拒绝均按 companies.verified=false 统一拒绝受限操作，固定响应 COMPANY_NOT_VERIFIED / code 5004 / HTTP 403 / 文案 company not verified。该错误码与已有数字码无冲突，HTTP 状态集中登记在 ErrorHttpStatusRegistry，没有在 Controller 中复制异常映射。

3. 端点库存与允许/禁止矩阵

逐个检查了 Controller 映射及其 Service 路径。下表中“COMPANY”表示现有 Controller/服务中的 COMPANY 身份要求仍保留；“own/资源归属”表示原企业 owner、岗位、投递或参与者校验仍执行。受限入口在服务端、候选人/Offer/面试等敏感查询或副作用之前执行认证门禁。

接口范围（HTTP method + path）	Controller → Service	Phase B 结果及既有校验
POST /jobs；PUT /jobs/{jobId}；PATCH /jobs/{jobId}/status	JobController → JobService	仍要求 COMPANY 和本企业岗位归属。创建 DRAFT、编辑自己的 DRAFT 允许；已发布内容编辑以及向 PUBLISHED 转换要求认证。将自己已发布岗位转为 CLOSED 仍允许，保留安全下架能力和旧状态语义。跨企业岗位仍按旧归属错误拒绝。公开 GET /jobs、GET /jobs/search、GET /jobs/public/{jobId}、GET /companies/{companyId}/jobs 不改变。
GET /company/applications；PATCH /applications/{id}/status；GET /company/candidates；GET /company/candidates/{applicationId}；GET /company/candidates/{applicationId}/resume；GET /applications/{id}/timeline（企业分支）	ApplicationController → ApplicationService / CompanyResumeAccessPolicy	COMPANY、公司/岗位归属与既有可见性校验保留。企业认证先于敏感投递/候选人查询；下载门禁先于简历存储读取。拒绝时不读文件；学生本人的投递/timeline 分支不加企业门禁。
GET /company/candidates/{applicationId}/scoring；GET /company/scoring/dashboard/{overview,job-rankings,job-rankings/{jobId},candidate-rankings,candidate-rankings/{applicationId},trend}	CandidateScoringController、CompanyScoringDashboardController → scoring services	企业评分/候选人评分属于候选人敏感数据，所有公司入口要求 verified；原公司归属与管理员分支保持不变。
GET/POST/PUT/DELETE /applications/{applicationId}/feedback	CandidateFeedbackController → CandidateFeedbackService	企业侧 feedback 先校验公司归属及认证，再访问投递或写反馈；学生自己的反馈路径/权限保持原语义。
GET /companies/me/jobs/{jobId}/talent-recommendations；POST /companies/me/jobs/{jobId}/talent-invitations；GET /companies/me/talent-invitations；GET /companies/me/talent-invitations/{invitationId}	TalentDiscoveryController、TalentInvitationController → respective services	企业身份、岗位/邀请归属后要求认证；门禁先于候选人匹配、资料加载及邀请写入/通知。/profile/me/talent-discovery 与求职者邀请列表/决定接口仍为求职者自身功能。
POST/GET /applications/{applicationId}/interviews；GET /interviews/me；GET/PUT /interviews/{interviewId}；POST /interviews/{interviewId}/cancel、/complete；GET /interviews/{interviewId}/timeline	InterviewController → InterviewService	企业安排、修改、取消、完成及查看面试时先检查企业认证及原面试/投递归属；求职者查看和回应自己的面试保留原路径与行为。
PUT/GET /interviews/{interviewId}/score；POST /interviews/{interviewId}/score/submit；GET /interviews/{interviewId}/score/history	InterviewScoreController → InterviewScoreService	企业侧评分读写要求认证，并保留面试参与者/归属检查；求职者侧不被企业门禁误伤。
POST/GET /offers；GET/PUT /offers/{id}；PATCH /offers/{id}/status；GET /offers/{id}/timeline；POST /offers/{id}/remind；GET/POST /offers/{id}/counter-offers；PATCH /offers/{id}/counter-offers/{coId}/accept、/reject；GET /offers/statistics	OfferController → OfferService	对公司发起、读取、修改、发送/流转 Offer 及统计入口，在查询/写入/提醒副作用之前验证公司。原 application/offer/counter-offer 所有权检查保留。GET /offers/compare 为求职者接口，不改。
GET/PUT /companies/me/jobs/{jobId}/recommendation-profile；GET/PUT /companies/me/match-rule	recommendation、MatchRuleController → services	公司侧候选人推荐/匹配配置要求 verified，并保留 owner 校验；/profile/me/match-rule 等求职者配置不改。
PUT /applications/{id}/hr-suitability-score；GET /applications/{id}/match；POST /applications/{id}/conversation；GET/POST /conversations；GET /conversations/{id}、/{id}/messages；POST /conversations/messages、/{id}/read、/{conversationId}/messages/{messageId}/recall	match、conversation、MessagingController → services	企业候选人匹配、发起/读取招聘会话和消息均需 verified。会话成员、投递和消息归属校验保留；求职者自己的候选兴趣分/匹配路径不变。消息列表读取还使用明确加载 user_roles 的查询，避免 detached lazy roles 导致角色分支错误。
GET /notifications、/unread-count；POST /notifications/{id}/read、/read-all（企业主体）	NotificationController → NotificationService	企业用户侧通知查看/读状态操作要求认证，拒绝先于通知列表读取或读状态写入；其他主体语义保留。系统 worker/事件生产路径不套用户发起的企业门禁。
GET/POST/PUT /companies/me；GET /companies/me/onboarding；POST/GET /companies/me/verification	CompanyController、CompanyVerificationController → company/onboarding/verification services	未认证企业仍可查改自己的资料、查询聚合状态、提交和查询自己的认证申请。身份及 owner 关系照旧验证；认证审核状态机未改。

明确未加门禁的入口

• 公开岗位、公司资料和公开评价查询没有候选人隐私或企业招聘副作用，保持公开行为。
• CompanyReviewManagementController 的本企业公开岗位评价/回复用于企业声誉运营，不读取候选人敏感资料，也不是招聘动作；按 Phase B 设计范围不设认证门禁，既有公司归属照旧。
• ApplicationMatchController 中求职者的 candidate-interest-score、求职者岗位匹配与个人设置仍按原 STUDENT 路径处理。
• OfferExpiryScheduler/expiry service、匹配通知重试、候选评分 refresh worker、邀请过期清理和通知消费是系统维护/既有任务，不是未认证企业发起的招聘请求；逐一检查没有从这些后台入口调用受限用户写 API，因此不加企业认证门禁，避免误伤既有系统处理。

4. 实施内容和精确文件范围

新增服务层共用规则 mydreamjob-server/src/main/java/com/mydreamjob/company/VerifiedCompanyGuard.java。它只依据传入的 Company.verified 判定；角色、活动状态、公司归属和资源归属仍由现有 service/guard 流程负责。

修改的生产文件（20 个）：

• application/ApplicationService.java、application/CompanyResumeAccessPolicy.java
• auth/UserRepository.java
• bidirectionalmatch/BidirectionalMatchService.java、MatchConversationService.java、MatchRuleService.java
• candidatescore/CandidateScoringEngineService.java、candidatescore/dashboard/CompanyScoringDashboardService.java
• common/exception/ErrorCode.java、ErrorHttpStatusRegistry.java
• feedback/CandidateFeedbackService.java
• interview/InterviewService.java、interviewscore/InterviewScoreService.java
• job/JobService.java
• messaging/MessagingService.java、notification/NotificationService.java
• offer/OfferService.java
• recommendation/JobRecommendationService.java
• talentdiscovery/TalentDiscoveryService.java、talentinvitation/TalentInvitationService.java

新增测试类（3 个）：

• phaseb/PhaseBVerifiedCompanyGateContractTest.java：静态端点—Service 覆盖映射，并锁定认证只看 companies.verified。
• phaseb/VerifiedCompanyGuardTest.java：verified / false / null / company missing 与固定业务码和 403 映射。
• phaseb/VerifiedCompanyGatePersistenceIntegrationTest.java：真实 HTTP PATCH /jobs/{id}/status 对 UNVERIFIED、PENDING、REJECTED 均返回 403/code 5004，并确认 DRAFT 仍未被发布；verified 企业发布成功。

另有既有 service/controller/persistence 测试被扩展：求职者、企业、管理员认证角色及旧行为回归；简历读取计数与租户边界；Job 发布；Offer、Interview、TalentInvitation 的拒绝副作用；feedback、matching、messaging、notification、scoring、resume、interview-score 的企业测试夹具现在明确使用已认证 Company，避免旧测试把默认 verified=false fixture 误当已认证企业。R01-B/R01-C/R01-E 错误映射和消息查询预算测试只调整了 Phase B 新码映射/现有 eager-role 读取所增加的固定查询基线。

被修改的既有测试文件（27 个）：

• application/ApplicationServiceTest.java、CompanyResumeAccessPolicyTest.java、CompanyResumeDownloadIntegrationTest.java
• bidirectionalmatch/BidirectionalMatchPersistenceIntegrationTest.java、BidirectionalMatchServiceTest.java、MatchConversationServiceTest.java、MatchRuleServiceTest.java
• candidatescore/CandidateScoringClockConsistencyTest.java、CandidateScoringEngineServiceTest.java
• common/exception/GlobalExceptionHandlerStatusContractTest.java
• common/r01b/ErrorHttpStatusRegistryTest.java、GlobalExceptionHandlerMappingParityTest.java、R01BIndependentHttpMappingParityTest.java
• common/r01e/R01EIndependentCrossDatabaseVerificationTest.java、R01EQueryBudgetAcceptanceTest.java
• feedback/CandidateFeedbackRefreshRegistrationTest.java、CandidateFeedbackServiceTest.java
• interview/InterviewServiceTest.java
• interviewscore/InterviewScoreControllerTest.java、InterviewScorePersistenceIntegrationTest.java、InterviewScoreServiceTest.java
• job/JobServiceTest.java
• messaging/MessageRecallHttpIntegrationTest.java、MessagingServiceTest.java
• notification/NotificationServiceTest.java
• offer/OfferServiceTest.java
• talentinvitation/TalentInvitationServiceTest.java

没有修改 Controller mappings、DTO、pom.xml、Flyway、V1–V46、OpenAPI 文件、短信服务、Phase A 注册/验证码/Token/企业认证审核流程，也没有任何 Phase C 用户/角色管理代码。

5. TDD 失败证据与测试覆盖

• 先增加 JobServiceTest.transitionStatus_unverifiedCompanyCannotPublish，在尚无门禁时失败：期望 BusinessException，旧实现没有抛出。修复前失败日志保存在系统临时目录，不加入仓库。
• 对简历策略做单点变异（移除认证判断）后，CompanyResumeAccessPolicyTest 新增负向用例失败：未认证时仍访问 applicationRepository.findById，与“门禁先于候选人/简历数据读取”相违。源码恢复后，变异目标测试转绿；变异失败日志保存在系统临时目录。
• HTTP 集成覆盖 UNVERIFIED/PENDING/REJECTED 统一 403 及 verified 可发布。跨企业资源仍由原 service ownership tests 和既有集成回归覆盖。
• 简历测试包含 storage read probe，拒绝路径 READ_CALLS=0。Job 拒绝后状态仍 DRAFT。Offer、Interview、TalentInvitation 的未认证路径对投递/岗位/候选人/offer/interview/invitation/history/audit/notification/刷新等依赖均断言 never()，无业务写入或通知触发。
• 无效 Token、匿名、STUDENT、ADMIN 的 401/403 使用现有 SecurityFilterChain/Controller 回归；Phase B 没有放开匿名路由，也没有改 SecurityConfig。

本轮测试驱动过程中的非产品问题：部分旧单测严格 Mockito stubbing 仍 stub 旧的 findById；用户/角色集合在 service 离开事务后为 lazy，导致企业身份分支不能可靠判定。通过更新这些测试的 stub，并新增 UserRepository.findByIdWithRoles 明确加载 user_roles 修复；没有降低断言，也没有删角色检查。OpenAPI 初次调用时使用了不存在的 docs/verify/_openapi.py 路径；依据仓库文件清单改用 docs/verify_openapi.py 后全部通过，未改脚本。

6. 验证结果

检查	结果
Phase B 定向（Contract + Guard + persistence + Job/Application/Resume/Offer/Interview/Invitation 及关联服务）	189/189，F=0 E=0 S=0；另外最新版 persistence HTTP 类 2/2 单独通过
全量 mvn test	2880/2880，F=0 E=0 S=0，BUILD SUCCESS
最终 mvn clean verify	2880/2880，F=0 E=0 S=0，BUILD SUCCESS；MySQL/Testcontainers 实测执行
python ..\docs\verify_openapi.py（从 server 模块目录）	182 paths / 220 operations，All checks passed
数据库 schema/migration	V1–V46 无差异；无迁移需求；无 V47
OpenAPI/API surface	Controller 路径和 operation 集合未改变；docs/openapi-rc.json 无差异

Phase B 新增用例共 12，全套从 2868 增至 2880。Docker 中 MySQL 8.4/Testcontainers 用例真实执行，Skipped=0。Hikari 在 Testcontainers 销毁/重建连接时输出连接已关闭的校验 WARN；两轮全量均以 0 errors 成功完成。

7. 副作用、安全与已知观测

• 认证事实静态断言确认 Guard 只读取 Company.verified，不读取 User.isVerified。
• 租户 A 即使已认证仍须通过原 owner/资源关系校验；新门禁不构成跨企业授权。服务先验证企业/权限，再查候选人敏感资源；简历 policy 在 read(storagePath) 之前失败关闭。
• 拒绝请求不会改变 DRAFT/Offer/Interview/Invitation 等业务记录；未调用 audit、notification、message/event publisher 或 scoring refresh 依赖。没有真实 RabbitMQ 运行，因此不声称 broker queue depth 被独立读取；拒绝路径的 publisher 无交互由测试逐项锁定。
• 新增代码和报告未包含凭据、JWT、密码、真实手机号、数据库连接秘密、容器动态口令或本机路径；测试数据使用非真实 fixture。修复前日志留在临时目录，未加入 Git。
• 没有通过设置 verified=true 绕过生产流程；“verified”测试场景仅在测试 fixture 中按显式场景构造，以验证认证企业原行为。

8. Git 结束状态

• HEAD 仍为 8c9429108cbd5d85e5245f6c404b2172bf6dd7f3，分支仍为 master。
• 暂存区为空，git diff --check exit 0；没有提交、推送、部署或合并。
• 新增生产组件和 Phase B 测试及本报告仍未跟踪；所有此前历史未跟踪文件原样保留。
• 工作区中 20 个已跟踪生产文件有 Phase B 改动；额外两个显示为修改的既有文件已通过 blob hash 证实内容与 HEAD 完全一致。
• 最终核查无 Java/Maven 残留进程，8080/8081 无监听；未停止或删除 Docker 容器/镜像。

Phase C 管理员用户与角色管理未进入；Phase B 未部署。下一步是独立代码复验，不是提交或部署。

9. 两项独立复验阻断修复（2026-09-23）

独立复验发现岗位发布门禁发生在岗位 ID/归属查询之后，可能通过业务码与 HTTP 状态差异探测跨企业岗位；另发现 VerifiedCompanyGatePersistenceIntegrationTest 使用全局 TestAuthTokens 数据源注册表，在组合运行时偶发无法签发会话。

• JobService.transitionStatus 对目标 PUBLISHED 先调用 requireVerifiedCompany，再查询岗位；未认证公司的有效 ID、其他公司 ID 和不存在 ID 均先得到固定认证拒绝，不触发岗位查询。
• 新增 JobRepository.findByIdAndCompanyId，并用于企业岗位读取、修改和状态操作。跨企业岗位和不存在岗位都按 JOB_NOT_FOUND/404 处理；JobController.getJob 改为单次归属限定查询，避免泄露资源存在性。
• 保留设计允许的未认证企业自有 DRAFT 岗位查看与编辑；已认证企业仍必须通过原企业归属条件，不获得跨企业访问权限。
• VerifiedCompanyGatePersistenceIntegrationTest 不再调用静态全局 TestAuthTokens，改由当前 Spring 测试上下文的真实 AuthSessionService 创建会话，Token 和会话记录落在当前事务数据源中，事务结束回滚，不依赖其他测试上下文的注册/销毁顺序。
• 先加 HTTP 回归再改生产代码时，新测试复现了原差异：未认证发布外企业岗位得到 400、读取/修改外企业岗位得到 400，而目标契约为认证门禁 403 或与不存在资源一致的 404。更新后的 HTTP 集成类 4/4 通过；岗位与认证边界组合 33/33 通过；原 10 类定向组合现为 191/191，F=0/E=0/S=0。
• 两条既有跨企业岗位 HTTP 断言改为校验 404/JOB_NOT_FOUND；夹具明确设成 VERIFIED，确保发布测试实际走到资源归属门禁而不是被未认证门禁短路。

修复后验证：

检查	结果
mvn test	2882/2882，F=0/E=0/S=0，BUILD SUCCESS
mvn clean verify	2882/2882，F=0/E=0/S=0，BUILD SUCCESS；Testcontainers 真实执行
python ..\docs\verify_openapi.py	182 paths / 220 operations，All checks passed

两项阻断已修复并验证。本轮仍未暂存、提交、推送或部署；Phase B 后续仍需独立复验结论确认后才能进入相应检查点。