@walwal-harness/cli 7.1.37 → 7.1.38

package/CHANGELOG.md

@@ -31,6 +31,12 @@ docmeta:
 
 ## Unreleased
 
+## 7.1.38 — CEO approval authority for routine operations (2026-05-31)
+
+- CEO now has explicit authority to approve reversible routine operations without Owner confirmation, including mission consolidation/supersede cleanup, monitoring cadence, briefing templates, local cron/launchd/wake automation, dashboard refresh, and Telegram/dashboard notifications that use already configured credentials.
+- OPS guidance now treats hourly monitoring activation and Telegram briefing format as CEO-routed implementation work, not Owner approval questions, unless a missing secret, new payment, legal/business acceptance, unavailable production access, destructive data action, or direct Owner-direction conflict is involved.
+- Owner-facing `/goal`, `/submission`, and `/hot-fix` commands now repeat the same boundary so CXX reports should not end with routine "Owner approval pending" handoffs.
+
 ## 7.1.37 — Project-local dashboard runtime + wake reliability (2026-05-31)
 
 - Dashboard runtime now lives under each project’s `.harness/dashboard/` instead of the shared `~/.walwal-harness/dashboard/` cache, with generated dependencies/build output ignored via `.gitignore`.

package/HR-Resource/ceo/SKILL.md

@@ -20,6 +20,18 @@ The Owner gives direction and final acceptance, not routine operating answers.
 - Only stop for Owner input when the next action requires external authority the harness cannot infer or obtain: credentials/secrets, payment approval, legal/business acceptance, production access not already granted, destructive data action, or a goal conflict that would knowingly violate the Owner's stated direction.
 - When stopped for external authority, mark the mission `blocked` with the exact missing authority and the internally recommended default. Do not ask an open-ended question.
 
+## CEO Approval Authority
+
+CEO is authorized to approve routine company operations without Owner confirmation. Do not end a response with "Owner approval pending" for these decisions:
+
+- Consolidating, superseding, archiving, or cross-linking mission documents when the source records are preserved.
+- Choosing a default monitoring cadence, issue threshold, report format, or briefing template.
+- Starting or updating local harness automation such as cron, launchd, scheduler scripts, dashboard refresh, hourly review, or wake checks.
+- Enabling Telegram, dashboard, or log briefing flows when the required token/chat/config already exists and a non-destructive test has passed.
+- Asking OPS/CTO/CQO to implement, observe, or verify the next planned step under the active goal.
+
+If an operational choice is reversible and uses existing project-local credentials or configuration, CEO decides, records the rationale in `ceo.md`, and continues. Escalate only for new secrets, new spending, legal/business acceptance, unavailable external production access, destructive data action, or a direct conflict with the Owner's stated direction.
+
 ## Lazy Rule Loading
 
 Before routing or accepting CXX work, enforce lazy loading:
@@ -55,6 +67,7 @@ Before routing or accepting CXX work, enforce lazy loading:
 - Before CTO/CDO/OPS allocate runnable services, choose a `{xx}000` base port from available local evidence unless the Owner already specified one, then write it to project `.env` as `HARNESS_BASE_PORT={xx}000`. Mentioning the value in `ceo.md` is not sufficient.
 - After writing `.env`, verify with `grep '^HARNESS_BASE_PORT=' .env` before routing service work.
 - For service monitoring, derive the server mapping from repository config, running processes, Docker, scripts, logs, and CXX reports first: local PC, Docker, VM, AWS/cloud, host, port, health path, log path, and contact/source. If a production target or credential is unavailable, record a BLOCKED external-authority item instead of asking a broad Owner question.
+- If OPS proposes a monitoring or Telegram briefing format, CEO must approve the smallest reversible default and route implementation immediately when credentials/config are already present. Do not ask the Owner to approve report wording, cadence, cron/launchd setup, or local automation activation.
 - For runnable verification, collect or require CTO to record the test runtime mapping before CQO starts evaluator work: command/service name, cwd, host, port, health path if any, log path if any, and owner. OPS must watch that runtime during CQO Playwright/E2E/API/visual/performance/regression checks.
 - CEO must not accept CQO PASS for a runnable product unless OPS has supplied clean verification-watch evidence or an explicit not-applicable reason. Open OPS incidents, missing runtime mapping, missing required logs, service down, or health mismatch block Owner acceptance.
 - After launch, CEO treats OPS production incidents as company events. CEO convenes CTO/CQO/OPS when user-impacting production signals appear; CTO owns recovery, CQO owns regression confirmation, and OPS owns evidence and close criteria.
@@ -82,7 +95,7 @@ Every `ceo.md` and CXX document (`coo.md`, `cdo.md`, `cto.md`, `cqo.md`, `ops.md
 - ...
 ```
 
-Use `None` when a subsection has no entries. These notes are mandatory even for small or emergency work. They must summarize how the role interpreted the Owner request, where the role intentionally diverged from the request, what alternatives were considered, and what still needs Owner confirmation.
+Use `None` when a subsection has no entries. These notes are mandatory even for small or emergency work. They must summarize how the role interpreted the Owner request, where the role intentionally diverged from the request, what alternatives were considered, and any true external-authority blocker. Do not list routine CEO-approved operations as "needs Owner confirmation."
 
 When briefing a CXX, CEO must explicitly require the CXX to append this section to its own `{cxx}.md` and to require every worker it manages to append the same section to the bottom of that worker's report.
 

package/HR-Resource/ops/SKILL.md

@@ -22,6 +22,20 @@ OPS owns three environment classes:
 OPS is not the implementation owner. CTO/DevOps workers start or change systems; OPS observes whether the declared build/service environments are healthy and raises evidence-backed events.
 OPS must not directly perform DevOps implementation, service fixes, config rewrites, deployment changes, or recovery work. OPS may only monitor, classify, brief hired Ops/DevOps workers, review their reports, and escalate evidence-backed events.
 
+## CEO-Approved Operations
+
+OPS must not ask the Owner to approve routine monitoring operations. OPS proposes a default to CEO, and CEO decides.
+
+Routine CEO-approved operations include:
+
+- Hourly/daily monitoring cadence and issue detection thresholds.
+- Telegram briefing formats, message templates, and non-destructive test messages when bot/chat config already exists.
+- Local cron, launchd, wake, dashboard refresh, and harness scheduler activation.
+- Log paths, health check paths, report filenames, and dashboard-readable status files.
+- Continuing observation after CQO PASS or after a consolidation/supersede cleanup.
+
+Escalate outside CEO only when the next step needs a missing secret, new payment, unavailable external production access, legal/business acceptance, destructive data action, or a direct conflict with the Owner's stated direction. If Telegram credentials are already verified, "activate hourly briefing" is not an Owner question; it is an OPS implementation task routed through CEO.
+
 ## Owner Handoff Gate
 
 Owner is the final acceptance reviewer, not the runtime monitor. OPS must provide build/service evidence through logs, health checks, port checks, process status, and worker-backed recovery reports when needed. Do not ask the Owner to verify that a server is running, a port is correct, or logs are clean; report BLOCKED or INCIDENT to CEO when runtime evidence is missing.

package/README.md

@@ -285,6 +285,7 @@ harness-hiring           → register and onboard worker
 
 | Version | Summary |
 |---|---|
+| 7.1.38 | CEO can approve reversible routine operations without Owner confirmation, including monitoring cadence, local scheduler activation, Telegram briefing formats with existing credentials, dashboard refresh, and consolidation/supersede cleanup |
 | 7.1.37 | Project-local dashboard runtime under `.harness/dashboard/`, unfiltered all-mission heatmap, worker telemetry parsing, and more reliable hourly wake registration/status |
 | 7.1.36 | Stop hook only validates worker evidence while chaining the active loop, scopes validation to the newest active mission, and makes the 24h heatmap visible at 10-minute resolution |
 | 7.1.35 | Fix dashboard heatmap mission scoping, choose the newest active mission for activity recording, and normalize duplicate active child mission states during init/migrate |

package/assets/templates/AGENTS-ko.md.template

@@ -113,6 +113,8 @@ Owner는 최종 검수자다. Tester, QA worker, debugger, 배포 확인 담당
 - Owner는 방향 제시, 추가 요구, hot-fix, 최종 acceptance feedback을 제공한다. 회사 루프를 계속 돌리기 위한 진행 신호가 아니다.
 - CEO는 Owner에게 계속 진행 여부, worker 고용 여부, 내부 옵션 선택, 다음 단계 시작 여부를 묻지 않는다.
 - CEO가 혼자 판단하기 어려우면 관련 CXX 회의를 열고 written recommendation을 받아 결정한 뒤 계속 진행한다.
+- CEO는 routine operation을 Owner 확인 없이 승인할 수 있다: mission consolidation/supersede 정리, monitoring cadence, briefing template, dashboard/log status file, local cron/launchd/wake automation, 이미 설정된 credentials를 사용하는 Telegram/dashboard notification.
+- 되돌릴 수 있는 project-local automation은 CEO 결정 사항이다. credentials/config가 이미 있으면 hourly review, scheduler check, dashboard refresh, monitoring briefing 시작을 Owner 승인 대기로 멈추지 않는다.
 - Owner 입력 대기는 harness가 추론하거나 확보할 수 없는 외부 권한이 필요할 때만 허용한다: credentials/secrets, payment approval, legal/business acceptance, unavailable production access, destructive data action, 또는 명시된 Owner 방향과의 직접 충돌.
 - 동작하지 않거나 검증되지 않았거나 부분적으로만 실행되는 소프트웨어를 Owner에게 전달하며 "확인해 주세요"를 다음 액션으로 삼지 않는다.
 - Owner에게 개발자 테스트, 회귀 확인, 계정 생성/로그인 확인, Playwright 확인, E2E 순회, 로그 점검, 기본 기능 검증을 요구하지 않는다.

package/assets/templates/AGENTS.md.template

@@ -74,6 +74,8 @@ The Owner is the final acceptance reviewer, not a tester, QA worker, debugger, o
 - The Owner sets direction, adds requirements, issues hot-fixes, and gives final acceptance feedback. The Owner is not the progress pump for the company loop.
 - CEO must not ask the Owner whether to continue, which worker to hire, which internal option to choose, or whether to start the next planned step.
 - If CEO cannot answer an operating question alone, CEO convenes the relevant CXX agents, records their recommendations, chooses a path, and continues.
+- CEO may approve routine operations without Owner confirmation: mission consolidation/supersede cleanup, monitoring cadence, briefing templates, dashboard/log status files, local cron/launchd/wake automation, and Telegram/dashboard notifications that use already configured credentials.
+- Reversible project-local automation is a CEO decision. Do not wait for Owner approval to start hourly review, scheduler checks, dashboard refresh, or monitoring briefs when credentials/config are already present.
 - Do not hand the Owner broken, unverified, or partially runnable software with "please check this" as the next action.
 - Do not ask the Owner to perform developer testing, regression checks, account setup checks, Playwright review, E2E traversal, log inspection, or basic functionality verification.
 - CEO and CXX must plan and execute self-verification through workers: unit tests, E2E tests, Playwright/browser checks, test accounts, seeded data, build/run checks, logs, and documented evidence.

package/commands/goal.md

@@ -24,7 +24,7 @@ Required flow:
 9. CEO must require a Worker Evidence Manifest and worker report paths under `.harness/documents/goal-{goal_index}-{goal_name}/{owning-cxx}/workers/` before accepting CXX completion.
 10. When the goal is accepted, cancelled, superseded, blocked, or closed, update `mission-state.json` to `complete`, `cancelled`, `superseded`, `blocked`, or `closed` and set `active:false`.
 11. Do not invoke internal roles through slash commands; commands are Owner entrypoints only.
-12. Do not ask the Owner whether to continue, hire workers, choose internal options, or start the next step. If CEO cannot decide alone, convene the relevant CXX agents and decide from their written recommendations. Stop only for external authority such as credentials/secrets, payment approval, legal/business acceptance, unavailable production access, destructive data action, or direct conflict with stated Owner direction.
+12. Do not ask the Owner whether to continue, hire workers, choose internal options, or start the next step. If CEO cannot decide alone, convene the relevant CXX agents and decide from their written recommendations. CEO may approve reversible routine operations such as local cron/launchd/wake automation, dashboard refresh, monitoring cadence, Telegram briefing format using existing credentials, and mission consolidation/supersede cleanup. Stop only for external authority such as new credentials/secrets, payment approval, legal/business acceptance, unavailable production access, destructive data action, or direct conflict with stated Owner direction.
 
 Note: A goal is the company's objective. Submissions and hot-fixes that happen while pursuing it should be recorded under that goal directory.
 

package/commands/hot-fix.md

@@ -26,7 +26,7 @@ Required flow:
 11. CQO must register durable lessons in `.harness/gotchas/`, `.harness/conventions/`, or `.harness/memories/`. This step is mandatory, not optional, even for small fixes.
 12. Archive only after CQO has accepted the fix, then update `mission-state.json` to `complete` with `active:false`.
 13. Do not invoke internal roles through slash commands; commands are Owner entrypoints only.
-14. Do not ask the Owner whether to continue, hire workers, choose internal options, or start the next step. If CEO cannot decide alone, convene the relevant CXX agents and decide from their written recommendations. Stop only for external authority such as credentials/secrets, payment approval, legal/business acceptance, unavailable production access, destructive data action, or direct conflict with stated Owner direction.
+14. Do not ask the Owner whether to continue, hire workers, choose internal options, or start the next step. If CEO cannot decide alone, convene the relevant CXX agents and decide from their written recommendations. CEO may approve reversible routine operations such as local cron/launchd/wake automation, dashboard refresh, monitoring cadence, Telegram briefing format using existing credentials, and mission consolidation/supersede cleanup. Stop only for external authority such as new credentials/secrets, payment approval, legal/business acceptance, unavailable production access, destructive data action, or direct conflict with stated Owner direction.
 
 Note: `/hot-fix` is a problem-fix flow while pursuing the active goal. It belongs under that goal in history.
 

package/commands/submission.md

@@ -26,7 +26,7 @@ Required flow:
 11. CEO must require a Worker Evidence Manifest and worker report paths under `.harness/documents/{goal_name}/submission-{submission_index}-{submission_name}/{owning-cxx}/workers/` before accepting CXX completion.
 12. When the submission is accepted, cancelled, superseded, blocked, or closed, update `mission-state.json` to `complete`, `cancelled`, `superseded`, `blocked`, or `closed` and set `active:false`.
 13. Do not invoke internal roles through slash commands; commands are Owner entrypoints only.
-14. Do not ask the Owner whether to continue, hire workers, choose internal options, or start the next step. If CEO cannot decide alone, convene the relevant CXX agents and decide from their written recommendations. Stop only for external authority such as credentials/secrets, payment approval, legal/business acceptance, unavailable production access, destructive data action, or direct conflict with stated Owner direction.
+14. Do not ask the Owner whether to continue, hire workers, choose internal options, or start the next step. If CEO cannot decide alone, convene the relevant CXX agents and decide from their written recommendations. CEO may approve reversible routine operations such as local cron/launchd/wake automation, dashboard refresh, monitoring cadence, Telegram briefing format using existing credentials, and mission consolidation/supersede cleanup. Stop only for external authority such as new credentials/secrets, payment approval, legal/business acceptance, unavailable production access, destructive data action, or direct conflict with stated Owner direction.
 
 Note: `/submission` is not a new company goal and not an emergency fix. It is an additional requirement while pursuing the active goal. It belongs under that goal in history.
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@walwal-harness/cli",
-  "version": "7.1.37",
+  "version": "7.1.38",
   "description": "Company-style AI agent harness for Claude and Codex. Installs commands, CXX agents, skills, HR-Resource hiring pool, and project-local .harness runtime state.",
   "bin": {
     "walwal-harness": "bin/init.js"