Operating Rhythms (Process as Fact)

Note: This document describes the operating process as "what it is (fact)". "How to run it (procedure)" is the responsibility of skills (/org-review, /hire-agent, etc.).

Approval Gates (Confirmed)

• HR changes (hiring, promotion, termination) = .claude/org/pending/ staging → final CEO approval → apply and commit.
• Setting and revising company goals = a separate category (does not reuse the HR ledger). Eden proposes a revision → CEO conversation approval → Notion updated + revision history in operations/goals/2026-goals-record.md. (Updating current KR values and status is gate-free.)
• Day-to-day task assignment is at the team-lead's discretion (no gate).

Regular Rhythms (Confirmed, 2026-07-15)

Confirmed with the introduction of the operating-rhythm system. Procedures are skills /report (reporting, goals, retrospectives) and /org-review (individual performance). Always-on automatic execution is Phase 2.

• Reporting: Daily (on active days) · Weekly (end of week) · Monthly (end of month). Activity-based — no report is produced for inactive periods. Living management is in Notion; records in operations/.
• Goal checkpoints: Mid-month / end-of-month (monthly) · every monthly retro (half-year progress) · half-year boundary (yearly). Revision requires the CEO approval gate.
• Retrospectives: Weekly (KPT, inside the report) · Monthly (closing + KPT, inside the report) · Half-year and yearly (separate strategic retro doc). Covers company goals and department performance (engineering = gstack:retro; individuals are separate from /org-review).
• Individual performance and persona evolution: End-of-month /org-review (runs in parallel with the cadence closing).
• Knowledge-base validation: npm run wiki:check (when documents change + monthly). Wiki regression tests: when skills/schema change (knowledge/_meta/README.md).
• Document freshness (introduced 2026-07-17): npm run docs:check — auto-runs on session-start hook + /report common pre-step 5. When a stale item is fixed, the regression rule (STALE_PATTERNS) is etched in one line (to prevent recurrence); confirmed-fact propagation targets are checked against operations/doc-registry.md (propagation map).

Notion Date Convention (Confirmed, 2026-07-16, CEO)

• A project period is always a start-to-end range. Entering only a start date renders as a single date and looks like a "past due date." Start date = actual kickoff date (planning-phase entries use the registration date).
• The due date is the target (expected) due date. The due date of an in-progress project is always read as the "we aim to finish by" expectation. No separate "expected completion date" field is used.
• On completion, replace the due date with the actual completion date — the timeline becomes a real history.
• A task deadline is also a target (expected) due date. Completion is confirmed by status = done (milestone check + due date = 🏁 milestone view and calendar).
• The same convention is stated in the Notion project and task DB descriptions. It applies to every expert who creates Notion projects and tasks.

Learning → Wiki Promotion (Confirmed)

• Session notes (.remember/) → agent growth log (reviews/) → verified team facts are promoted to knowledge/.
• Promotion conditions (one or more): reproduced 2+ times · "a fact the whole team must know" · session note survives 1+ day and shows value.

Token Efficiency Operating Principle (Added 2026-07-19 — W29 Report Trigger)

See [org-governance.en.md §Token Efficiency Operating Principle] for full text. This section documents the rhythm-related aspect only.

Session-level efficiency and named-agent use are now part of the team's operating habits. Effect is tracked in the W30 report (visibility, not evaluation).