@aopslabs/aops 0.3.24 → 0.3.25

package/assets/agent-assets/core/user-guides/working-disciplines.md

@@ -23,7 +23,7 @@ A discipline is:
 - memory cadence
 - plan and slice rhythm
 
-A discipline is role-agnostic. Reusable discipline text names roles such as `implementer`, `reviewer`, `coordinator`, and `operator-approver`; it does not bind concrete agents to those roles. Concrete agent-to-role assignment belongs in mission-specific `mission.policy.roles`.
+A discipline is role-agnostic. Reusable discipline text names roles such as `implementer`, `reviewer`, `coordinator`, and `operator-approver`; it does not bind concrete agents to those roles. Concrete agent-to-role assignment belongs in the session-specific discipline policy.
 
 The four canonical ids are:
 
@@ -32,7 +32,7 @@ The four canonical ids are:
 | `solo-pm-loop` | Single-agent or low-uncertainty work | Projectman, optional RR, memory |
 | `build-review-chat` | Live implementer plus reviewer work | Projectman RR/RRR, ChatV3 wake, memory |
 | `design-first-consensus` | High design uncertainty or irreversible choices | Discuss, operator approval, Projectman |
-| `coordinator-loop` | Operator delegates session management to one coordinator agent directing implementer agents | Mission policy, Projectman RR/RRR, ChatV3 room, memory |
+| `coordinator-loop` | Operator delegates session management to one coordinator agent directing implementer agents | Projectman RR/RRR, ChatV3 room, memory |
 
 `mode` is transport/session shape: `solo`, `solo+async-review`, or `chat-room`.
 `discipline` is the work policy. A chat-room mode usually maps to
@@ -87,111 +87,22 @@ The start pack includes:
 - `method.selected` with `aliasOf: "discipline"`
 - `guardrails[]`
 - `guardrailGroups.execution` and `guardrailGroups.closeout`
-- `policy` and `policyJson` for mission policy seeding
 - `policy.closeout` with explicit closeout command hints
 - apply-required `deferredBindings`
 
-## 3 Mission policy convention
 
-### 3.1 Overview
-
-#### 3.1.1 Overview
-
-Mission policy stays free-form, but AOPS uses this convention. The current
-`aops start --json` seed includes the main policy groups plus the expanded
-selection/orchestration helpers shown below:
-
-```json
-{
-  "discipline": {
-    "id": "build-review-chat",
-    "version": "s1",
-    "enforcement": "advisory",
-    "selectedBy": "operator",
-    "selectedVia": "--discipline",
-    "recommended": "solo-pm-loop",
-    "signals": {
-      "mode": "solo",
-      "agentCount": 1
-    },
-    "rationale": ["explicit discipline flag supplied"]
-  },
-  "signalMapping": {
-    "mode": "transport/session shape",
-    "agentCount": "coordination complexity",
-    "workSize": "planning granularity",
-    "decisionUncertainty": "design-first trigger",
-    "operatorInterface": "delegation trigger for coordinator-loop"
-  },
-  "guardrails": [],
-  "guardrailGroups": {
-    "execution": [],
-    "closeout": []
-  },
-  "closeout": {
-    "required": true,
-    "trigger": "explicit",
-    "guardrailIds": ["closeout-handoff-memory"],
-    "check": {
-      "command": null,
-      "mode": "read-only",
-      "state": "not-shipped-use-owner-readbacks",
-      "statusStates": [
-        "present",
-        "missing",
-        "deferred-with-owner",
-        "not-applicable",
-        "waived-by-operator"
-      ]
-    },
-    "handoff": {
-      "command": "aops pm handoff write --help",
-      "mode": "owner-surface"
-    }
-  },
-  "review": {},
-  "issue": {},
-  "memory": {},
-  "plan": {},
-  "planning": {},
-  "orchestration": {},
-  "vocabBridge": {
-    "mode": { "meaning": "transport/session shape" },
-    "discipline": { "meaning": "policy preset plus guardrails" },
-    "method": { "aliasOf": "discipline" }
-  }
-}
-```
-
-Use `result.mission.policyJson` from `aops start --json` with
-`aops mission create --policy-json` or `aops mission update --policy-json`.
-
-The exact policy is still advisory and free-form. Treat this convention as a
-stable reading/writing shape, not as a strict schema.
-
-`mission.policy.roles` may bind the generic roles for one mission, for example `implementer`, `reviewer`, `coordinator`, and `operator-approver`. A `coordinator-loop` mission typically binds `roles.operator`, `roles.coordinator`, and one or more `roles.implementer` entries; `roles.reviewer` defaults to the coordinator when absent. This binding is mission-local evidence and must not be copied into reusable discipline docs as a fixed Codex/Claude assignment.
+## 3 Guardrail registry
 
-`guardrailGroups.execution` and `guardrailGroups.closeout` are presentation
-groups over the same `guardrails[]` registry. `policy.closeout` is an
-explicit-before-leaving convention: it records required closeout guardrails,
-the required owner readbacks and a Projectman/memory handoff. This Community
-release has no `mission check` or `mission handoff` command, and it never closes
-boards or chat rooms automatically.
-
-## 4 Guardrail registry
-
-### 4.1 Overview
+### 3.1 Overview
 
 #### 4.1.1 Overview
 
 Every guardrail now has a phase:
 
 - `execution`: applies while planning, implementing, reviewing, and committing.
-- `closeout`: applies before leaving a mission/session or handing it to the next run.
+- `closeout`: applies before leaving a session or handing it to the next run.
 
 Empty `evidence` means reviewer-attested/non-auto-checkable in S1/S2. A later
-`mission check --closeout` must not auto-fail those rows; it may report them as
-not-applicable or reviewer-attested. Non-empty evidence names a surface that a
 future read-only check can inspect.
 
 | Guardrail id | Phase | Disciplines | Evidence | Enforcement |
@@ -201,7 +112,7 @@ future read-only check can inspect.
 | `verify-first-initial-stance` | execution | `build-review-chat`, `design-first-consensus` | `chatv3.message` | advisory |
 | `coordinator-independent-research` | execution | `coordinator-loop` | `projectman.kanban-task`, `projectman.sprint` | advisory |
 | `single-operator-interface` | execution | `coordinator-loop` | `chatv3.message` | advisory |
-| `assignment-via-canonical-refs` | execution | `coordinator-loop` | `agentspace.mission`, `projectman.kanban-task`, `projectman.sprint` | advisory |
+| `assignment-via-canonical-refs` | execution | `coordinator-loop` | `projectman.kanban-task`, `projectman.sprint` | advisory |
 | `idle-window-improvement` | execution | `coordinator-loop` | `projectman.issue`, `projectman.feedback` | advisory |
 | `review-request-per-slice` | execution | `build-review-chat`, `coordinator-loop` | `projectman.review-request`, `chatv3.message` | advisory |
 | `verify-in-code` | execution | `build-review-chat`, `coordinator-loop` | empty | advisory |
@@ -220,20 +131,19 @@ future read-only check can inspect.
 | `closeout-pm-status-audit` | closeout | all | `projectman.status.audit`, `projectman.status.reconcile` | soft-preflight |
 | `closeout-triage-open-reviews` | closeout | all | `projectman.review-request` | soft-preflight |
 | `closeout-triage-open-issues` | closeout | all | `projectman.issue` | soft-preflight |
-| `closeout-mission-status-finalized` | closeout | all | `agentspace.mission.status` | soft-preflight |
-| `closeout-resume-readiness` | closeout | all | `agentspace.mission.resume-pack` | soft-preflight |
+| `closeout-resume-readiness` | closeout | all | `agentspace.memory`, `projectman.implementation-plan`, `projectman.handoff` | soft-preflight |
 | `closeout-session-summary` | closeout | all | `agentspace.memory-item` | soft-preflight |
 | `closeout-slice-review-accounted` | closeout | `build-review-chat`, `coordinator-loop` | `projectman.review-request`, `projectman.issue` | soft-preflight |
 | `closeout-commit-scope-recorded` | closeout | `build-review-chat`, `coordinator-loop` | `git.commit`, `projectman.review-request`, `chatv3.message` | soft-preflight |
-| `closeout-assignment-queue-truthful` | closeout | `coordinator-loop` | `agentspace.mission`, `projectman.kanban-task` | soft-preflight |
+| `closeout-assignment-queue-truthful` | closeout | `coordinator-loop` | `projectman.kanban-task` | soft-preflight |
 | `closeout-discuss-output-finalized` | closeout | `design-first-consensus` | `agentspace.discussion-topic.outputs` | soft-preflight |
 | `closeout-decision-carried-to-execution` | closeout | `design-first-consensus` | `projectman.kanban-task`, `projectman.sprint`, `projectman.issue`, `projectman.feedback` | soft-preflight |
 
-### 4.2 Closeout discipline
+### 3.2 Closeout discipline
 
 #### 4.2.1 Overview
 
-Closeout is the explicit before-leaving phase for an active mission/session. It
+Closeout is the explicit before-leaving phase for an active session. It
 is not the same as operator board closeout or leaving a ChatV3 room.
 
 Use handoff when work continues or a future session must resume. Use complete
@@ -247,7 +157,6 @@ All disciplines share this closeout checklist:
 - run `aops pm status audit` for the active task/board before saying work is done; resolve, reconcile, or explicitly defer stale task/sprint status findings with an owner
 - triage open review requests as accepted, linked to follow-up work, or deferred with owner
 - triage open issues as resolved, linked to follow-up work, or deferred with owner
-- leave mission status truthful: active, handoff, completed, blocked, or deferred
 - prove resume readiness from objective, policy, plan, memory, review, issue, and next-action refs
 - record a concise session summary with changed scope and validation evidence
 
@@ -255,7 +164,6 @@ Closeout status values are intentionally descriptive, not hard-fail booleans:
 `present`, `missing`, `deferred-with-owner`, `not-applicable`, and
 `waived-by-operator`.
 
-The current Community CLI does not ship `mission check` or `mission handoff`.
 Use the owner surfaces instead:
 
 ```bash
@@ -267,9 +175,9 @@ aops mem checkpoint --help
 Agents enforce closeout through PM/RR state, memory, review, chat wake refs,
 and honest handoff notes.
 
-## 5 solo-pm-loop
+## 4 solo-pm-loop
 
-### 5.1 Overview
+### 4.1 Overview
 
 #### 5.1.1 Overview
 
@@ -306,13 +214,13 @@ RR/RRR:
 
 Closeout checklist:
 
-- base closeout guardrails only: handoff memory, review/issue triage, mission status, resume readiness, and session summary
+- base closeout guardrails only: handoff memory, review/issue triage, resume readiness, and session summary
 - optional async review is either accepted or deferred with owner
 - next agent can resume from PM sprint/task plus memory without reading the whole chat
 
-## 6 build-review-chat
+## 5 build-review-chat
 
-### 6.1 Overview
+### 5.1 Overview
 
 #### 6.1.1 Overview
 
@@ -336,7 +244,7 @@ Consensus-to-plan binding:
 - when a material consensus exists, the implementer or reviewer proactively asks whether it should become a PM implementation plan
 - the operator approval gate decides whether the consensus is carried into Projectman
 - execution waits until the plan references the consensus and the reviewer accepts the plan review request
-- the reusable recipe stays role-agnostic; the mission policy decides which concrete agent is implementer or reviewer
+- the reusable recipe stays role-agnostic; the discipline policy decides which concrete agent is implementer or reviewer
 
 Verify-first consensus-to-build recipe:
 
@@ -392,9 +300,9 @@ Closeout checklist:
 - unresolved review findings become PM issues before handoff or completion
 - do not close the room or board unless the operator says to close them
 
-## 7 design-first-consensus
+## 6 design-first-consensus
 
-### 7.1 Overview
+### 6.1 Overview
 
 #### 7.1.1 Overview
 
@@ -437,7 +345,7 @@ Consensus-to-plan binding is mandatory for this discipline when implementation f
 - carry the concluded consensus ref into a Projectman task, sprint-backed implementation plan, issue, or feedback record before implementation resumes
 - the implementation plan goal should explain `NE / NICIN / DONE-WHEN` in operator-readable language
 - execution stays blocked until the operator-approved consensus is bound to the plan and the reviewer accepts the plan approval review request
-- concrete agent names stay in mission policy; the reusable discipline names only implementer, reviewer, and operator-approver roles
+- concrete agent names stay in discipline policy; the reusable discipline names only implementer, reviewer, and operator-approver roles
 
 Closeout checklist:
 
@@ -447,9 +355,9 @@ Closeout checklist:
 - unresolved decision work is deferred with owner instead of disappearing into chat
 - handoff memory names the accepted decision and the next execution surface
 
-## 8 coordinator-loop
+## 7 coordinator-loop
 
-### 8.1 Overview
+### 7.1 Overview
 
 #### 8.1.1 Overview
 
@@ -464,19 +372,19 @@ When to use:
 - review authority is delegated: the coordinator (or a bound reviewer) accepts
   slices; the operator is not paged per slice
 
-Roles (generic, bound per mission in `mission.policy.roles`):
+Roles (generic, bound per session):
 
 - `operator`: human intent, priorities, and approvals; speaks only to the
   coordinator.
 - `coordinator`: single operator interface. Researches independently before
-  assigning, authors mission/task/plan records, assigns work with canonical
-  refs, reviews RRs, instructs commits, keeps PM/mission/memory truthful, and
+  assigning, authors task/plan records, assigns work with canonical
+  refs, reviews RRs, instructs commits, keeps PM/memory truthful, and
   uses idle windows for improvement work (docs, skills, tooling) plus
   issue/feedback capture.
 - `implementer` (one or more): executes assigned slices, opens an RR per slice,
   routes questions and decisions to the coordinator (never directly to the
   operator), commits only on coordinator instruction.
-- `reviewer` (optional): defaults to the coordinator; a mission may bind a
+- `reviewer` (optional): defaults to the coordinator; a session may bind a
   separate reviewer.
 
 Role names are open: `master` or `operator-agent` are discouraged aliases for
@@ -494,9 +402,9 @@ Preset:
   implementer file them; the coordinator also files doc/skill gap findings
   discovered during policy checks
 - memory: the coordinator writes kickoff/checkpoint/closeout memory; assignment
-  truth lives in mission/ktask/plan records, not in chat prose
+  truth lives in ktask/plan records, not in chat prose
 - rhythm: operator request -> coordinator independent research (code, PM,
-  docs) -> mission/ktask/plan authoring -> chat assignment with canonical
+  docs) -> ktask/plan authoring -> chat assignment with canonical
   refs -> implementer slices with RRs -> coordinator review and fix loop ->
   instructed pathspec commit -> next task or idle-window improvement work
 
@@ -504,7 +412,6 @@ Expected flow:
 
 ```bash
 # coordinator: durable anchor + role binding
-aops mission create --objective "<program>" \
   --policy-json '{"discipline":"coordinator-loop","roles":{"operator":"<name>","coordinator":"<agent>","implementer":"<agent>"}}' \
   --apply --json
 
@@ -512,9 +419,8 @@ aops mission create --objective "<program>" \
 aops pm ktask create --board <board> --column Doing --title "<task>" --apply --json
 aops plan create --task <task-id> --name "<plan>" --goal "<goal>" \
   --scope-item "S1 ..." --scope-item "S2 ..." --apply --json
-aops mission update --id <mission-id> --active-plan <plan-id> --apply --json
 aops chat send --session <session> --room general \
-  "GOREV ATAMASI: mission <id> / ktask <id> / plan <id> - S1'den basla, slice basina RR" --json
+  "GOREV ATAMASI: ktask <id> / plan <id> - S1'den basla, slice basina RR" --json
 
 # implementer: per slice
 aops pm review-request create --task <task-id> --sprint <plan-id> \
@@ -529,7 +435,7 @@ aops pm review-request result --id <rr-id> --reviewer <coordinator> \
 Free-form session notes:
 
 - multiple independent tasks may be active at once; each gets its own
-  ktask/plan; the mission stays the session anchor and
+  ktask/plan; the plan stays the session anchor and
   `activeImplementationPlanRef` tracks the current focus
 - the coordinator adapts the depth of process to the task: an atomic fix may
   run as a single RR without a plan; multi-slice work gets a sprint-backed plan
@@ -550,21 +456,20 @@ Closeout checklist:
 - base closeout guardrails plus `build-review-chat` items: every slice RR
   accounted for; commit hash, pathspec, and validation evidence recorded
 - assignment queue truthful: every operator request in the session is bound to
-  a mission/ktask/plan record, completed, or explicitly deferred with owner
+  a ktask/plan record, completed, or explicitly deferred with owner
 - coordinator improvement findings are filed as PM issues/feedback, not left in
   chat
 - handoff memory names the active assignments, review states, and the next
   action per implementer
 
-## 9 Owner boundaries
+## 8 Owner boundaries
 
-### 9.1 Overview
+### 8.1 Overview
 
 #### 9.1.1 Overview
 
 | Surface | Owner | Use for |
 | --- | --- | --- |
-| Mission | Agentspace | durable intent and policy |
 | Projectman | Projectman | task, sprint, microtask, issue, review truth |
 | Discuss | Agentspace discuss | material decisions and final stances |
 | Memory | Agentspace memory | durable carry-forward context |
@@ -575,14 +480,3 @@ Closeout checklist:
 Do not hand-edit `.aops/hosted/**` or `.aops/docman/**` as canonical truth.
 Use hosted commands, then refresh mirrors.
 
-## 10 Later: mission check
-
-### 10.1 Overview
-
-#### 10.1.1 Overview
-
-`aops mission check --closeout` is intentionally later. The MVP check must
-be read-only and inspect PM/discuss/memory evidence plus declared closeout
-status. It must not mutate PM, memory, git, boards, or chat rooms. It should not
-hard-fail by default; strict enforcement is opt-in later through
-`policy.discipline.enforcement = "strict"` or a future explicit closeout policy.

package/dist/commands/checkpoint.js

@@ -6,7 +6,6 @@ import { resolveOwnerScopeIdFromBinding, resolveProjectBindingContext, } from '.
 import { createNewLocalMemoryEntry, readLocalMemoryEntries, rebuildLocalMemoryWorkspace, resolveMemoryWorkspacePaths, writeLocalMemoryEntryFile, } from '../utils/memory-workspace.js';
 const REPO_FIRST_CHECKPOINT_TOOL_ID = 'repo-first.checkpoint';
 const CHECKPOINT_SCHEMA_VERSION = 1;
-const MISSION_SUBJECT_TYPE = 'agentspace.mission';
 const PROJECT_SUBJECT_TYPE = 'projectman.plan';
 function isRecord(value) {
     return value !== null && typeof value === 'object' && !Array.isArray(value);
@@ -126,17 +125,9 @@ function buildCheckpointState(entries, includeLegacy = true) {
     return { supersededIds, currentIds };
 }
 function resolveCheckpointSubject(options, context) {
-    const missionId = normalizeNonEmpty(options.missionId);
-    if (missionId) {
-        return {
-            subjectType: MISSION_SUBJECT_TYPE,
-            subjectId: missionId,
-            subjectTitle: normalizeNonEmpty(options.missionSlug) ?? `mission:${missionId}`,
-        };
-    }
     const subjectId = normalizeNonEmpty(options.subjectId) ?? resolveOwnerScopeIdFromBinding(context) ?? normalizeNonEmpty(context.projectId);
     if (!subjectId) {
-        throw new Error('Checkpoint subject could not be resolved. Provide --mission-id, --subject-id, --project-id, or repo config.');
+        throw new Error('Checkpoint subject could not be resolved. Provide --subject-id, --project-id, or repo config.');
     }
     return {
         subjectType: normalizeNonEmpty(options.subjectType) ?? PROJECT_SUBJECT_TYPE,
@@ -145,9 +136,6 @@ function resolveCheckpointSubject(options, context) {
     };
 }
 function resolveReadSubject(options) {
-    const missionId = normalizeNonEmpty(options.missionId);
-    if (missionId)
-        return { subjectType: MISSION_SUBJECT_TYPE, subjectId: missionId };
     const subjectType = normalizeNonEmpty(options.subjectType);
     const subjectId = normalizeNonEmpty(options.subjectId);
     if (!subjectType && !subjectId)
@@ -215,8 +203,6 @@ function buildCheckpointEntry(params) {
     const nextSteps = toStringArray(options.nextStep);
     const timestamp = new Date().toISOString();
     const anchors = compactPayload({
-        missionId: normalizeNonEmpty(options.missionId),
-        missionSlug: normalizeNonEmpty(options.missionSlug),
         sessionId: normalizeNonEmpty(options.sessionId),
         projectId: normalizeNonEmpty(context.projectId),
         projectSlug: normalizeNonEmpty(context.projectSlug),
@@ -243,7 +229,6 @@ function buildCheckpointEntry(params) {
             'memory:checkpoint',
             'checkpoint:session',
             context.projectId ? `project:${context.projectId}` : undefined,
-            options.missionId ? `mission:${options.missionId}` : undefined,
             linked.kanbanTaskId ? `kanban-task:${linked.kanbanTaskId}` : undefined,
             linked.sprintId ? `sprint:${linked.sprintId}` : undefined,
             linked.phaseId ? `phase:${linked.phaseId}` : undefined,
@@ -494,13 +479,11 @@ export function makeCheckpointCommand() {
         .option('--content <textOrFile>', 'Optional notes text, or @file to read notes from disk')
         .option('--source-ref <value>', 'Repeatable source ref (string, JSON object/array, or @file.json)', collectRepeatedOption, [])
         .option('--next-read-ref <value>', 'Repeatable next read ref (string, JSON object/array, or @file.json)', collectRepeatedOption, [])
-        .option('--mission-id <id>', 'Mission id anchor; uses agentspace.mission subject')
-        .option('--mission-slug <slug>', 'Mission slug/title hint')
         .option('--session-id <id>', 'Session id anchor')
         .option('--agent <id>', 'Agent/session actor label')
-        .option('--subject-type <type>', 'Explicit subject type for non-mission checkpoint')
-        .option('--subject-id <id>', 'Explicit subject id for non-mission checkpoint')
-        .option('--subject-title <text>', 'Explicit subject title for non-mission checkpoint')
+        .option('--subject-type <type>', 'Explicit subject type checkpoint')
+        .option('--subject-id <id>', 'Explicit subject id checkpoint')
+        .option('--subject-title <text>', 'Explicit subject title checkpoint')
         .option('--task-id <id>', 'Linked kanban task id')
         .option('--kanban-task-id <id>', 'Linked kanban task id')
         .option('--sprint-id <id>', 'Linked sprint id')
@@ -518,7 +501,6 @@ export function makeCheckpointCommand() {
     }));
     applyCheckpointContextOptions(cmd.command('list')
         .description('List checkpoint timeline, including superseded records')
-        .option('--mission-id <id>', 'Filter to mission checkpoint subject')
         .option('--subject-type <type>', 'Filter by subject type')
         .option('--subject-id <id>', 'Filter by subject id')
         .option('--current', 'Show only current non-superseded checkpoint per subject')
@@ -532,7 +514,6 @@ export function makeCheckpointCommand() {
         .description('Get a checkpoint by id, or the current checkpoint for a subject')
         .option('--id <id>', 'Checkpoint id')
         .option('--current', 'Get current checkpoint for the requested subject (default when --id is omitted)')
-        .option('--mission-id <id>', 'Mission id subject for current lookup')
         .option('--subject-type <type>', 'Subject type for current lookup')
         .option('--subject-id <id>', 'Subject id for current lookup')
         .option('--full', 'Include checkpoint content body')