mirai-graph 1.4.0 → 2.1.0

package/standard/implementation-control-cycles.md

@@ -1,194 +0,0 @@
-# Implementation Control Cycles
-
-Status: 1.0 release-candidate standard section
-
-## Purpose
-
-Implementation-control cycles define repeatable, governed work scenarios inside
-Mirai Graph. They make project movement explicit without treating generated
-context, feedback, evidence or runtime output as automatic permission to change
-canonical state.
-
-## Core Principle
-
-```text
-cycle = repeatable governed scenario
-gate = readiness, safety or approval check
-evidence = trace supporting a claim
-proposal = reviewable request for canonical change
-controlled update = approved canonical change
-```
-
-Cycles must define inputs, outputs, stages, gates, validators, recovery
-behavior, repeat condition and promotion path.
-
-`stages` describe the human-readable projection of work. Executable process
-movement must use state-machine fields such as `executable_states`,
-`state_mapping` and `state_machine_id`. Narrative stages are not enough to
-authorize state transitions.
-
-Cycle transitions define when one cycle may hand off to another. A cycle does
-not silently start the next cycle. It produces a transition decision with
-required outputs, required gates and a handoff artifact.
-
-## Standard Cycles
-
-### `human_projection_feedback`
-
-Purpose: create a human-readable projection from a graph baseline, review it
-for semantic gaps and convert accepted findings into explicit graph proposals.
-
-Typical stages:
-
-```text
-extract_baseline_context
--> generate_projection
--> semantic_review
--> classify_findings
--> create_sync_proposal
--> approval_gate
--> regenerate_projection
-```
-
-Promotion path: accepted review findings become sync proposals. The projection
-itself does not become canonical truth.
-
-### `implementation_planning`
-
-Purpose: convert a reviewed baseline, feature scope or project goal into a
-bounded work plan with owners, gates, allowed scope and evidence requirements.
-
-Promotion path: accepted plans create launch-ready batches, not executed work.
-
-### `bounded_work_batch`
-
-Purpose: execute only the scope approved by a launch gate.
-
-Promotion path: work output becomes evidence and possibly a sync proposal. It
-does not directly update canonical graph state.
-
-### `review_and_evidence`
-
-Purpose: verify implementation evidence, semantic acceptance, drift and
-proposal readiness before approval.
-
-Promotion path: accepted evidence may support approval, but evidence is not
-approval by itself.
-
-Significant work should also include technology quality feedback: a separate
-check that the declared method, process or technology was actually followed.
-Passing tests and complete evidence are not enough when the workflow itself
-drifted from the accepted technology.
-
-### `release_or_publish`
-
-Purpose: decide whether an artifact, package or public output is ready for
-release or publication.
-
-Promotion path: release readiness requires explicit gates and public-safety
-review when the artifact becomes public.
-
-### `runtime_feedback`
-
-Purpose: capture operational, user or runtime feedback and convert it into
-reviewable improvement items or graph proposals.
-
-Promotion path: feedback becomes a proposal or Kaizen item. It must not mutate
-canonical behavior automatically.
-
-### `kaizen_improvement`
-
-Purpose: evaluate completed cycles and convert lessons, regressions and
-improvement opportunities into controlled artifact, graph, process, validator,
-tooling or backlog changes.
-
-Typical stages:
-
-```text
-evaluate_result
--> classify_improvement
--> check_impact_and_risk
--> decide_accept_or_defer
--> validate_improvement_path
--> choose_next_transition
-```
-
-Kaizen is a meta-cycle. It is not a replacement for `runtime_feedback`:
-
-- `runtime_feedback` captures operational, user or runtime evidence;
-- `kaizen_improvement` reviews the quality of completed work and the quality
-  of the process that produced it.
-
-Kaizen blocks the next transition only for safety, quality, DNA alignment or
-critical drift findings. Other improvements are accepted locally or deferred to
-follow-up proposals.
-
-## Cycle Transitions
-
-The public cycle pattern is:
-
-```text
-cycle completed
--> transition decision
--> kaizen review
--> classified improvement
--> blocking/non-blocking decision
--> next governed cycle
-```
-
-Each transition must define:
-
-- source cycle;
-- target cycle;
-- trigger;
-- required outputs;
-- required gates;
-- handoff artifact;
-- owner;
-- failure behavior;
-- recovery behavior.
-
-Default rule: if a transition gate does not pass, the next cycle is not
-available. The source cycle must repeat, record a blocker or produce a handoff
-that explains the missing condition.
-
-Kaizen default rule: every major cycle records whether improvement was needed.
-If improvement is needed, it is classified before the next transition is
-chosen.
-
-Recommended Kaizen finding taxonomy:
-
-- `artifact_improvement`;
-- `graph_spec_improvement`;
-- `process_improvement`;
-- `validator_improvement`;
-- `tooling_improvement`;
-- `dna_alignment_issue`;
-- `quality_regression`;
-- `safety_regression`;
-- `critical_drift`;
-- `user_value_gap`.
-
-## Required Boundaries
-
-- `ready_to_execute` is not `executed`.
-- `ready_to_code` is not `implemented`.
-- Generated projection is not source of truth.
-- Evidence is not approval.
-- Passing tests are not acceptance.
-- Technology quality feedback supports acceptance; it is not acceptance by
-  itself.
-- Feedback is not canonical update.
-- Proposal is not controlled update.
-- Runtime decision is not executed action.
-
-## Schema
-
-Machine-readable cycle results can be validated with:
-
-```text
-schemas/implementation-control-cycle.schema.json
-```
-
-The schema validates public shape and traceability. It does not prove semantic
-truth, operational effectiveness or real-world safety.

package/standard/implementation-control.md

@@ -1,102 +0,0 @@
-# Implementation Control
-
-Status: 1.0 release-candidate standard section
-
-## Purpose
-
-Implementation control defines how Mirai Graph represents governed movement from
-project knowledge to implementation action without confusing generated context,
-feedback, proposals, approvals and canonical state.
-
-## Control Loop
-
-```text
-implementation baseline
--> generated projection view
--> semantic review
--> launch gate
--> workflow batch
--> evidence pack
--> sync proposal
--> approval gate
--> controlled update
--> drift check
--> updated baseline
--> improvement item
-```
-
-## Rules
-
-- Generated context is not authorization.
-- Human feedback is not an automatic canonical update.
-- Implementation evidence is not proof of approval.
-- A sync proposal must remain separate from an approved update.
-- Canonical updates require explicit governance gates.
-- `ready_to_execute` and `ready_to_code` are not `executed` or `implemented`.
-- Bounded work batches require a launch gate before writes or runtime actions.
-- Implementation state promotion requires evidence and drift review.
-- Public transfer requires public-safety review and synthetic examples unless
-  the source material is already public.
-
-## Relationship To Project Management
-
-Use `project-management` for goals, tasks, milestones, stakeholder coordination,
-ordinary decisions and high-level risks.
-
-Use `implementation-control` when the work crosses a control boundary:
-generated context becomes a human projection, a plan becomes a bounded work
-batch, evidence becomes an approval candidate, or feedback becomes a proposal
-for canonical graph change.
-
-The implementation-control profile is therefore stricter than ordinary project
-management. It models authorization boundaries, evidence boundaries, drift
-checks and controlled updates.
-
-## Cycles
-
-Reusable implementation-control cycles are documented in:
-
-```text
-standard/implementation-control-cycles.md
-```
-
-## Launch Records
-
-Launch records are bounded authorization artifacts for executable work
-batches. They are documented in:
-
-```text
-standard/launch-record.md
-```
-
-A launch record is not implementation proof, release approval or a canonical
-update.
-
-## Process Control Contracts
-
-Executable process-control contracts bind cycles, state machines, launch-record
-policy, evidence, recovery, risk controls, validators and Kaizen closure. They
-are documented in:
-
-```text
-standard/process-control-contract.md
-```
-
-## Profile
-
-Machine-readable profile:
-
-```text
-profiles/implementation-control/profile.json
-```
-
-## Schema
-
-The initial loop schema is documented at:
-
-```text
-schemas/implementation-control-loop.schema.json
-```
-
-It validates the shape of a loop result, not the semantic truth of the
-implementation.

package/standard/launch-record.md

@@ -1,53 +0,0 @@
-# Launch Record
-
-Status: 1.0 release-candidate standard section
-
-## Purpose
-
-A launch record is a durable authorization boundary for a bounded work batch.
-It says what may be attempted, which state transition is being requested, what
-evidence must be produced and when the work must stop.
-
-It is not implementation proof, acceptance evidence, release approval or a
-canonical update.
-
-## Required Contract
-
-A launch record must define:
-
-- workflow id;
-- process model id;
-- cycle id;
-- current state and target state;
-- allowed and forbidden files or scopes;
-- allowed actions;
-- required gates;
-- required evidence;
-- stop conditions;
-- owner role;
-- user approval flag;
-- evidence references;
-- limitations.
-
-## Execution Boundary
-
-```text
-plan
--> launch record
--> bounded work
--> evidence
--> review
--> approval candidate
-```
-
-The launch record permits only the declared work. If scope, owner, state,
-evidence requirements or stop conditions change, the launch record must be
-updated or replaced before continuing.
-
-## Schema
-
-Machine-readable launch records can be validated with:
-
-```text
-schemas/launch-record.schema.json
-```

package/standard/lifecycle-readiness.md

@@ -1,159 +0,0 @@
-# Mirai Graph Lifecycle And Readiness
-
-Status: 1.0 release-candidate standard section
-
-## Purpose
-
-Lifecycle and readiness rules describe how Mirai Graph objects, relations,
-context packs and standard sections move from early ideas to accepted canonical
-state.
-
-Readiness is not the same as task status. It records whether a graph element is
-mature enough to be used as trusted context, implementation input or governance
-evidence.
-
-## Core Readiness Values
-
-### `draft`
-
-The element exists but is incomplete, unreviewed or exploratory.
-
-Use for:
-
-- early graph-seed objects;
-- unreviewed relations;
-- initial examples;
-- newly imported material.
-
-### `review_ready`
-
-The element is structured enough for review.
-
-Use for:
-
-- candidate objects with evidence;
-- candidate relations with clear source and target;
-- context packs prepared for human review;
-- standard sections ready for critique.
-
-### `accepted`
-
-The element has passed the relevant review or governance gate and may be used
-as canonical state.
-
-Use for:
-
-- stable objects;
-- approved relations;
-- accepted evidence records;
-- reviewed standard sections.
-
-### `blocked`
-
-The element cannot progress until a blocker is resolved.
-
-Use for:
-
-- missing evidence;
-- unresolved contradiction;
-- privacy or licensing issue;
-- governance approval requirement;
-- unsafe action boundary.
-
-### `deprecated`
-
-The element remains traceable but should not be used for new work.
-
-Use for:
-
-- superseded objects;
-- old relation types;
-- obsolete profiles;
-- retired context-pack rules.
-
-## Lifecycle Flow
-
-Typical flow:
-
-```text
-draft -> review_ready -> accepted
-draft -> blocked -> draft
-review_ready -> blocked -> review_ready
-accepted -> deprecated
-accepted -> blocked
-```
-
-An accepted element may become blocked if new evidence creates a serious
-conflict or governance issue.
-
-## Object Lifecycle
-
-An object may move to `review_ready` when it has:
-
-- stable `id`;
-- `kind`;
-- `title`;
-- `summary`;
-- readiness value;
-- profile;
-- evidence boundary or explicit reason why evidence is not yet available.
-
-An object may move to `accepted` when:
-
-- it has been reviewed for meaning;
-- its evidence is sufficient for the current use;
-- it does not duplicate another accepted object;
-- privacy and public-safety rules are satisfied.
-
-## Relation Lifecycle
-
-A relation may move to `review_ready` when it has:
-
-- stable `id`;
-- relation `type`;
-- existing `source` object;
-- existing `target` object;
-- evidence or explicit rationale;
-- directionality checked.
-
-A relation may move to `accepted` when:
-
-- source and target are correct;
-- relation type is appropriate;
-- direction is correct;
-- evidence is sufficient;
-- contradiction handling is complete.
-
-## Context-Pack Lifecycle
-
-A generated context pack starts as `draft` unless it is produced by an accepted
-and validated generation procedure.
-
-A context pack may be `accepted` only for a specific task, time and evidence
-boundary. It must not replace canonical graph state.
-
-## Governance Lifecycle
-
-Governance gates can block:
-
-- canonical updates;
-- public release;
-- generated context use;
-- automated action;
-- claims about validation or readiness.
-
-When a governance gate blocks progress, record:
-
-- blocked element;
-- reason;
-- owner or reviewer;
-- required evidence;
-- next review point.
-
-## Anti-Patterns
-
-- Treating `draft` graph elements as authoritative.
-- Using generated context as canonical state.
-- Marking elements `accepted` without evidence or review.
-- Hiding contradictions by deleting blocked elements.
-- Reusing a context pack outside its task boundary.

package/standard/multi-agent-coordination.md

@@ -1,50 +0,0 @@
-# Multi-Agent Coordination
-
-Status: 1.0 release-candidate standard section
-
-## Purpose
-
-Multi-agent coordination defines how several humans, agents or services can
-work on one graph-governed system without duplicating ownership, overwriting
-canonical state or creating hidden coupling.
-
-## Coordination Principle
-
-Parallel work is allowed only when each worker has:
-
-- a reservation;
-- a bounded scope;
-- an execution branch or workspace;
-- allowed files or allowed actions;
-- evidence path;
-- proposal path;
-- coordinator ownership;
-- conflict-resolution rule.
-
-No worker should own canonical graph writes by default.
-
-## Coordination Objects
-
-- coordination contract;
-- work reservation;
-- branch or workspace reservation;
-- evidence pack;
-- sync proposal;
-- review result;
-- approval or release decision.
-
-## Locking Rules
-
-- one active owner per bounded execution scope;
-- no parallel canonical updates without coordinator review;
-- cross-scope changes require impact analysis before execution;
-- conflicting proposals are resolved by coordinator decision;
-- reservations must be releasable, supersedable or recoverable.
-
-## Schema
-
-Machine-readable coordination contracts can be validated with:
-
-```text
-schemas/multi-agent-coordination.schema.json
-```

package/standard/multi-source-quality-feedback.md

@@ -1,71 +0,0 @@
-# Multi-Source Quality Feedback
-
-Multi-Source Quality Feedback is a Mirai Graph pattern for combining quality signals from tests, validators, cockpit instruments, human review, runtime feedback, and Kaizen into one classified transition input.
-
-It exists because passing tests alone can miss process violations, semantic gaps, unsafe assumptions, and technology drift.
-
-## Pattern
-
-```text
-work evidence
--> source-specific feedback
--> normalized findings
--> classification
--> blocking decision
--> transition route
--> Kaizen or proposal path
-```
-
-## Sources
-
-Recommended feedback sources include:
-
-- automated tests;
-- static or schema validators;
-- process-transition validation;
-- technology quality feedback;
-- development cockpit signals;
-- feature implementation traceability;
-- human expert review;
-- runtime observations;
-- user or stakeholder feedback.
-
-Each source should declare evidence references and limitations. A source can support a decision, but no single source silently overrides the required gate.
-
-## Finding Classification
-
-Findings should be classified with reusable categories:
-
-- `accepted`;
-- `work_fix_required`;
-- `test_gap`;
-- `spec_gap`;
-- `graph_update_proposal`;
-- `process_improvement`;
-- `release_blocker`;
-- `security_blocker`;
-- `defer_with_reason`.
-
-Blocking findings stop the transition they block. Non-blocking findings must still declare a route: continue, fix, defer, proposal, or Kaizen.
-
-## Transition Use
-
-A multi-source feedback report should make the transition decision explicit:
-
-- `accepted_for_transition`;
-- `changes_requested`;
-- `blocked`;
-- `defer_with_reason`;
-- `proposal_required`.
-
-The report can calibrate a decision, but it is not a canonical update and does not replace approval.
-
-## Kaizen Use
-
-When feedback reveals a repeatable weakness in the work technology, it should route to Kaizen:
-
-```text
-finding -> classified improvement -> prevention mechanism -> next governed cycle
-```
-
-The prevention mechanism should be durable: checklist update, validator change, template improvement, reviewer instruction, gate refinement, or documented limitation.