Integrated team-move F candidate handoff (THR296seq135)

Founder-controlled teams move capability/preview/apply/show/recover now has
public service/CLI source. F proposes APPLY_AVAILABLE=True with actual native
apply AND recovery readiness gates; whole-feature independent acceptance and
manager guarded merge remain required. Skills/agents gain no execution or
ambient-bearer self-admission authority. Manage-agent retains team/role; transfers use the
separate admitted founder operation. Preview uses only the pure native planner,
not materializers/resets/reservations. Exact normalized client bytes/key are
privately fsynced before POST, including exact saved-file reuse/apply reads;
a complete prior failed-save file requires fresh descriptor/byte validation,
file fsync/close and containing-directory fsync/close. Partial/changed bytes
refuse without overwrite/new key; same-UID limitations remain. Preserve key on
transport loss and use same-key
show, never automatic second apply. HTTP202/CLI3 is in-flight, saved COMPLETE
readback/release alone permits apply200/CLI0; refusal/repair is1, parser2.
Show is read-only; recover explicitly binds SAME ID/revision and native prior
owner/process proof/CAS. Durable daemon tasks survive client disconnect; shutdown
reaps them before DB close without clearing holds. Diagnostic-org read/recovery
uses strict native owners, closes before positive normal attachment and clears
only after successful native map insertion. Native dedup redelivery follows.
Show/recover diagnostics distinguish strict saved bounded code/owner IDs and
original/latest recovery/publisher identities from current native census and
publisher owner observations. Diagnostic-only reads require no ordinary attachment
or preview; unavailable ownership stays unknown. Async failure/secondary close
or attachment facts are safe process-local observations, never durable evidence.
Resolve named dependencies before explicit SAME operation/target/revision recovery;
no automatic retry or TTL takeover. Both show GET forms declare202/CLI3 in-flight.
D staging/history/leases, C1-C3 uncertainty/EMPTY budgets and actual callbacks
remain. Earlier unavailable-E statements below describe historical checkpoints.
Current contract: docs/superpowers/specs/2026-10-14-online-team-move.md and
engineering-owned docs/runbooks/online-team-move.md. F candidate source,
independent acceptance/merge, separately authorized release loading and exact
Founder live operation are distinct. Shared bearer does not prove human presence. Behavior
UNEXECUTED, integration INCLUDING callback SKIPPED24342, units RETIRED; no new
cases/campaign, live operation, deployment or cleanup authority follows.

F native release preparation runs through OrgState.load: strict read-only move
discovery precedes naming preflight, generic compatibility writes, roster
validation, publication and producer admission. After complete native workflow
validation, the DB-owned install_team_move_schema transaction validates exact
existing layout/history/org identity, refuses held/unknown state, installs only
the literal ONE table if absent, and validates before COMMIT. Repeated compatible
attachment is idempotent. Generic Database/runtime-audit, capability/preview/show
and restricted diagnostic recovery never install or repair it. Source delivery
does not call it on production: separately authorized compatible release loading
through the supported launcher performs native preparation; Founder assembles
no files, SQL or offline manifest. Missing schema/owners are engineering release
dependencies. Even an empty installed table requires reader@3. An absent optional
layout remains compatible with generic/older readers; source rollback cannot
undo durable state or grant a downgrade.

F also freezes C2 thread retry initialization explicitly, including EMPTY
budgets. New initial/fallback/nudge phase initialization is distinct from a
frozen zero budget; deferral/reentry cannot replenish it. Old missing facts keep
their original history interpretation but refuse ambiguous new retry/reentry
with team_move_thread_retry_initialization_unknown; no history is backfilled.
Updated shell/Mac launchers require online-team-move@3 (reads old @1/@2), so
earlier supported parsers refuse before startup. Already-running old daemons,
obsolete launchers and unchecked old interpreters remain outside that guard.
All behavioral/installation/recovery/launcher observations remain UNEXECUTED.

Historical task attribution is separate from current launch eligibility. The
complete parent/child/revisit/chain/fanout/workflow closure retains task team keys,
recorded participants and permanent IDs, including retired actors authenticated
by the existing strict naming owner or native INTEGER task/result/SID attribution.
It never resolves settled history through today's manager or requires re-enrollment.
Unknown identity/graph facts remain actionable census blockers without discarding
collected inventory; dependent sessions/jobs/recovery callbacks/workflows remain
joined even for terminal tasks. New execution still requires a current executable
owner. No historical record, team, callback or binding is rewritten.

The SAME INTEGER thread invocation/agent/SID preparation owner spans native
materialization, integrity, repository refresh and launch-spec/cache preparation,
including helper-internal omissions and caught failures. Such uncertainty appends
the existing sticky failed_cleanup fact BEFORE ordinary failure settlement;
backend preparation/cleanup and native workspace/cache failures retain ownership.
Later success/callback/terminal state cannot erase it. Serializer, audit COMMIT,
strict history reader, restart/reentry and census preserve that fact, independently
of frozen EMPTY/nonempty retries. Ordinary stale-claim/agent/breaker or missing
launch-seam refusals before effects retain their native no-effect disposition;
returned failure alone never proves compensation. No new schema/journal/backfill
or generic producer identity is introduced. All behavior remains UNEXECUTED.

Ordinary tasks carry their SAME native TaskInvocation/task/agent/runtime SID
through materialization, integrity (including retries), package omissions,
repository refresh, attachment writes/cleanup, task scratch and builtin/custom
cache/workspace setup. Safe deferred ownership becomes durably prepared before
preparation resumes; this never clears existing uncertainty.
Preparation failure sets the existing local reservation cleanup flag BEFORE the
fallible strict Pause save/COMMIT, then retains execution_unknown/unknown in
the admitted journal. Terminal/callback/quiescent later attempts and safe unrelated
worktree cleanup cannot clear it. Settlement persists that fact before release;
failed saves retain local ownership and original plus persistence errors.
Restart treats unclosed task prepared entries as unknown, including terminal
rows and prepared recovery/retry owners; absence of first launch is no proof of
preparation cleanup. Unknown deferred entries cannot authorize a fresh launch.
Native pre-effect source/artifact validation, repo-scan and missing launch-seam refusals
retain their no-effect disposition. Existing retry/recovery IDs, frozen budgets,
INTEGER callbacks and authority-v2 are preserved. No new field/journal, history
backfill, compensation or clearance writer is introduced. Behavior UNEXECUTED.

D private operation and startup holds (THR296seq135)

The corrected reader is online-team-move@3 (also reads old @1/@2 records); supported
launchers pass --reader-guarded-start=online-team-move@3 and reject earlier D
readers. Per-org open/identity/SQLite errors remain diagnostic-only and survive
startup/switch readback. Restricted recovery preserves the original error on
close failure; standalone close failures retain native classification and holds.
Recovery reconciles only pre-recorded operation staging
intent/acquired identity/terminal disposition in existing audits. Unknown acquired
identity or cleanup stays held even after owner-finished; no glob deletion or
legacy evidence adoption is allowed. Native discovery and publication capture
run outside durable profile/publication mutation leases, with revision/epoch/CAS
revalidation before mutation and at final release. This grants no skill execution,
cleanup, activation, live operation or behavioral-proof authority.

Global/rebind/claim/retry/synchronization profile writers retain diagnostic roots
and refuse without diagnostic filesystem/DB acquisition while leased, even with
EMPTY dependencies.
Adapter removal reports the retained EMPTY-dependency diagnostic refusal as
HTTP409 with detail.code; its bounded ProfileCoordinatorError translation
preserves unrelated exceptions and native removal/audit/compensation.
Native startup/attachment performs positive inspection
outside leases. Matching attachment revalidates its actual already-open DB owner
in the short segment; only successful attachment clears its diagnostic. Other
roots, failed attachment, current holds and malformed history stay held. D's
own-operation/native-identity exception also checks EMPTY dependencies. Public
recovery/reattachment is source-wired by E and gated on actual native owners by F; no skill authority is granted.

D supplies private canonical/context/reset/profile/publication/recovery source.
E supplies public API/CLI source; F proposes reviewed source enablement with
separate actual apply/recovery readiness gates;
no skill or agent may invoke the private owner or use ambient bearer credentials
to self-admit a move. Manage-agent still cannot transfer teams. New startup
schema-owner discovery precedes compatibility writers and partial membership;
unknown/unresolved state keeps that org diagnostic-only and its durable holds.
Only admitted bounded same-operation recovery can reconcile exact owned images
and native owner evidence; no timeout, missing tracker or source rollback releases
it. Updated launchers require the guarded reader protocol; old running daemons
and arbitrary direct old interpreters remain outside that protection. Source
and static checks do not prove behavior. No activation/restart/live move, new
tests/campaign, callback fabrication or cleanup authority follows. Earlier C3
checkpoint text below records that slice only; current D disposition is in
docs/superpowers/specs/2026-10-14-online-team-move.md. SAME13 observations stay;
behavior/recovery UNEXECUTED, integration INCLUDING callback SKIPPED24342,
Python units RETIRED. Native permission/execution enforcement is unchanged.

Current names and permanent automation IDs

Fresh prompts may show current Name · ID for this turn. Use the permanent ID
from the injected parameters for callback agent/composer/speaker, task/session/
invocation proofs, configuration and delegate/then/fanout targets. A name is
human-addressing/presentation data, never actor authority. Human destination
arguments and @mentions accept current names or IDs; former names refuse with
the current name and do not forward. Founder is a separate human; recipient
transport remains @founder. Metadata failure gives ID-only context.

Human Todo-list filters accept current names; schedules create/spawn payload agent and self/session checks remain permanent-ID-only. No scheduling authority changes.

Todos — Agent-owned scheduled commitments (THR-105 v2)

Native C3 preparation failure or ordinary process return never proves file,
package or process cleanup. Unknown ownership remains in retained audit census.
New retry budgets explicitly freeze even an empty schedule; missing legacy facts
cannot authorize replenishment/reentry. Schedule runtime SID is pinned through
real preparation/spec/execution and is distinct from provider resume identity.
Custom-skill authority validates before reservations; only explicit native
validation/rollback/temporary-cleanup evidence can settle a refused writer.
No history deletion, automatic recovery, apply or execution authority follows.

An online team-move hold preserves pending schedules before claim and missed/expiry bookkeeping. The native owner reevaluates ordinary deadlines after release with current context; never shift recurrence, invent catch-up or create a replacement schedule. Stable permanent-ID schedules can remain; retired-team content or unsupported bindings need explicit owner resolution. Firing/session ownership blocks a move. Apply is unavailable; behavior remains UNEXECUTED.

Agents may create one_shot, weekly, and recurring self-scheduled Todos via the
schedules create callback. This is a self-only, explicit-instruction,
session-bound operation available to every valid in-org agent. You cannot
schedule another agent, you cannot infer or proactively create future work, and
the skill body is discoverability only — it does not bypass server validation.

Preconditions

1. Founder/operator instruction only. Only create a Todo when the
   founder or an operator has explicitly told you to schedule something.
   Never infer, guess, or proactively arm a schedule.

2. You must be a valid in-org caller. Every agent with an active session
   and a resolvable in-org team may create a self-owned Todo. Legacy
   scheduling.enabled_agents configuration is accepted but has no effect.

3. Self-target only. Agents must create Todos only for themselves
   and must never target another agent. The agent field must match
   your own agent name — the server validates it against the active
   session.

4. Normalize before arming. Before firing the callback, turn the
   founder/operator instruction into a concrete, founder-reviewable
   normalized_brief — a self-contained task brief that any engineer
   reading the Todo list would understand without extra context:
   "Run the weekly user-growth report and post it to #metrics" is good;
   "do the thing from yesterday" is not. source_instruction records
   the original request verbatim.

The single-line callback

happyranch schedules create --org {ORG_SLUG} --from-file /tmp/schedule-<task_id>.json

All happyranch examples MUST be single-line and use --from-file with a
pre-written JSON payload file. Multi-line bash is rejected by executor
permission matchers.

Payload shape (--from-file file)

{
  "task_id":      "TASK-XXX",
  "session_id":   "sess-…",
  "agent":        "your_agent_name",
  "source_instruction": "verbatim founder/operator instruction",
  "normalized_brief":   "self-contained, reviewable task brief",
  "kind":         "one_shot | weekly | recurring",
  "fire_at":      "2026-08-07T18:00:00+08:00",
  "recurrence":   null,
  "timezone":     "UTC"
}

Field	Required	Notes
task_id	✓	Your current task id
session_id	✓	Your current session id
agent	✓	Your agent name (validated against the active session)
source_instruction	✓	Verbatim instruction — kept for audit, never edited afterward
normalized_brief	✓	Self-contained, founder-reviewable brief — immutable after creation
kind	✓	"one_shot", "weekly", or "recurring"
fire_at	✓ except native recurring with start_date	ISO-8601 with an explicit timezone offset (+00:00, +08:00, or Z); omit for the server-derived phase form below
recurrence	one_shot: omit/null; weekly/recurring: required	See recurrence section
timezone	default "UTC"	Must equal recurrence.tz for weekly and recurring schedules
start_date	native recurring only, optional	Canonical local YYYY-MM-DD phase; never send for one-shot or weekly

Extra fields are forbidden. The server responds 422 for unrecognized keys.

One-shot (kind: "one_shot")

• recurrence must be null or omitted.
• fire_at must be in the future, within 90 days from now.
• Format: YYYY-MM-DDTHH:MM:SS±HH:MM or …T…Z (UTC).

Weekly (kind: "weekly")

• recurrence must be exactly:

  {"day": "mon", "time": "09:00", "tz": "Asia/Shanghai"}

  where day is a single lowercase weekday (mon–sun), time is
  24-hour HH:MM, and tz is a valid IANA timezone string.

• timezone must equal recurrence.tz — the server validates this.

• fire_at must be the next computed occurrence of the recurrence
  (server-validated; the server rejects mismatches with a diagnostic
  showing the expected ISO-8601 value).

Recurring (kind: "recurring")

Use this exact bounded recurrence object. The server computes and stores
anchor_date; do not send it in an agent-authored create payload.

For an explicitly instructed local phase, send top-level start_date and
omit fire_at. The daemon validates that date against the complete rule
(including DST), derives the first UTC instant, and persists only its managed
anchor_date. A supplied fire_at is assertion-only; agents should not
calculate it. Without start_date, retain the legacy rule: fire_at is
required and must exactly match the server's next candidate.

freq	Required fields	Forbidden fields
DAILY	interval, time, tz	byday, bymonthday, ordinal
WEEKLY	interval, non-empty distinct byday (MO–SU), time, tz	bymonthday, ordinal
MONTHLY	interval, time, tz, and exactly one selector below	See below
YEARLY	interval, time, tz	byday, bymonthday, ordinal

For MONTHLY, choose exactly one selector:

• bymonthday: one integer from 1 through 31; or
• byday: exactly one MO–SU token and ordinal: one of first,
  second, third, fourth, fifth, or last.

interval is a positive integer. time is HH:MM; tz is an IANA timezone.
The only end conditions are: omit both until and count for never; set
until to one inclusive local YYYY-MM-DD date; or set count to a positive
integer for that many successful dispatches. Never set both. count is
not a calendar-candidate count and must never be expressed as RRULE COUNT.

The agent-authored grammar has no lists of monthly dates, negative wire values,
cron/sub-daily fields, yearly selectors, or alternate field names. If the
instruction cannot be expressed exactly (for example, "every weekday except
the second Tuesday"), do not approximate it: ask for clarification before
arming.

timezone must equal recurrence.tz. For a native recurring payload with
start_date, omit fire_at and never calculate recurrence or DST. Without
start_date, the legacy fire_at remains required and must exactly match the
server's next computed occurrence.

• Default expiry: 90 days from creation. The server does not
  accept "indefinite": true from the agent callback — indefinite
  expiry is founder-set only.

Caps (v1)

Cap	Limit
Armed Todos per agent	20
Armed Todos org-wide	100

Cap violations return 409 with an actionable message — pause or cancel an
existing Todo to make room.

Failure handling — do not guess

Failure class	Server response	What you do
Session mismatch / unknown	409	Re-read your task_id/session_id/agent triples; retry once
Agent team unresolved	409 agent_team_unresolved	Do not arm; report the in-org identity/configuration problem
Invalid kind	422 invalid_kind	Only one_shot, weekly, and recurring are valid
Malformed fire_at or missing timezone offset	422 invalid_fire_at	Correct the ISO-8601 timestamp; always include an offset
One-shot fire_at is past or more than 90 days ahead	409 create_failed with the service diagnostic	Correct the timestamp only when the explicit instruction supports it; otherwise report the diagnostic and ask for clarification
Invalid recurring grammar or phase	422 with one of invalid_freq_fields, invalid_byday, monthly_selector_missing, monthly_selector_conflict, invalid_interval, anchor_date_not_settable, invalid_start_date, invalid_until, invalid_count, end_condition_conflict, invalid_time, or invalid_timezone	Do not guess or retry a different grammar; correct only from the explicit instruction, or ask for clarification
Cap exceeded	409 create_failed	Report which cap; ask the founder which Todo to pause/cancel
Ambiguous instruction	(your guard — don't call)	Ask for clarification — do NOT guess the date, timezone, cadence, or instruction. Escalate rather than arm nonsense.

On success

The server returns a schedule response including:

• schedule_id (e.g., SCHEDULE-007)
• kind, normalized_brief, timezone
• fire_at (the next fire, returned as server-validated ISO-8601)
• status: "armed", active: true

Report to the founder: the schedule_id, the normalized commitment,
kind, timezone, and next fire time. Let them know:

✅ Armed. Founders can inspect all Todos through the Todos list
surface and pause, cancel, or edit timing/recurrence/timezone through
the Todos controls. Original source_instruction and normalized_brief
are immutable and cannot be edited through founder controls.

Founder management (separate from agent create): The Todos surface provides list, show/id detail, pause, cancel, and edit (timing/recurrence/timezone only) operations. Do NOT use todos create — agent creation is schedules create.

Examples

Example 1 — Follow up in 48 hours (one-shot)

Context: The founder says "follow up on TASK-4000 in 48 hours."

Write /tmp/schedule-TASK-4317.json:

{
  "task_id": "TASK-4317",
  "session_id": "sess-b86b2a3404d740179c23871958c9c7db",
  "agent": "dev_agent",
  "source_instruction": "follow up on TASK-4000 in 48 hours",
  "normalized_brief": "Review TASK-4000 status and report any blockers or completion to the founder in #engineering",
  "kind": "one_shot",
  "fire_at": "2026-08-06T18:40:00+08:00",
  "recurrence": null,
  "timezone": "UTC"
}

Placeholders you MUST replace: fire_at must be an actual
future timestamp 48 hours from now with your own offset. task_id,
session_id, agent must match your active session. The
normalized_brief must reflect the real instruction.
Do NOT conduct a live schedule create — this is a template.

happyranch schedules create --org happyranch --from-file /tmp/schedule-TASK-4317.json

Example 2 — Saturday market update (weekly)

Context: The founder says "send me a market update every Saturday
at 09:00 Shanghai time."

Write /tmp/schedule-weekly-market.json:

{
  "task_id": "TASK-4317",
  "session_id": "sess-b86b2a3404d740179c23871958c9c7db",
  "agent": "dev_agent",
  "source_instruction": "send me a market update every Saturday at 09:00 Shanghai time",
  "normalized_brief": "Compile and post a concise crypto/ai market update for the week, including major price moves and news, to the founder's thread",
  "kind": "weekly",
  "fire_at": "2026-08-08T01:00:00Z",
  "recurrence": {"day": "sat", "time": "09:00", "tz": "Asia/Shanghai"},
  "timezone": "Asia/Shanghai"
}

Placeholders you MUST replace: fire_at must be the actual
next Saturday 09:00 Asia/Shanghai occurrence computed from NOW and
encoded as UTC (or with offset). The example shows 2026-08-08T01:00:00Z
which is Saturday 2026-08-08 09:00 CST (UTC+8). Replace with the
real next occurrence. task_id, session_id, agent, and
normalized_brief must reflect reality.

happyranch schedules create --org happyranch --from-file /tmp/schedule-weekly-market.json

Example 3 — fortnightly Tuesday/Thursday report, ending after six successful dispatches (recurring)

This is a template only. Use it only when the founder/operator explicitly gave
this exact commitment and phase. Let the daemon calculate the first instant.

{
  "task_id": "TASK-4317",
  "session_id": "sess-abc123",
  "agent": "dev_agent",
  "source_instruction": "Every other Tuesday and Thursday at 09:00 Shanghai time, send the project report; stop after six successful reports.",
  "normalized_brief": "Send the project report to the founder's thread, covering progress, blockers, and the next planned steps.",
  "kind": "recurring",
  "start_date": "2026-08-18",
  "recurrence": {
    "freq": "WEEKLY",
    "interval": 2,
    "byday": ["TU", "TH"],
    "time": "09:00",
    "tz": "Asia/Shanghai",
    "count": 6
  },
  "timezone": "Asia/Shanghai"
}

happyranch schedules create --org happyranch --from-file /tmp/schedule-fortnightly-report.json

v2 boundaries — what is NOT included

Out of scope	Details
Cross-agent scheduling	Self-only; agents must never target another agent
Cron or unsupported recurrence	No sub-daily/cron, monthly lists or negative values, yearly selectors, or hidden alternate grammar
Hidden / silent schedules	All Todos are founder-visible
General unscheduled backlog	No "Todo inbox" — every Todo has a fire_at
Resume / re-arm from agent side	Re-arming after pause is founder-controlled
Edit source_instruction or normalized_brief	Immutable; founder can only edit timing/recurrence/timezone
Agent-driven todos create	Agent create is schedules create; the todos surface is founder management (list/show/pause/cancel/edit)
indefinite: true from agent callback	Indefinite expiry is founder-set only

C3 writer disposition follows the actual authority/profile interval through
native naming reconciliation and explicit leading validation. Stale rename or
prompt CAS may settle only after successful native rollback/reconciliation;
unfenced status alone proves nothing. Caught reconciliation/publication/clone
failure, cancellation and partial effects retain unknown ownership. Skill scratch
cleanup requires no-follow lstat ENOENT; surviving entries, inspection errors and
prior uncertainty stay unknown. Cleanup causes are retained; existing unknown
history is never cleared. These are source accounting rules, not behavioral
verification or new execution/activation authority.