godpowers 1.6.12 → 1.6.14

package/CHANGELOG.md

@@ -5,6 +5,62 @@ All notable changes to Godpowers will be documented in this file.
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
 and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
+## [1.6.14] - 2026-05-16
+
+Approved automation setup execution.
+
+### Added
+- Added `god-automation-engineer`, a specialist agent for approved host-native
+  automation setup.
+- Added automation execution-plan metadata to `lib/automation-providers.js`.
+- Added gated automation state recording helpers:
+  `buildAutomationRecord(...)` and `recordAutomation(...)`.
+- Added tests for host tool execution plans, complex setup delegation, and
+  post-success automation recording.
+
+### Changed
+- `/god-automation-setup` now distinguishes simple direct host tool calling
+  from complex setup that should spawn `god-automation-engineer`.
+- Setup plans now show method, action, host tool availability, specialist
+  agent routing, and the state file written after success.
+- Automation docs now explain that CLI commands are deterministic and
+  read-only, while slash-command hosts can use LLM tool calling after approval.
+
+### Guardrails
+- `.godpowers/automations.json` is written only after host setup succeeds.
+- Complex, write-capable, background-agent, scriptable-scheduler, or uncertain
+  setup routes through `god-automation-engineer`.
+
+## [1.6.13] - 2026-05-16
+
+Host automation provider discovery and opt-in setup planning.
+
+### Added
+- Added `lib/automation-providers.js`, a shared provider detector for
+  host-native automation support.
+- Added `godpowers automation-status --project .` and
+  `godpowers automation-setup --project .` for opt-in automation support.
+- Added `/god-automation-status` and `/god-automation-setup` slash commands.
+- Added `docs/automation-providers.md` with provider classes, safe templates,
+  and approval rules.
+- Added automation provider tests covering provider classification, active
+  automation config, setup-plan rendering, and CLI JSON output.
+
+### Changed
+- The dashboard engine now reports automation support when host-native
+  automation providers are available.
+- The installer help now documents automation-status and automation-setup as
+  first-class read-only helper commands.
+- Godpowers command guidance now recommends automation setup when provider
+  support exists and no approved automation template is active.
+
+### Guardrails
+- Automation setup is opt-in only. Godpowers must not create schedules,
+  routines, background agents, API triggers, or CI workflows during install.
+- Default automation templates are read-only and must not commit, push,
+  publish, deploy, clear reviews, accept Critical security findings, or access
+  provider dashboards without explicit user approval.
+
 ## [1.6.12] - 2026-05-16
 
 Executable dashboard CLI and shared runtime status engine.

package/README.md

@@ -2,7 +2,7 @@
 
 [![CI](https://github.com/aihxp/godpowers/actions/workflows/ci.yml/badge.svg)](https://github.com/aihxp/godpowers/actions/workflows/ci.yml)
 [![License: MIT](https://img.shields.io/badge/License-MIT-yellow.svg)](LICENSE)
-[![Version](https://img.shields.io/badge/version-1.6.12-blue)](CHANGELOG.md)
+[![Version](https://img.shields.io/badge/version-1.6.14-blue)](CHANGELOG.md)
 [![npm](https://img.shields.io/npm/v/godpowers.svg)](https://www.npmjs.com/package/godpowers)
 
 **Ship fast. Ship right. Ship everything. Ship accountably.**
@@ -12,10 +12,16 @@ idea to hardened production. It runs as **slash commands inside your AI coding
 tool** (Claude Code, Codex, Cursor, etc.) that orchestrate **specialist agents**
 in fresh contexts to do the work.
 
-Version 1.6.12 adds an executable dashboard engine and CLI status surface:
+Version 1.6.14 builds on the executable dashboard engine and CLI status surface:
 `godpowers status --project .` and `godpowers next --project .` now compute the
 same disk-derived progress, planning visibility, proactive checks, and next
 action used by `/god-status`, `/god-next`, and God Mode closeouts.
+It adds an opt-in automation-provider layer so Godpowers can detect host
+automation surfaces such as Codex App automations, Claude Routines, Cline
+schedules, Qwen loops, Cursor Background Agents, Copilot cloud agent, and
+scriptable CLI providers without silently creating background work.
+Approved setup can now use host tool calling for simple read-only automation
+or spawn `god-automation-engineer` for complex automation setup.
 
 It fuses four disciplines into one unified workflow:
 
@@ -139,6 +145,8 @@ npx godpowers status --project=. --json
 | `/god-launch` | Launch (gated on harden) | god-launch-strategist |
 | `/god-harden` | Adversarial security review | god-harden-auditor |
 | `/god-status` | Re-derive state from disk | (built-in) |
+| `/god-automation-status` | Show host automation provider support | (built-in) |
+| `/god-automation-setup` | Prepare opt-in automation setup | (built-in) |
 | `/god-preflight` | Read-only intake audit before project-run readiness and pillars | god-auditor |
 | `/god-audit` | Score artifacts against have-nots | god-auditor |
 | `/god-debug` | 4-phase systematic debug | god-debugger |
@@ -197,6 +205,18 @@ ends in a vague "done" state. The dashboard is backed by
 `lib/dashboard.js`, so status and next-step commands share one executable
 source of disk truth instead of parallel Markdown-only contracts.
 
+Godpowers can also inspect automation support:
+
+```bash
+npx godpowers automation-status --project=.
+npx godpowers automation-setup --project=.
+```
+
+Automation setup is opt-in. The installer does not create schedules, routines,
+background agents, API triggers, or CI workflows. Safe starting templates are
+read-only status, checkpoint, review queue, hygiene, and release readiness
+reports.
+
 For existing codebases and org-constrained new projects, God Mode now runs a
 greenfield simulation audit and then actions it through a greenfieldification
 plan. It pauses before risky artifact rewrites because that process can change
@@ -319,7 +339,7 @@ Pi. T3 Code inherits from the underlying agent (Codex / Claude / OpenCode).
 
 - [Getting Started](docs/getting-started.md)
 - [Concepts](docs/concepts.md)
-- [Command reference (all 106 skills + 39 agents)](docs/reference.md)
+- [Command reference (all 108 skills + 40 agents)](docs/reference.md)
 - [Roadmap](docs/ROADMAP.md)
 - [1.5 Release Notes](RELEASE.md)
 - [Changelog](CHANGELOG.md)

package/RELEASE.md

@@ -1,19 +1,21 @@
-# Godpowers 1.6.12 Release
+# Godpowers 1.6.14 Release
 
 Date: 2026-05-16
 
-Godpowers 1.6.12 turns progress visibility into executable product behavior.
-The same dashboard logic now powers slash command closeouts, direct CLI status
-checks, JSON status output, and next-action recommendations from disk state.
+Godpowers 1.6.14 turns automation setup from a plan-only contract into an
+approved execution contract for hosts that expose tool calling. The CLI remains
+deterministic and read-only, while `/god-automation-setup` can use host-native
+tool calling for simple read-only setup or spawn `god-automation-engineer` for
+complex setup.
 
 ## What is stable
 
-- 106 slash commands
-- 39 specialist agents
+- 108 slash commands
+- 40 specialist agents
 - 13 executable workflows
 - 36 intent recipes
 - 15-runtime installer
-- 453 package files in the npm tarball
+- 459 package files in the npm tarball
 - Codex installs with generated `god-*.toml` agent metadata files
 - Markdown specialist agent contracts at `<runtime>/agents/god-*.md`
 - Shared runtime bundle at `<runtime>/godpowers-runtime`
@@ -27,16 +29,13 @@ checks, JSON status output, and next-action recommendations from disk state.
 
 ## What is new
 
-- Added `lib/dashboard.js`, a shared executable status engine.
-- Added `godpowers status --project .`.
-- Added `godpowers next --project .`.
-- Added `--json` output for machine-readable status and next-step routing.
-- Dashboard output now reports current phase, tier position, percentage,
-  planning visibility, proactive checks, open items, and recommended action.
-- `/god-status`, `/god-next`, `/god-mode`, and `god-orchestrator` now reference
-  the same dashboard engine when local runtime execution is available.
-- Tests now cover dashboard computation, rendering, CLI output, review queue
-  detection, and git porcelain parsing.
+- Added `god-automation-engineer`.
+- Added automation execution-plan metadata to `lib/automation-providers.js`.
+- Added gated automation state recording helpers.
+- `/god-automation-setup` now shows direct host tool calling availability,
+  complex setup delegation, and the state recording path.
+- Tests now cover host tool execution plans, complex setup delegation, and
+  post-success automation recording.
 
 ## Platform behavior
 
@@ -45,11 +44,12 @@ Trae, Cline, Kilo, Antigravity, Qwen, CodeBuddy, and Pi all receive the same
 portable Markdown agent contracts. Codex also receives `god-*.toml` files as
 its registry adapter.
 
-The dashboard engine ships in the installed runtime bundle so host tools can
-use one shared implementation instead of parallel command-specific Markdown
-contracts. If a host platform cannot provide a true fresh-context agent spawn,
-Godpowers must say so visibly and report the work as local runtime only or
-simulated in current context.
+The dashboard and automation provider engines ship in the installed runtime
+bundle so host tools can use shared implementation code instead of parallel
+command-specific Markdown contracts. If a host platform cannot provide a true
+fresh-context agent spawn, durable scheduler, or callable automation tool,
+Godpowers must say so visibly and report the work as local runtime only,
+manual workflow only, or simulated in current context.
 
 ## Safety policy
 
@@ -62,21 +62,24 @@ Godpowers still must not auto-run these without explicit user intent:
 - deployed staging verification against a guessed URL
 - production launch
 - provider dashboard, admin console, DNS, credential, or secret checks
+- schedule, routine, background agent, API trigger, or CI workflow creation
 - broad dependency upgrades
 - destructive repair, rollback, reset, delete, or cleanup
 - clearing `.godpowers/REVIEW-REQUIRED.md`
 - accepting Critical security findings
 - git stage, commit, push, package, release, or publish
+- `.godpowers/automations.json` writes before host setup success
 
 ## Validation
 
 Release validation includes:
 
 - `node scripts/test-dashboard.js`
+- `node scripts/test-automation-providers.js`
 - `npm test`
 - `npm run test:audit`
 - `node scripts/check-package-contents.js`
 - `git diff --check`
 
-The `v1.6.12` git tag points to the release commit that matches the npm
-`godpowers@1.6.12` package.
+The `v1.6.14` git tag points to the release commit that matches the npm
+`godpowers@1.6.14` package.

package/SKILL.md

@@ -156,6 +156,7 @@ Proactive checks:
   Sync: <fresh | missing | stale | local helper ran | suggest /god-sync>
   Docs: <fresh | possible drift, suggest /god-docs>
   Runtime: <not-applicable | known URL, suggest /god-test-runtime | no known URL, defer deployed verification>
+  Automation: <not configured | N active | available via provider, suggest /god-automation-setup>
   Security: <clear | sensitive files changed, suggest /god-harden>
   Dependencies: <clear | dependency files changed, suggest /god-update-deps>
   Hygiene: <fresh | stale, suggest /god-hygiene>
@@ -235,6 +236,8 @@ Automatic steps that especially need visible reporting:
 - DESIGN/PRODUCT change detection that spawns `god-design-reviewer`
 - `/god-scan` when it runs reverse-sync directly without an agent
 - checkpoint refresh after state mutations
+- automation provider detection in `/god-status`, `/god-next`,
+  `/god-automation-status`, and `/god-automation-setup`
 
 ### 13. Proactive Auto-Invoke Policy
 Godpowers should be proactive from disk evidence, not from guesswork. Before
@@ -252,6 +255,9 @@ Run or apply these by default in every relevant closeout:
   status shows stale docs, deps, or review queues.
 - Suggest `/god-locate` when `.godpowers/CHECKPOINT.md` is missing, stale, or
   conflicts with `state.json`.
+- Suggest `/god-automation-status` or `/god-automation-setup` when host-native
+  automation support is available and `.godpowers/automations.json` has no
+  active read-only templates.
 
 #### Level 2: Auto-run local helpers, visible and logged
 Run these local runtime helpers automatically when their trigger is present:
@@ -280,6 +286,9 @@ Spawn these agents only when the trigger is direct and scope is bounded:
 - `god-deps-auditor` suggestion after dependency files changed; auto-spawn only
   inside `/god-update-deps`, `/god-hygiene`, or an explicitly approved project
   workflow.
+- `god-automation-engineer` after the user approves provider, template,
+  cadence, and scope for multi-template, write-capable, background-agent,
+  scriptable-scheduler, or provider-uncertain automation setup.
 
 #### Level 4: Explicit approval required
 Never auto-run these from inference alone:
@@ -291,6 +300,10 @@ Never auto-run these from inference alone:
 - clearing `.godpowers/REVIEW-REQUIRED.md`
 - accepting Critical security findings
 - git stage, commit, push, package, release, or publish
+- schedule, routine, background agent, API trigger, or CI workflow creation
+  without explicit user approval
+- `.godpowers/automations.json` writes before the host automation setup
+  reports success
 
 Every auto-invoke decision must be explainable from one of these inputs:
 changed files, Godpowers artifacts, `state.json`, `PROGRESS.md`,

package/agents/god-automation-engineer.md

@@ -0,0 +1,103 @@
+---
+name: god-automation-engineer
+description: |
+  Configures approved host-native Godpowers automation after the user chooses
+  provider, template, cadence, and scope. Verifies the host setup and records
+  only successful automations in .godpowers/automations.json.
+
+  Spawned by: /god-automation-setup
+tools: Read, Write, Edit, Bash, Glob
+---
+
+# God Automation Engineer
+
+Configure approved host-native automation without pretending a background
+surface exists when it does not.
+
+## Gate Check
+
+The user explicitly approved:
+
+- provider id
+- template ids
+- cadence
+- project or repository scope
+- whether the automation is read-only or write-capable
+
+If any approval field is missing, stop and return the missing field list.
+
+## Process
+
+1. Read `.godpowers/automations.json` if it exists.
+2. Load `lib/automation-providers.js` from the installed runtime bundle or
+   repository.
+3. Call `automation.setupPlan(projectRoot, { templates })`.
+4. Confirm the chosen provider is installed and matches the approved provider.
+5. Execute only through a confirmed host surface:
+   - Codex App: call the host automation tool when available.
+   - Claude Code: use the host schedule or routine surface.
+   - Cline: use `cline schedule` only when that CLI is available.
+   - Qwen: use `/loop` only for session-scoped recurring prompts.
+   - Cursor or Copilot: use branch or PR scoped background agent setup.
+   - Scriptable CLIs: use an approved scheduler. Do not invent OS scheduling.
+6. After host setup succeeds, call `automation.buildAutomationRecord(...)`.
+7. Call `automation.recordAutomation(projectRoot, record, {
+   confirmedHostSuccess: true
+   })`.
+8. Run `/god-automation-status` or the equivalent local helper and report the
+   active state.
+
+## Tool Calling Policy
+
+Use direct host tool calling only when all of these are true:
+
+- one approved read-only template
+- one detected provider
+- no provider dashboard, credential, billing, DNS, production, or repository
+  write scope is required
+- the host exposes a native scheduling or automation tool in the current
+  session
+
+If the host lacks a callable tool, return exact manual setup steps. Do not
+claim setup succeeded.
+
+## Hard Stops
+
+Never create or approve automation that can do these unless the user explicitly
+approved that exact write-capable action:
+
+- stage, commit, push, merge, package, publish, or release
+- deploy to staging or production
+- access provider dashboards, DNS, credentials, secrets, or billing
+- clear `.godpowers/REVIEW-REQUIRED.md`
+- accept Critical security findings
+- run broad dependency upgrades
+- delete files, reset branches, or clean worktrees
+
+Never write `.godpowers/automations.json` before the host setup succeeds.
+
+## Output
+
+Return:
+
+```text
+Automation setup result:
+  Provider: <provider id>
+  Templates: <template ids>
+  Host surface: <tool, command, routine, or manual>
+  Status: <created | manual steps required | blocked>
+  Recorded: <yes | no>
+  Config: .godpowers/automations.json
+  Next: /god-automation-status
+```
+
+## Have-Nots
+
+- Records automation before host setup succeeds
+- Creates background work during install
+- Treats a manual workflow as durable scheduling
+- Uses OS or CI scheduling without explicit approval
+- Grants write scope for a read-only template
+- Uses provider dashboards or credentials without explicit approval
+- Claims an automation is active without re-checking status
+- Hides provider limitations from the user

package/agents/god-orchestrator.md

@@ -310,12 +310,16 @@ Use this trigger map:
 | frontend-visible files changed and no known URL exists | suggest `/god-test-runtime` with local URL setup, defer deployed URL | proposition |
 | security-sensitive files changed | auto-spawn only inside harden, hotfix, launch, or project run; otherwise suggest `/god-harden` | proposition |
 | dependency files changed | auto-spawn only inside update-deps, hygiene, or approved project run; otherwise suggest `/god-update-deps` | proposition |
+| host automation support detected and no active templates are recorded | suggest `/god-automation-status` or `/god-automation-setup` | proposition |
+| user approves complex automation setup | spawn `god-automation-engineer` | approval card plus setup result |
 | full project run complete or hygiene stale | suggest `/god-hygiene` | proposition |
 
 Never use this matrix to auto-run Level 4 actions: deployed staging against a
 guessed URL, production launch, provider dashboard access, broad dependency
 upgrades, destructive repair, review clearing, Critical security acceptance, or
-git stage, commit, push, package, release, or publish.
+git stage, commit, push, package, release, publish, schedule creation, routine
+creation, background agent creation, API trigger creation, or CI workflow
+creation without explicit user approval.
 
 Every auto action must emit either `Auto-invoked:`, `Sync status:`, or a
 proposition explaining why it did not run.

package/bin/install.js

@@ -316,6 +316,8 @@ function parseArgs(argv) {
     switch (arg) {
       case 'status':
       case 'next':
+      case 'automation-status':
+      case 'automation-setup':
         opts.command = arg;
         break;
       case '--json':
@@ -571,10 +573,12 @@ function showHelp() {
   log('Commands:');
   log('  status               Show the Godpowers Dashboard for a project');
   log('  next                 Show the dashboard and recommended next command');
+  log('  automation-status    Show host automation provider support');
+  log('  automation-setup     Show an opt-in automation setup plan');
   log('');
   log('Options:');
-  log('  --project=<path>     Project root for status or next (default: cwd)');
-  log('  --json               Emit JSON for status or next');
+  log('  --project=<path>     Project root for status, next, or automation commands');
+  log('  --json               Emit JSON for status, next, or automation commands');
   log('  -g, --global         Install globally (to config directory)');
   log('  -l, --local          Install locally (to current directory)');
   log('  --claude             Install for Claude Code');
@@ -599,11 +603,27 @@ function showHelp() {
   log('Examples:');
   log('  npx godpowers status --project=.');
   log('  npx godpowers next --project=.');
+  log('  npx godpowers automation-status --project=.');
+  log('  npx godpowers automation-setup --project=.');
   log('  npx godpowers --claude --global');
   log('  npx godpowers --all');
   log('  npx godpowers --codex --cursor');
 }
 
+function runAutomationCommand(opts) {
+  const automation = require('../lib/automation-providers');
+  const result = opts.command === 'automation-setup'
+    ? automation.setupPlan(opts.project)
+    : automation.detect(opts.project);
+  if (opts.json) {
+    console.log(JSON.stringify(result, null, 2));
+  } else if (opts.command === 'automation-setup') {
+    console.log(automation.renderSetupPlan(result));
+  } else {
+    console.log(automation.render(result));
+  }
+}
+
 function runDashboardCommand(opts) {
   const dashboard = require('../lib/dashboard');
   const result = dashboard.compute(opts.project);
@@ -636,6 +656,11 @@ function main() {
     return;
   }
 
+  if (opts.command === 'automation-status' || opts.command === 'automation-setup') {
+    runAutomationCommand(opts);
+    return;
+  }
+
   console.log(BANNER);
 
   const srcDir = path.resolve(__dirname, '..');