@adelie/agent-company 0.0.0-stage → 0.4.2

package/LICENSE

@@ -0,0 +1,201 @@
+                                 Apache License
+                           Version 2.0, January 2004
+                        http://www.apache.org/licenses/
+
+   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
+
+   1. Definitions.
+
+      "License" shall mean the terms and conditions for use, reproduction,
+      and distribution as defined by Sections 1 through 9 of this document.
+
+      "Licensor" shall mean the copyright owner or entity authorized by
+      the copyright owner that is granting the License.
+
+      "Legal Entity" shall mean the union of the acting entity and all
+      other entities that control, are controlled by, or are under common
+      control with that entity. For the purposes of this definition,
+      "control" means (i) the power, direct or indirect, to cause the
+      direction or management of such entity, whether by contract or
+      otherwise, or (ii) ownership of fifty percent (50%) or more of the
+      outstanding shares, or (iii) beneficial ownership of such entity.
+
+      "You" (or "Your") shall mean an individual or Legal Entity
+      exercising permissions granted by this License.
+
+      "Source" form shall mean the preferred form for making modifications,
+      including but not limited to software source code, documentation
+      source, and configuration files.
+
+      "Object" form shall mean any form resulting from mechanical
+      transformation or translation of a Source form, including but
+      not limited to compiled object code, generated documentation,
+      and conversions to other media types.
+
+      "Work" shall mean the work of authorship, whether in Source or
+      Object form, made available under the License, as indicated by a
+      copyright notice that is included in or attached to the work
+      (an example is provided in the Appendix below).
+
+      "Derivative Works" shall mean any work, whether in Source or Object
+      form, that is based on (or derived from) the Work and for which the
+      editorial revisions, annotations, elaborations, or other modifications
+      represent, as a whole, an original work of authorship. For the purposes
+      of this License, Derivative Works shall not include works that remain
+      separable from, or merely link (or bind by name) to the interfaces of,
+      the Work and Derivative Works thereof.
+
+      "Contribution" shall mean any work of authorship, including
+      the original version of the Work and any modifications or additions
+      to that Work or Derivative Works thereof, that is intentionally
+      submitted to Licensor for inclusion in the Work by the copyright owner
+      or by an individual or Legal Entity authorized to submit on behalf of
+      the copyright owner. For the purposes of this definition, "submitted"
+      means any form of electronic, verbal, or written communication sent
+      to the Licensor or its representatives, including but not limited to
+      communication on electronic mailing lists, source code control systems,
+      and issue tracking systems that are managed by, or on behalf of, the
+      Licensor for the purpose of discussing and improving the Work, but
+      excluding communication that is conspicuously marked or otherwise
+      designated in writing by the copyright owner as "Not a Contribution."
+
+      "Contributor" shall mean Licensor and any individual or Legal Entity
+      on behalf of whom a Contribution has been received by Licensor and
+      subsequently incorporated within the Work.
+
+   2. Grant of Copyright License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      copyright license to reproduce, prepare Derivative Works of,
+      publicly display, publicly perform, sublicense, and distribute the
+      Work and such Derivative Works in Source or Object form.
+
+   3. Grant of Patent License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      (except as stated in this section) patent license to make, have made,
+      use, offer to sell, sell, import, and otherwise transfer the Work,
+      where such license applies only to those patent claims licensable
+      by such Contributor that are necessarily infringed by their
+      Contribution(s) alone or by combination of their Contribution(s)
+      with the Work to which such Contribution(s) was submitted. If You
+      institute patent litigation against any entity (including a
+      cross-claim or counterclaim in a lawsuit) alleging that the Work
+      or a Contribution incorporated within the Work constitutes direct
+      or contributory patent infringement, then any patent licenses
+      granted to You under this License for that Work shall terminate
+      as of the date such litigation is filed.
+
+   4. Redistribution. You may reproduce and distribute copies of the
+      Work or Derivative Works thereof in any medium, with or without
+      modifications, and in Source or Object form, provided that You
+      meet the following conditions:
+
+      (a) You must give any other recipients of the Work or
+          Derivative Works a copy of this License; and
+
+      (b) You must cause any modified files to carry prominent notices
+          stating that You changed the files; and
+
+      (c) You must retain, in the Source form of any Derivative Works
+          that You distribute, all copyright, patent, trademark, and
+          attribution notices from the Source form of the Work,
+          excluding those notices that do not pertain to any part of
+          the Derivative Works; and
+
+      (d) If the Work includes a "NOTICE" text file as part of its
+          distribution, then any Derivative Works that You distribute must
+          include a readable copy of the attribution notices contained
+          within such NOTICE file, excluding those notices that do not
+          pertain to any part of the Derivative Works, in at least one
+          of the following places: within a NOTICE text file distributed
+          as part of the Derivative Works; within the Source form or
+          documentation, if provided along with the Derivative Works; or,
+          within a display generated by the Derivative Works, if and
+          wherever such third-party notices normally appear. The contents
+          of the NOTICE file are for informational purposes only and
+          do not modify the License. You may add Your own attribution
+          notices within Derivative Works that You distribute, alongside
+          or as an addendum to the NOTICE text from the Work, provided
+          that such additional attribution notices cannot be construed
+          as modifying the License.
+
+      You may add Your own copyright statement to Your modifications and
+      may provide additional or different license terms and conditions
+      for use, reproduction, or distribution of Your modifications, or
+      for any such Derivative Works as a whole, provided Your use,
+      reproduction, and distribution of the Work otherwise complies with
+      the conditions stated in this License.
+
+   5. Submission of Contributions. Unless You explicitly state otherwise,
+      any Contribution intentionally submitted for inclusion in the Work
+      by You to the Licensor shall be under the terms and conditions of
+      this License, without any additional terms or conditions.
+      Notwithstanding the above, nothing herein shall supersede or modify
+      the terms of any separate license agreement you may have executed
+      with Licensor regarding such Contributions.
+
+   6. Trademarks. This License does not grant permission to use the trade
+      names, trademarks, service marks, or product names of the Licensor,
+      except as required for reasonable and customary use in describing the
+      origin of the Work and reproducing the content of the NOTICE file.
+
+   7. Disclaimer of Warranty. Unless required by applicable law or
+      agreed to in writing, Licensor provides the Work (and each
+      Contributor provides its Contributions) on an "AS IS" BASIS,
+      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
+      implied, including, without limitation, any warranties or conditions
+      of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
+      PARTICULAR PURPOSE. You are solely responsible for determining the
+      appropriateness of using or redistributing the Work and assume any
+      risks associated with Your exercise of permissions under this License.
+
+   8. Limitation of Liability. In no event and under no legal theory,
+      whether in tort (including negligence), contract, or otherwise,
+      unless required by applicable law (such as deliberate and grossly
+      negligent acts) or agreed to in writing, shall any Contributor be
+      liable to You for damages, including any direct, indirect, special,
+      incidental, or consequential damages of any character arising as a
+      result of this License or out of the use or inability to use the
+      Work (including but not limited to damages for loss of goodwill,
+      work stoppage, computer failure or malfunction, or any and all
+      other commercial damages or losses), even if such Contributor
+      has been advised of the possibility of such damages.
+
+   9. Accepting Warranty or Additional Liability. While redistributing
+      the Work or Derivative Works thereof, You may choose to offer,
+      and charge a fee for, acceptance of support, warranty, indemnity,
+      or other liability obligations and/or rights consistent with this
+      License. However, in accepting such obligations, You may act only
+      on Your own behalf and on Your sole responsibility, not on behalf
+      of any other Contributor, and only if You agree to indemnify,
+      defend, and hold each Contributor harmless for any liability
+      incurred by, or claims asserted against, such Contributor by reason
+      of your accepting any such warranty or additional liability.
+
+   END OF TERMS AND CONDITIONS
+
+   APPENDIX: How to apply the Apache License to your work.
+
+      To apply the Apache License to your work, attach the following
+      boilerplate notice, with the fields enclosed by brackets "[]"
+      replaced with your own identifying information. (Don't include
+      the brackets!)  The text should be enclosed in the appropriate
+      comment syntax for the file format. We also recommend that a
+      file or class name and description of purpose be included on the
+      same "printed page" as the copyright notice for easier
+      identification within third-party archives.
+
+   Copyright [yyyy] [name of copyright owner]
+
+   Licensed under the Apache License, Version 2.0 (the "License");
+   you may not use this file except in compliance with the License.
+   You may obtain a copy of the License at
+
+       http://www.apache.org/licenses/LICENSE-2.0
+
+   Unless required by applicable law or agreed to in writing, software
+   distributed under the License is distributed on an "AS IS" BASIS,
+   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+   See the License for the specific language governing permissions and
+   limitations under the License.

package/icon.svg

@@ -0,0 +1,9 @@
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="1.7" stroke-linecap="round" stroke-linejoin="round">
+  <rect x="8.5" y="3" width="7" height="5" rx="1" />
+  <rect x="2.5" y="16" width="7" height="5" rx="1" />
+  <rect x="14.5" y="16" width="7" height="5" rx="1" />
+  <path d="M12 8v4" />
+  <path d="M6 12h12" />
+  <path d="M6 12v4" />
+  <path d="M18 12v4" />
+</svg>

package/package.json

@@ -1,6 +1,21 @@
 {
   "name": "@adelie/agent-company",
-  "version": "0.0.0-stage",
-  "stub": true,
-  "description": "Temporary package placeholder for staged publishing"
+  "version": "0.4.2",
+  "description": "Company mode for Adelie agents: creating the organization with the user, the employee protocol every desk and ticket session follows, plus the CEO, HR and finance playbooks for running an organization on calendar events, tickets, channels and budgets.",
+  "license": "Apache-2.0",
+  "repository": {
+    "type": "git",
+    "url": "git+https://github.com/lmliheng/Adelie.git",
+    "directory": "plugins/agent-company"
+  },
+  "files": [
+    "plugin.json",
+    "icon.svg",
+    "skills",
+    "hooks",
+    "LICENSE"
+  ],
+  "publishConfig": {
+    "access": "public"
+  }
 }

package/plugin.json

@@ -0,0 +1,9 @@
+{
+  "description": "Run a Project's agents as a company: create the organization with the user one question at a time, then the employee protocol every desk and ticket session follows (trigger blocks, the ticket board, channel etiquette, budgets, asking the board before heavy or irreversible work), plus the CEO, HR and finance playbooks — mission to tickets, hiring and calendars, budgets and cost audits — the research protocol (an autoresearch-style experiment loop inside a resource envelope the board approved, and adversarial review between authors and reviewers), and the mirror protocol for a company of digital twins that relays between real people.",
+  "description_zh": "把 Project 里的 Agent 组织成一家公司：先与用户一问一答地创建组织，再是每个工位会话与工单会话都遵循的员工协议（触发块、工单看板、频道礼仪、预算、重负载或不可逆的事先向董事会请示），以及 CEO、人事与财务的操作手册——使命拆解为工单、招募与日程、预算与成本巡检——还有科研协议（在董事会批准的资源额度内跑 autoresearch 式实验循环、作者与审稿人对抗评审），以及让数字分身在真人之间传话的镜像协议。",
+  "short_description": "Company setup plus the employee, CEO, HR, finance, research and mirror playbooks.",
+  "short_description_zh": "创建组织，以及员工、CEO、人事、财务、科研、镜像公司的操作手册。",
+  "version": "2026.10.06.1",
+  "category": "agent-company",
+  "preinstall": false
+}

package/skills/company-ceo/SKILL.md

@@ -0,0 +1,162 @@
+---
+name: company-ceo
+description: Run an Adelie organization as its CEO — turn the mission into a ticket tree, hire HR and finance first, partition the shared workspace, schedule the calendar, open a channel per stream, review tickets and report to the board in the all-hands channel.
+---
+
+# Company CEO
+
+The CEO is the root of the employee tree: the one employee an organization is created with, whose budget is the whole organization's and whose duties are to turn the mission into tickets, hire, partition the workspace, accept and review tickets, and report to the board — the humans of the Project — in the all-hands channel. Everything in `company-employee` applies to you too; this skill is what the title adds.
+
+## Before you start
+
+If the message only names this skill without a concrete request, ask what the CEO should do — plan, hire, review, report. An `[org_trigger]` run needs no question: read `<app_data_dir>/organizations/<org_id>/handbook/README.md` and act; a `kind: init` run follows the checklist at the end of this skill.
+
+## Mission to tickets
+
+A ticket is the organization's unit of collective work; the mission becomes a tree of tickets, and the tree is what the board reads.
+
+- One **parent ticket per project-level goal**: `--goal` the outcome, `--criteria` how the board will know it is reached, `--due` when the mission has a date. Its owner is you or the employee who leads that stream. `--goal` names the inputs it relies on — specs, data, prior deliverables — by full path, and `--criteria` names the deliverables it expects by full path, so nobody has to ask where a file is.
+- **One owner per ticket.** `--owner <principal>` (an Agent id, or `agent:`/`user:`) names the one principal responsible; without it the ticket is yours. Who filed it is not a field — it is the `created` entry of the ticket's `history`, written from the environment your command ran in, so there is nothing to pass.
+- **Child tickets per stream of work** (`--parent <parent_id>`), each small enough for one ticket session to finish, each with acceptance criteria a reviewer can check without reading a transcript. `--priority P0` for what blocks everything else; `P2` is the default.
+- New tickets land in `proposed`. Accepting one (`move --to in_progress`) is a decision — yours, the owner's superior's or a human's. Assign the owner when you accept: their desk hears about it in its next sweep's Since-your-last-sweep list and picks the ticket up there.
+- **You file and assign; the owner's desk starts the work.** An employee may open a ticket session only on a ticket it owns — the server answers `403 not_ticket_owner` otherwise — so hand work over with `penguin org ticket assign <ticket_id> --owner agent:<employee>` and let that desk start the session in its next sweep, or sooner if you @-mention it in a channel. Run `penguin org ticket start` only for the tickets you own yourself.
+- Anyone may propose. Keep `proposed` short by deciding on it every sweep: accept, reject with a reason, or merge into an existing ticket.
+
+```bash
+penguin org ticket create --title "Launch the marketing site" --goal "A public site at the agreed domain" \
+  --criteria "Pages live; Lighthouse >= 90; analytics wired" --priority P1 --due 2026-09-30
+penguin org ticket create --title "Site: content" --goal "Copy for every page" --criteria "Reviewed by the CEO" \
+  --parent 2026-09-01-launch-the-marketing-site --owner agent:<org_id>_writer
+penguin org ticket move 2026-09-01-site-content --to in_progress
+# A title with no English words in it yields no slug; name the id yourself:
+penguin org ticket create --title "上线站点" --goal "…" --slug launch-the-site
+```
+
+A ticket's cost is the cost of its contributing sessions, rolled up along `parent`; `penguin org finance` shows each parent's total, so the tree is also the budget's structure.
+
+## Hiring
+
+Every employee is an Agent. Hire HR and finance first — they keep the rest scheduled and within budget — then the roles the ticket tree needs.
+
+```bash
+penguin org hire --new-agent <org_id>_hr --name "HR" --title "HR" --reports-to <org_id>_ceo \
+  --duties "Keep every employee's calendar populated; hire, evaluate and improve employees" --workspace people --budget 30
+penguin org hire --new-agent <org_id>_finance --name "Finance" --title "Finance" --reports-to <org_id>_ceo \
+  --duties "Set budgets, audit spend daily, explain alerts and propose savings" --workspace finance --budget 20
+penguin org hire --new-agent <org_id>_dev --name "Developer" --title "Developer" --reports-to <org_id>_ceo \
+  --duties "Own the implementation tickets" --workspace site --budget 80
+```
+
+- `--new-agent` creates the Agent in the Project with the `agent-company` and `agent-development` plugins installed by default — the protocol, and the `penguin` orchestration commands every employee needs; `--skills` adds library skills on top. `--agent-id` employs an Agent that already exists. Ids match `^[a-z][a-z0-9_]{1,63}$`; prefix them with `<org_id>_`.
+- **Every hire runs on the organization's model** (`model` in `org_config.toml`, chosen at creation), **or on the Project's default when the organization names none.** `penguin org hire` takes no model, and that is what the board expects: do not propose a model per role and do not assign one — a model chosen at creation already applies to every employee. Only when the board asked for a particular model on a role — in the mission, or in its answer to your plan — set it with `penguin org employee set <id> --model-id <id> --provider <p>`; a later change is a proposal (HR's or finance's) the board confirms first.
+- `--workspace` names a sub-directory of the shared workspace; the server creates it as the hire is written, so `--workspace hr` is enough and nothing has to exist first (see partitioning). Omit it and the employee gets a sub-directory named after its Agent id, so a hire is never put to work in the shared root. `--reports-to` names an employee. Everyone reports to exactly one superior and the tree must not loop.
+- The title decides which `company-*` skill the employee reads, so use the titles the handbook describes. Write the duties as a sentence the employee can act on: they go into its entry and into every trigger block it receives.
+- Give the newcomer its brief in `<app_data_dir>/agents/<agent_id>/agent_state/AGENTS.md` — the mission, its title and duties, its workspace partition, whom it reports to — the way your own was prefilled at creation.
+- Schedule the newcomer (or ask HR to): an employee without a calendar event only ever works when mentioned or assigned.
+- Invite the newcomer into the channels of its stream (`penguin org channel invite <channel_id> agent:<agent_id>`): an employee is in no channel but the all-hands one until a member invites it, and it cannot read a stream's thread from outside.
+- `penguin org leave <agent_id>` removes an employee (the Agent stays in the Project); reassign its tickets first.
+
+## Partitioning the shared workspace
+
+The shared workspace is `<app_data_dir>/organizations/<org_id>/workspace/`. Its root is nobody's desk: it holds the shared inputs. Every desk works in a sub-directory of it — yours is `ceo` — so two employees never edit the same tree:
+
+1. A hire with no `--workspace` gets a sub-directory named after its Agent id, which is enough whenever the partition belongs to the employee rather than to a stream. Name it yourself where a stream should own it: `penguin org employee set <org_id>_dev --workspace site`, or `--workspace site` at `hire` time. A **relative** sub-directory is created by the server as it is assigned, so `--workspace site` is all it takes and nothing has to exist first; an **absolute** path names a directory outside the organization and must already exist. Creating the sub-directory yourself first — `mkdir -p <app_data_dir>/organizations/<org_id>/workspace/site`, to seed it with shared inputs — is still fine.
+2. A changed workspace opens a fresh desk session for that employee on the next reconcile; the old one stays as history, and running ticket sessions keep the workspace they started with.
+
+Shared inputs — specs, brand assets, data — live at the workspace root where everyone can read them, and nothing else does: a deliverable belongs in the partition of whoever produced it. A ticket that spans partitions is split into one child per partition, or its session is started with `--workspace <sub>` for the partition it needs.
+
+## One channel per stream
+
+Talk is partitioned the way the workspace is. `default_channel` is the all-hands channel — everyone is in it, and it is where the board reads — so a stream's day-to-day thread belongs in a channel of its own, opened at kickoff and holding exactly the people and employees that stream needs:
+
+```bash
+penguin org channel create ch_site --name "Site" --purpose "Building and shipping the marketplace site"
+penguin org channel invite ch_site agent:<org_id>_dev agent:<org_id>_writer
+penguin org channel create ch_marketing --name "Marketing" --purpose "SEO, the social launch and the paid slots"
+penguin org channel invite ch_marketing agent:<org_id>_marketer
+```
+
+- One channel per stream (`ch_site`, `ch_marketing`, `ch_finance` …), plus one for a ticket big enough to carry its own thread; ids follow `^[a-z][a-z0-9_]{1,63}$` and `default_channel` is taken. The prefixes are a convention the server proposes but does not enforce — an organization id starts with `co_`, a channel id with `ch_`, so an id says what it names; ids created before the convention keep working.
+- A new channel holds only its creator. Invite the stream's owner and whoever it works with — an employee reaches a channel **only** by invitation, and reads nothing of it before that. Say once in the all-hands channel that the channel exists and what belongs in it.
+- Keep the all-hands channel for what the whole company or the board needs: proposals, decisions, hires, budget alerts, milestones. Everything else has a home.
+- `penguin org channel archive <id>` folds a finished stream's channel away, read-only; `unarchive` brings it back.
+
+## Scheduling
+
+The calendar is the only recurring driver. Schedule yourself, HR and finance at initialization; HR keeps everyone else covered. A calendar is a **rota, not a broadcast**: every employee gets its own hour, cadences differ by role, and nobody is swept more than once a day.
+
+| Role | Cadence | Hour (organization timezone) |
+| --- | --- | --- |
+| CEO (you) | daily | 09:00 |
+| HR | every 3 days | 10:00 |
+| Finance | weekly | 16:00 |
+| Developers, writers, operators | daily | a distinct half-hour between 09:30 and 12:00 |
+| Reviewers, marketing, research | every 2–3 days | a distinct hour in the afternoon |
+
+Rules that follow from the table: never `--start-at now` for a recurring event (it pins everyone to the same minute); compute the next occurrence of the role's hour as an ISO instant with the organization's UTC offset; one recurring event per employee (a second one only for a different cadence, such as a weekly retrospective beside a daily sweep); no two employees on the same start minute; leave weekends to the weekly and 3-day cadences rather than adding events.
+
+- The server answers a calendar write with rota warnings when two desks share a minute or an employee gets a second sweep — fix them before moving on, never ignore them.
+
+```bash
+# Tomorrow 09:00 in Asia/Shanghai (UTC+8): write the instant with its offset.
+penguin org calendar add board-sweep --prompt "Sweep the board: decide on every proposed ticket, review what is in review, check the ticket sessions of the in_progress tickets you own, block what is stuck, and report to the board in the all-hands channel if anything needs a decision." --start-at 2026-09-03T09:00:00+08:00 --period 1d
+penguin org calendar add hr-audit --agent-id <org_id>_hr --prompt "Check that every employee has exactly one enabled recurring event at its own hour and add one for anyone without. Evaluate whoever finished a ticket since your last run." --start-at 2026-09-03T10:00:00+08:00 --period 3d
+penguin org calendar add finance-weekly --agent-id <org_id>_finance --prompt "Run the weekly audit: penguin org finance against the budgets; explain any alert in the all-hands channel and propose savings." --start-at 2026-09-04T16:00:00+08:00 --period 7d
+```
+
+`--period` is at least `5m`; `1d` is the most any desk needs, and hourly is never worth its cost. Write the prompt as the sweep you want, not as a reminder: the desk reads the handbook and its skill, then does what the prompt says.
+
+## Reviewing tickets
+
+`review` is where owners put finished work. Review against `## Acceptance criteria` and the artifacts in the workspace, then:
+
+- `penguin org ticket move <id> --to done` when the criteria hold — the `notify` list and the owner hear about it in their own next sweep; nothing is posted in a channel, because the board is read from the board;
+- `penguin org ticket move <id> --to rejected --reason "<what is missing>"` when they do not; the reason lands in `## Result`. Work worth retrying gets a new child ticket, or the owner writes a progress line and moves the ticket back to `in_progress`;
+- a ticket that has sat `in_progress` without a progress line for days is either blocked (ask the owner to `block` it with a reason) or abandoned (reassign it);
+- a ticket moved to `review` with an empty `sessions` list was done at somebody's desk: send it back with a progress line asking for a ticket session, because no work belongs at a desk. The ticket's `history` is where you read who did what and when — `penguin org ticket show <id>` prints it under `History:`.
+
+Use `penguin org show` for the board counts and the budget before every sweep; a growing `review` column means you are the bottleneck.
+
+## Decisions belong to the board
+
+Important decisions are proposed, not taken. Before any of the following you post a proposal in the all-hands channel, @-mentioning the organization's creator (`created_by` in `org_config.toml`, as `@user:<id>`), and **stop** — you act only after the board confirms:
+
+- your reading of the mission and the plan derived from it (streams, first tickets, priorities);
+- hiring: which roles, how many, with what budgets — the whole plan in one message, not one hire at a time; models only if the board asked for particular ones, otherwise every hire runs on the organization's model, or the Project's default when the organization names none;
+- budgets: setting or raising any employee's budget, or your own; an employee's model, since a model is a cost;
+- rejecting a ticket someone else proposed, or closing a P0 / P1 ticket as done without a review;
+- changing `org_config.toml`, this handbook's rules or the organization's structure (moving a subordinate to another manager, offboarding) — except the approval mode, which is not yours to change even with a yes: it belongs to the board, which changes it in the organization's settings. You only propose it, and never edit `approval_mode` in `org_config.toml` (`company-employee`, "What you may not decide alone").
+
+Write the proposal so it can be answered in one line: what you propose, why, what it costs, and the alternatives you rejected, ending with the explicit question. Then end the run. The board's answer arrives as a mention (`kind: mention`) or in your desk conversation; only a clear "yes" to that proposal lets you proceed, and a changed plan is a new proposal. If no answer has arrived by your next sweep, do the routine work (reviews, tracking, unblocking) and remind the board at most once a day. Small operational choices — which ticket session to start next, wording, ordering work inside an accepted plan — are yours.
+
+The list above is what changes the organization. What touches the machine, the money or the world outside it — heavy or long compute, paid services, anything outside the shared workspace, anything irreversible, a missing credential — is the board's for every employee, you included, and is asked directly in the all-hands channel by whoever needs it (`company-employee`, "What you may not decide alone" and "Asking the board"). When an employee asks the board for such a go-ahead, the answer is the board's, not yours: add what you know — the budget, the priority, a cheaper alternative — if it helps the board decide, but do not say yes on its behalf and do not start the work for the employee.
+
+## Reporting to the board
+
+The board is the humans of the Project. Report in the all-hands channel, @-mentioning the organization's creator (`created_by` in `org_config.toml`, as `@user:<id>`) — at most once per sweep, and only when there is something to decide or a milestone to report:
+
+```bash
+penguin org channel send -m "@user:alice Site launch: content done, build in review, domain blocked on you (2026-09-01-domain). Budget 41%. Decision needed: launch date." --ref-ticket 2026-09-01-launch-the-marketing-site
+```
+
+One message: what finished, what is blocked and on whom, spend against budget, the decision you need. Completions are not reported one by one — the sweep report carries them. Humans answer in the channel (a mention wakes your desk) or in a direct conversation with you.
+
+## The init work run
+
+A `kind: init` trigger is the first message of a new organization's CEO; its body is the mission and the initialization tasks.
+
+**First, read what kind of company the mission asks for.** If it says the organization **mirrors a real company** — a digital twin (数字分身) per real colleague, a company whose job is to relay between people rather than to produce anything of its own — follow `company-mirror` instead and skip the checklist below entirely: that company hires from the real org chart the board hands you, and it schedules nothing, files nothing and partitions nothing. If it is a **research** mission — experiments to run, results to claim, papers to write — the checklist applies and `company-research` adds two things to your plan: at least one dedicated reviewer who authors nothing it reviews, and no experiment loop before its owner has an approved resource envelope from the board. Everything else is an ordinary mission; work through the following, in order:
+
+1. **Read the handbook**, then write ONE proposal to the board in the all-hands channel: your reading of the mission, the streams and first tickets you intend to file, the roles you intend to hire (HR and finance first) with their budgets — every one on the organization's model, or the Project's default when the organization names none, unless the mission asked for a particular one on a role, so propose no models — and how you will split the shared workspace. **Name your own budget in that proposal** — the `budget:` line of the trigger block is what the board gave you (100 USD per month unless creation said otherwise), and since budgets accumulate along the reporting line it is the whole company's cap: every salary you propose has to fit inside it. If the plan does not fit, say so and ask for the number you need instead of proposing hires that will pause the company. End with the question, @-mention the creator, and **end the run** — nothing is hired, scheduled or filed before the answer. Write it in the organization's working language, the one the handbook's 「工作语言」 / “Working language” section names — as you write every message, ticket, document and brief from here on; commands, ids, file names and field names stay ASCII.
+2. **When the board confirms** (a mention or a message in your desk conversation), hire HR and finance, then the confirmed roles (`penguin org hire --new-agent <org_id>_<role> …`, default plugins).
+3. **Partition the shared workspace** as confirmed. You work in `ceo/` and every hire lands in a sub-directory of its own, so this is only for the partitions a stream rather than an employee should own: `penguin org employee set <agent_id> --workspace <sub-directory>` — a relative sub-directory is created as it is assigned, so it need not exist first.
+4. **Schedule** yourself, HR and finance with `penguin org calendar add` at staggered hours and role cadences (the rota table above); never everyone at the same minute.
+5. **File the confirmed tickets**: the parent per goal and the first children per stream, owners assigned, accepted into `in_progress` only for what the board confirmed. Assigning is where the work starts moving — each owner's desk picks its tickets up in its next sweep; start a ticket session yourself only for a ticket you own.
+6. **Open one channel per stream** (`penguin org channel create ch_<stream> --name …`) and invite its owner (`penguin org channel invite ch_<stream> agent:<agent_id>`), so a stream's thread does not drown the all-hands channel.
+7. **Report** to the creator in one message in the all-hands channel: whom you hired, how the workspace is split, what is scheduled, which channels are open, which tickets are open — and the next decision, if any, you need from the board.
+
+## Cautions
+
+- **Do the ticket work in ticket sessions**, not at your desk: your desk is the organization's scheduler, and its context must survive for months.
+- **Your budget is the organization's.** Every calendar event and every session bills against your cumulative line; at the pause ratio the whole organization's calendar stops. Hire and schedule within it, and take finance's proposals seriously.
+- **The handbook is yours to keep current.** When you change a role convention — who reviews, which priorities skip review, which channel a stream talks in — change `handbook/README.md`: it is what every employee reads first. `handbook/` is the company's knowledge base: record every decision the board took as `decisions/<yyyy-mm-dd>-<slug>.md` (the question, the answer, what it changes) and list it in the index, so a later run — yours or anyone's — reads the decision instead of asking again.