docs(hjc): 甲方确认项目与标书为同一实体（一个项目一本标书），单表建模

CONTEXT.md

@@ -4,13 +4,9 @@
 
 ## 核心实体
 
-**项目 (Project)**:
-一条被浏览/售卖的采购项目，是平台内容的主体。携带项目编号、名称/分类、招标人、中标公司、中标金额与中标公告信息。
-_Avoid_: 标书项目, tender
-
-**标书 (BidDocument)**:
-挂在项目下、可购买下载的标书。一个项目当前对应一本标书，但按未来「一个项目多本标书」预留 1:N。携带标书价格（信息服务费）、标书附件、开售/停售时间与售卖方式。
-_Avoid_: tender, 招标文件
+**标书项目 (Bid Project)**:
+一条采购项目，同时也是可购买下载的标书，二者是**同一实体**（甲方确认：一个项目即一本标书）。携带项目编号、名称/分类、招标人、中标公司、中标金额与中标公告信息，以及标书价格（信息服务费）、标书附件、开售/停售时间与售卖方式。
+_Avoid_: 项目(单用), 标书(单用), tender
 
 **企业账号 (Enterprise Account)**:
 买家账号，用企业名称+密码登录，须通过资质审核才能购买标书。

docs/adr/0002-project-biddoc-onetomany.md

@@ -1,3 +1,5 @@
-# 项目与标书建模为两个实体，关联 1 项目:N 标书
+# 项目与标书为同一实体：一个项目一本标书
 
-项目（Project）与标书（BidDocument）建为两个独立实体，标书持有项目外键，关联为 1 项目:N 标书。当前一对一，但需求明确未来可能出现一个项目挂多本标书，故标书字段不并入项目，而是独立成表。一站式推送的公告类字段（公告标题/招标人/中标公司/中标金额/公告正文/公告附件）落项目，销售类字段（标书价格/附件/开售/停售/售卖方式/needSell）落标书，二者都由「推送入库 + 管理后台手工增删改查」双路填充。理由：在项目/标书需求仍模糊时避免强行锁死单一结构，同时为「一项目多标书」预留扩展而不必迁移主数据。
+**Supersedes**: 早先「项目/标书两个实体、1 项目:N 标书」的假设——甲方已明确**项目与标书是一个东西，一个项目即一本标书**，故撤销该假设。
+
+项目（Project）与标书（BidDocument）建模为**同一个实体**（`标书项目`），单表承载。一站式推送的公告类字段（公告标题/招标人/中标公司/中标金额/公告正文/公告附件）与销售类字段（标书价格/附件/开售/停售/售卖方式/needSell）都落在这一张表上，由「推送入库 + 管理后台手工增删改查」双路填充。理由：既然甲方确认一个项目仅对应一本标书，两实体之间的 1:N 关系已不存在，拆表只会增加复杂度而无对应业务收益；等未来确实出现「一项目多标书」再演进（届时把标书款从主表抽出即可，主表结构无须预埋）。