婚礼客户门户里的会议和共享笔记，为什么仍只能查看

新人在婚礼项目门户里看见会议、文件和笔记，并不意味着已经取得整套项目的编辑界面。HoneyBook的客户门户帮助页将它定义为project的client-facing version，即项目面向客户的一侧。这个定义先划出内容的对象：客户集中接触的是已共享文件、消息和项目详情，而不是策划团队内部工作区的完整镜像。[1]

门户中各区域承担的事情并不相同。Activity呈现文件何时发出、邮件往来，也允许客户发送消息；Files集中共享文档、附件和书签；Payments则用于查看发票文件。[1] 同属一个婚礼项目，并没有使消息记录、资料附件和发票成为一种文件。整理一份交接说明时，指出资料位于哪个区域，能够同时交代它在项目沟通中的角色，不必把所有内容都笼统称为“项目文档”。

Meetings的限制尤其明确：过去和未来的会议以只读列表呈现，客户不能通过这个门户安排会议。[1] 因此，列表中的一项会议可以是客户能够查阅的安排，却不是在该列表里新建或修改会议的入口。这里的过去、未来又说明，只读并非仅针对已经结束的记录；资料的时间方向与界面允许的行为，是两个不同方面。

共享笔记也保持同样清楚的查看边界。Notes区域显示策划方已分享的笔记，客户可以看而不能编辑；被选择分享的项目详情同样只能查看。[1] “分享”在这里首先让特定内容进入客户侧，不会自动把笔记的修改权一并交出。一份策划备注从内部形成到客户可读，涉及的是可见内容的选择，而不是把所有项目字段都变成双方共同编辑的表格。

内部区域进一步解释了客户侧为何不是完整后台。帮助页将Not visible to clients下面的内容限定为策划方及有项目访问权的内部团队成员可见；另外明确，客户不能访问内部任务、自动化工具或尚未分享的笔记。[1] 内部成员也有项目访问这一前提，不应只因属于团队便抹掉它。对同一份项目介绍，已共享笔记与未共享笔记必须分别表达，不能统一写成客户已经看到所有筹备说明。

客户并非完全不能增加内容。原页说，Attach可加入客户自己的图像或文件，项目参与者能查看这些附件，但不会得到通知。[1] 这条规则让上传、内容可见和通知成为三个具体事实：有附件不等于已有通知记录。本篇只保留这一门户规则，不沿用另一份任务文档去推断上传后执行清单的完成状态。

项目之间也存在边界。All Projects让被加入多个项目的客户在其中切换，原文同时排除了未加入的其他项目、业务pipeline与账户详情。[1] 对婚礼策划资料员而言，一次项目入口应按它实际包含的区域来说明：会议和共享笔记可读，附件可加入，内部工作资料另有范围。上述内容来自公开帮助文字，首次发布日期未明确；本文未登录账户或测试通知，不据此作保密、付款或服务履行判断。