red-methodology 0.1.0__py3-none-any.whl

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
red_cli/__init__.py ADDED
@@ -0,0 +1,4 @@
1
+ """RED methodology command-line interface."""
2
+
3
+ __version__ = "0.1.0"
4
+ PROTOCOL_VERSION = 1
@@ -0,0 +1,60 @@
1
+ {
2
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
3
+ "$id": "https://github.com/exoticknight/red/blob/main/spec/artifact-schema.json",
4
+ "title": "RED Protocol 1 artifact metadata",
5
+ "type": "object",
6
+ "additionalProperties": false,
7
+ "required": ["id", "state", "status", "title", "created"],
8
+ "properties": {
9
+ "id": { "type": "string" },
10
+ "state": { "enum": ["research", "evolve"] },
11
+ "status": { "enum": ["open", "closed", "accepted", "rejected"] },
12
+ "title": { "type": "string", "minLength": 1 },
13
+ "created": {
14
+ "type": "string",
15
+ "format": "date",
16
+ "pattern": "^[0-9]{4}-(0[1-9]|1[0-2])-([0-2][0-9]|3[01])$"
17
+ },
18
+ "based_on": {
19
+ "type": "array",
20
+ "uniqueItems": true,
21
+ "items": { "type": "string", "pattern": "^[RE]-(?:[1-9][0-9]*|0[0-9]{3})$" }
22
+ },
23
+ "document_paths": {
24
+ "type": "array",
25
+ "minItems": 1,
26
+ "uniqueItems": true,
27
+ "items": {
28
+ "type": "string",
29
+ "minLength": 1,
30
+ "allOf": [
31
+ { "not": { "pattern": "^(?:[A-Za-z]:|/|\\\\)" } },
32
+ { "not": { "pattern": "(^|[\\\\/])\\.\\.([\\\\/]|$)" } }
33
+ ]
34
+ }
35
+ },
36
+ "verified": { "type": "boolean" }
37
+ },
38
+ "allOf": [
39
+ {
40
+ "if": { "properties": { "state": { "const": "research" } }, "required": ["state"] },
41
+ "then": {
42
+ "properties": {
43
+ "id": { "type": "string", "pattern": "^R-(?:[1-9][0-9]*|0[0-9]{3})$" },
44
+ "status": { "enum": ["open", "closed"] }
45
+ }
46
+ }
47
+ },
48
+ {
49
+ "if": { "properties": { "state": { "const": "evolve" } }, "required": ["state"] },
50
+ "then": { "properties": { "id": { "type": "string", "pattern": "^E-(?:[1-9][0-9]*|0[0-9]{3})$" } } }
51
+ },
52
+ {
53
+ "if": { "properties": { "status": { "const": "accepted" } }, "required": ["status"] },
54
+ "then": {
55
+ "required": ["document_paths", "verified"],
56
+ "properties": { "verified": { "const": true } }
57
+ }
58
+ }
59
+ ]
60
+ }
@@ -0,0 +1,57 @@
1
+ {
2
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
3
+ "$id": "https://github.com/exoticknight/red/blob/main/spec/config-schema.json",
4
+ "title": "RED Protocol 1 configuration",
5
+ "type": "object",
6
+ "additionalProperties": false,
7
+ "required": ["version", "document", "research", "evolve", "policy"],
8
+ "properties": {
9
+ "version": {
10
+ "type": "integer",
11
+ "minimum": 1,
12
+ "maximum": 9007199254740991
13
+ },
14
+ "document": { "$ref": "#/$defs/document" },
15
+ "research": { "$ref": "#/$defs/artifactDirectory" },
16
+ "evolve": { "$ref": "#/$defs/artifactDirectory" },
17
+ "policy": { "$ref": "#/$defs/policy" }
18
+ },
19
+ "$defs": {
20
+ "relativePath": {
21
+ "type": "string",
22
+ "minLength": 1,
23
+ "allOf": [
24
+ { "not": { "pattern": "^(?:[A-Za-z]:|/|\\\\)" } },
25
+ { "not": { "pattern": "(^|[\\\\/])\\.\\.([\\\\/]|$)" } }
26
+ ]
27
+ },
28
+ "document": {
29
+ "type": "object",
30
+ "additionalProperties": false,
31
+ "required": ["paths"],
32
+ "properties": {
33
+ "paths": {
34
+ "type": "array",
35
+ "minItems": 1,
36
+ "uniqueItems": true,
37
+ "items": { "$ref": "#/$defs/relativePath" }
38
+ }
39
+ }
40
+ },
41
+ "artifactDirectory": {
42
+ "type": "object",
43
+ "additionalProperties": false,
44
+ "required": ["path"],
45
+ "properties": { "path": { "$ref": "#/$defs/relativePath" } }
46
+ },
47
+ "policy": {
48
+ "type": "object",
49
+ "additionalProperties": false,
50
+ "required": ["document_requires_approval", "report_document_implementation_conflicts"],
51
+ "properties": {
52
+ "document_requires_approval": { "type": "boolean" },
53
+ "report_document_implementation_conflicts": { "type": "boolean" }
54
+ }
55
+ }
56
+ }
57
+ }
@@ -0,0 +1,38 @@
1
+ ---
2
+ name: red
3
+ description: Manage project knowledge and engineering changes with Research, Evolve, and Document. Use when the user requests RED, or when a repository declares RED through red.toml, RED.md, or AGENTS.md. Do not impose RED on undeclared projects.
4
+ metadata:
5
+ red-protocol: "1"
6
+ ---
7
+
8
+ # RED
9
+
10
+ Keep accepted knowledge, unresolved research, and ongoing change distinct.
11
+
12
+ ## Knowledge and authority
13
+
14
+ - Document is the normative baseline for people and agents using, maintaining, or changing the project. Organize accepted knowledge and necessary rationale around their tasks; keep R/E record references, provenance, and work history on the R/E side. Use the Document writing guidance in `references/artifacts.md` when drafting or updating it.
15
+ - Research holds unverified evidence, claims, and questions. Evolve holds proposed or ongoing change and unresolved alternatives.
16
+ - Code, tests, configuration, and runtime output are implementation evidence. Investigate and report conflicts with Document before choosing a side.
17
+ - At an R/E boundary, present the reviewable result and wait for a separately authorized transition. A broad earlier request does not supply that decision. Update Document only after acceptance.
18
+ - Preserve existing documentation structure and project storage/version-control policy. Keep small, resolved work in the task; persist consequential or shared work using the criteria in `references/work.md`.
19
+
20
+ ## Load context on demand
21
+
22
+ 1. Follow applicable repository instructions. Read `red.toml` when present; otherwise locate likely Document sources. Create configuration only for requested adoption or deterministic operations needing a mapping.
23
+ 2. Read the reference for the current route below. Load additional references only when their operation becomes necessary; links are lookup targets, not a recursive reading list.
24
+ 3. Find relevant Document sections, active E items, R evidence, and implementation with filenames, headings, or scoped search before reading bodies. Widen the search when dependencies or conflicts require it.
25
+ 4. Reuse instructions and evidence already available in context. Re-read changed sections, or missing material after compaction, rather than restarting discovery each turn. Keep tool output focused on relevant excerpts and results.
26
+
27
+ ## Routes
28
+
29
+ - Engineering work and E maintenance: [work.md](references/work.md).
30
+ - First-time or brownfield adoption: [adopt.md](references/adopt.md).
31
+ - Project health checks: [inspect.md](references/inspect.md).
32
+ - Creating/promoting artifacts or drafting/updating Document: [artifacts.md](references/artifacts.md).
33
+ - Using, enabling, or falling back from the CLI: [cli.md](references/cli.md).
34
+ - Unclear state semantics: [protocol.md](references/protocol.md); unfamiliar routing cases: [scenarios.md](references/scenarios.md).
35
+
36
+ ## Finish
37
+
38
+ Reconcile active E with current decisions, evidence, remaining work, and open alternatives. Report verification, conflicts, and unknowns; apply the transition boundary above. Run `red check --json` when the CLI is available, and state when it could not run.
@@ -0,0 +1,7 @@
1
+ interface:
2
+ display_name: "RED"
3
+ short_description: "Manage project knowledge through RED states"
4
+ default_prompt: "Use $red to handle this project task with the RED methodology."
5
+
6
+ policy:
7
+ allow_implicit_invocation: true
@@ -0,0 +1,5 @@
1
+ <!-- red:start protocol=1 -->
2
+ ## RED workflow
3
+
4
+ Use Research for unresolved evidence and questions, Evolve for proposed or ongoing changes, and Document for accepted project knowledge. A clear change may enter Evolve directly. After Research, report findings and wait for explicit authority before Evolve. After Evolve passes verification, report evidence and proposed Document changes, then wait for separate acceptance before updating Document. Do not treat Research as a requirement or silently resolve open Evolve alternatives. Follow the project's version-control policy for Research and Evolve; RED does not choose one. Report conflicts between Document and implementation evidence.
5
+ <!-- red:end -->
@@ -0,0 +1,33 @@
1
+ # RED Agent Instructions
2
+
3
+ This project uses RED Protocol 1 to separate unresolved research, ongoing change, and accepted project knowledge.
4
+
5
+ ## Knowledge states
6
+
7
+ ### Research
8
+
9
+ Research contains unresolved questions, evidence, hypotheses, experiments, and conflicting claims. Do not treat it as accepted requirements.
10
+
11
+ ### Evolve
12
+
13
+ Evolve contains proposed or active changes, their rationale, affected areas, acceptance conditions, and open questions. Preserve unresolved alternatives until the user or project policy decides them.
14
+
15
+ ### Document
16
+
17
+ Document contains accepted project goals, terminology, interfaces, architecture rules, operating instructions, and contribution rules. Treat it as the normative baseline.
18
+
19
+ Code, tests, configuration, and runtime output provide implementation evidence. Report conflicts with Document and investigate them through Research. A resulting decision may repair the implementation or create an Evolve item that changes Document.
20
+
21
+ ## Workflow
22
+
23
+ 1. Read repository instructions and `red.toml` when present.
24
+ 2. Load only the Document, active Evolve, Research, and implementation evidence relevant to the task.
25
+ 3. Implement directly when accepted knowledge specifies the work.
26
+ 4. Use Research when an unknown can change the decision. Report findings and wait for explicit authority before entering Evolve.
27
+ 5. Use Evolve when the task changes accepted behavior, data, public interfaces, architecture, or engineering rules. A clear change may enter Evolve directly.
28
+ 6. Design, implement, test, and revise inside the authorized Evolve scope.
29
+ 7. When acceptance conditions pass, report evidence and proposed Document changes. Wait for separate acceptance before updating Document.
30
+ 8. Persist R or E when work crosses tasks, needs review, presents alternatives, or leaves an unresolved conflict.
31
+ 9. Run `red check --json` when the CLI is available.
32
+
33
+ Prefer the RED CLI for deterministic operations. If it is unavailable, follow the same protocol by hand. CLI promotion records a decision supplied by the user or project; it does not authorize the transition. Follow the project's version-control policy for Research and Evolve; RED does not require tracked files, local files, or an external tracker. Do not reorganize existing documentation or install tools globally without authorization.
@@ -0,0 +1,14 @@
1
+ version = 1
2
+
3
+ [document]
4
+ paths = ["README.md", "docs/**"]
5
+
6
+ [research]
7
+ path = "research"
8
+
9
+ [evolve]
10
+ path = "evolve"
11
+
12
+ [policy]
13
+ document_requires_approval = true
14
+ report_document_implementation_conflicts = true
@@ -0,0 +1,15 @@
1
+ # Adopt RED
2
+
3
+ Adopt RED without reorganizing the repository.
4
+
5
+ 1. Inventory existing README files, maintained docs, ADRs, proposals, investigations, issues, and contribution rules.
6
+ 2. Propose a mapping for Document, Evolve, and Research. Explain ambiguous locations.
7
+ 3. Prefer the RED CLI. Run `red init` only after the task authorizes project setup.
8
+ 4. Edit the generated `red.toml` to reflect the accepted mapping.
9
+ 5. Run `red check --json`.
10
+
11
+ Do not migrate old documents or reconstruct historical decisions. Classify current sources and use RED for work from this point forward.
12
+
13
+ Choose whether the project tracks Research and Evolve files, keeps them local, or uses its issue or pull-request system. Record the choice in repository guidance or ignore rules; RED supplies no default.
14
+
15
+ For agents without Skill support, use `red instructions install --target AGENTS.md` or `red instructions export --output RED.md`.
@@ -0,0 +1,69 @@
1
+ # RED artifacts
2
+
3
+ Use UTF-8 Markdown with TOML front matter delimited by `+++` for Research and Evolve artifacts. Document follows the project's documentation format and the writing guidance below.
4
+
5
+ ## Research
6
+
7
+ ```md
8
+ +++
9
+ id = "R-1"
10
+ state = "research"
11
+ status = "open"
12
+ title = "Tag semantics"
13
+ created = "2026-09-05"
14
+ +++
15
+
16
+ # R-1: Tag semantics
17
+
18
+ ## Question
19
+
20
+ ## Evidence
21
+
22
+ ## Unknowns
23
+ ```
24
+
25
+ ## Evolve
26
+
27
+ ```md
28
+ +++
29
+ id = "E-1"
30
+ state = "evolve"
31
+ status = "open"
32
+ title = "Add tags"
33
+ created = "2026-09-05"
34
+ based_on = ["R-1"]
35
+ +++
36
+
37
+ # E-1: Add tags
38
+
39
+ ## Change
40
+
41
+ ## Rationale
42
+
43
+ ## Acceptance
44
+
45
+ ## Open questions
46
+ ```
47
+
48
+ Create new artifacts with sequential positive integers without leading zeros within each state. Identifiers have no fixed digit width. Accept legacy four-digit, zero-padded identifiers when reading an existing project, and count them during allocation. Filenames start with the identifier and a readable slug. Keep source artifacts in the working environment while their history remains useful.
49
+
50
+ Version control is project policy. Inspect repository guidance and ignore rules before staging Research or Evolve. A project may track the files, keep them local, or represent shared work in issues or pull requests.
51
+
52
+ The CLI may validate promotion readiness and record an accepted decision. The agent presents Research findings before Research-to-Evolve promotion and presents Evolve evidence plus proposed Document changes before Evolve-to-Document promotion. It must not invent agreement or rewrite Document content without an authorized decision.
53
+
54
+ ## Write Document for its readers
55
+
56
+ Document serves people and agents who need accepted project knowledge while using a feature, implementing a change, reviewing behavior, or diagnosing a problem. Assume they arrive through a search or a direct link without the originating conversation.
57
+
58
+ Before writing, identify the intended reader, the situation that brings them here, and the question or action the page should support. Use those answers to choose the scope and presentation: procedures for performing tasks, contracts and examples for implementing against interfaces, or boundaries and rationale for making design decisions. Fit the existing documentation structure; these are choices, not mandatory sections.
59
+
60
+ When drafting proposed Document content or applying an accepted change:
61
+
62
+ 1. Lead with the answer the reader needs. Extract the accepted definitions, behavior, rules, boundaries, and necessary rationale, and state them directly. Use descriptive headings and concrete examples where they help the reader act. Update the relevant explanation in place when behavior changes.
63
+ 2. Keep working history and unresolved alternatives in R/E. Remove R/E record identifiers, links, citations, provenance footnotes, and narratives about how those records produced the result. This includes optional history or source links. Record any traceability from R/E to the relevant Document paths instead.
64
+ 3. Omit authoring dates, last-updated stamps, implementation commit hashes, completion reports, and verification logs from ordinary knowledge pages. Keep delivery evidence in E or version-control history. Include a date, version, or revision only when it changes how the reader interprets or uses the content, or a project-required document format calls for it; explain its role. Examples include an effective date, a supported version range, or an exact revision required for a reproducible procedure. Preserve purposeful metadata in established ADR, release, or audit formats without spreading that format to other pages.
65
+ 4. Review the page as its intended reader with R/E, task history, and commit history unavailable. Can they find the answer, understand its scope and rationale, and take the intended action? Remove metadata that does not help those tasks. Fill gaps from accepted knowledge; if a gap needs a new decision, keep it open in E and obtain that decision before presenting it as accepted content.
66
+
67
+ For example, replace “Implemented retry handling in commit abc123 on 2026-09-11; verification passed” with the accepted contract: “Transient failures are retried up to three times. Authentication failures return immediately.” Add the rationale or usage detail the reader needs. Keep a migration deadline when it determines when the reader must act.
68
+
69
+ Completion requires both independent readability and absence of references to R/E working records. Existing Document-to-Document organization may be preserved. A document whose subject is RED may explain Research and Evolve as concepts; that does not make a particular working record part of Document.
@@ -0,0 +1,44 @@
1
+ # RED CLI
2
+
3
+ Prefer the CLI for configuration, identifiers, templates, installation, status, and structural checks.
4
+
5
+ ## Detection and enablement
6
+
7
+ 1. Use an existing `red` executable.
8
+ 2. In a Node project, try the project-local package or the official pinned `npx` package.
9
+ 3. In a Python project, try the installed package or the official pinned `pipx` runner.
10
+ 4. Make at most one network-backed attempt in a task. Follow the host's approval rules.
11
+ 5. Do not install globally or change project dependencies unless the user asks.
12
+ 6. Continue by hand when the CLI is unavailable, incompatible, declined, or offline.
13
+
14
+ ## Commands
15
+
16
+ ```text
17
+ red init
18
+ red new research --title <title>
19
+ red new evolve --title <title> [--from <id>]
20
+ red status --json
21
+ red check --json
22
+ red promote <artifact> --to evolve
23
+ red promote <artifact> --to document --accepted --verified --document <path>
24
+ red skill install [--scope user|repo]
25
+ red skill status [--scope user|repo]
26
+ red skill update [--scope user|repo]
27
+ red skill uninstall [--scope user|repo]
28
+ red instructions install --target AGENTS.md
29
+ red instructions uninstall --target AGENTS.md
30
+ red instructions export --output RED.md
31
+ ```
32
+
33
+ One-shot forms:
34
+
35
+ ```text
36
+ npx -y @exoticknight/red@latest <command>
37
+ pipx run --spec red-methodology red <command>
38
+ ```
39
+
40
+ The CLI installs the Skill snapshot shipped in its own release. Use `skill status` to inspect `.red-install.json` and `skill update` to replace only an installation managed by RED.
41
+
42
+ The CLI handles structure, not transition authority. Invoke Research-to-Evolve promotion only after the user or a project-authorized decision source approves the proposed scope. Pass `--accepted` and `--verified` only after Evolve evidence has been presented and the result has received separate acceptance. A successful command records those supplied assertions; it does not prove that the decision occurred.
43
+
44
+ Use `--json` when consuming command output. Protocol incompatibility is a hard stop for CLI mutation; fall back to manual work under the protocol supported by the project.
@@ -0,0 +1,15 @@
1
+ # Inspect a RED project
2
+
3
+ Inspect these conditions:
4
+
5
+ - `red.toml` parses and uses a supported protocol version.
6
+ - Declared paths exist or have a clear reason to remain empty.
7
+ - R and E identifiers are unique.
8
+ - Research claims have not leaked into Document as accepted facts.
9
+ - Evolve alternatives have not been resolved without a recorded decision.
10
+ - Accepted changes have matching implementation and Document updates.
11
+ - Document meets the reader and writing criteria in [artifacts.md](artifacts.md): readers can find and use accepted knowledge without working history; dates and revisions have a reader-facing purpose or a required format; R/E record references and process narratives stay in R/E.
12
+ - Document conflicts with code, tests, configuration, or runtime evidence are visible.
13
+ - Installed Skill or exported instructions implement the configured protocol.
14
+
15
+ Use `red status --json` and `red check --json` when available. Add semantic findings from reading the relevant content; the CLI cannot make those judgments.
@@ -0,0 +1,33 @@
1
+ # RED Protocol 1
2
+
3
+ RED assigns project knowledge to one of three states.
4
+
5
+ ## Research
6
+
7
+ Research holds unresolved questions, observations, external sources, hypotheses, experiments, and conflicting evidence. A Research item may stay incomplete. Label claims and uncertainty so an agent cannot mistake them for requirements.
8
+
9
+ Research supports an Evolve proposal through explicit references. Promotion does not copy every note into Evolve.
10
+
11
+ When Research can support an Evolve scope, the agent reports its findings and waits for an explicit human decision or a decision source that the project has authorized. RED does not require Research when the change and its acceptance conditions are already clear.
12
+
13
+ ## Evolve
14
+
15
+ Evolve holds a proposed or active change. Record the problem, proposed change, tradeoffs, affected areas, acceptance conditions, and open questions. Design, implementation, tests, revision, and user interaction remain in Evolve until acceptance. An explicit user request can authorize work on an Evolve item. Open alternatives remain undecided until the user or project policy resolves them.
16
+
17
+ After implementation and verification, the agent reports its evidence and proposed Document changes, then waits for explicit acceptance. An accepted Evolve item updates the relevant Document sources. A rejected item leaves Document unchanged. A partially accepted item records the accepted boundary and updates Document only for that part.
18
+
19
+ ## Document
20
+
21
+ Document contains accepted goals, boundaries, terminology, public interfaces, architecture rules, operating instructions, and contribution rules. Agents start from Document and treat it as the normative baseline.
22
+
23
+ Document can become stale. Code, tests, configuration, and runtime output provide implementation evidence. A conflict between the baseline and evidence enters Research. The resulting decision may restore the implementation to Document or create an Evolve item that changes the baseline.
24
+
25
+ ## Transition authority
26
+
27
+ A broad request to complete work does not authorize later transitions whose results were not ready for review when the request was made. The user decides at the Research and Evolve checkpoints, unless the project defines another human-approved decision source such as an issue state or pull-request approval. CLI flags record a supplied decision; they do not create authority.
28
+
29
+ ## Persistence
30
+
31
+ RED classifies knowledge in every task but does not require a file for every thought. Persist Research or Evolve when work crosses tasks, needs review, presents alternatives, affects public behavior or architecture, or leaves an unresolved conflict. Keep short-lived local reasoning in the active task.
32
+
33
+ Persistence and publication are separate decisions. Each project chooses whether to track Research and Evolve files, keep them local, or publish the work through another collaboration system. Tracking changes availability, not knowledge state: an R or E artifact does not become Document when committed.
@@ -0,0 +1,25 @@
1
+ # Scenario routing
2
+
3
+ | Situation | Route | Persistent artifact |
4
+ |---|---|---|
5
+ | Work already specified by Document | Implement | Usually none |
6
+ | Clear accepted feature request | Evolve | Persist for public or cross-task change |
7
+ | Ambiguous feature request | Research, then Evolve | Persist unresolved evidence and consequential change |
8
+ | Research has enough evidence for a proposal | Report findings and stop | Wait for explicit authority before Evolve |
9
+ | Diagnose a bug | Research | Persist when findings must survive the task |
10
+ | Repair behavior that violates Document | Research, then repair | Document stays unchanged |
11
+ | Change a public interface | Evolve | Persist and update Document after acceptance |
12
+ | Mechanical internal refactor | Implement | Usually none |
13
+ | Architectural refactor | Evolve | Persist |
14
+ | Experimental spike | Research | Do not promote without a decision |
15
+ | Document conflicts with implementation | Research | Persist unresolved conflict |
16
+ | Evolve item rejected | Close Evolve | Document stays unchanged |
17
+ | Evolve item partly accepted | Record boundary | Update Document for accepted part |
18
+ | Evolve passes its acceptance conditions | Report evidence and stop | Wait for explicit acceptance before Document |
19
+ | Urgent repair | Restore accepted behavior, then record material findings | Keep the record proportional |
20
+ | Repository is read-only | Analyze and report | No writes |
21
+ | User declines CLI or docs | Work in task context | Explain unresolved continuity risk |
22
+ | CLI cannot run | Follow artifact rules by hand | Report skipped structural validation |
23
+ | Concurrent Evolve items conflict | Preserve both and request a decision | Do not merge conclusions |
24
+
25
+ “Persist” means keep the work available beyond the current task. The project decides whether that means tracked files, local files, issues, pull requests, or another system.
@@ -0,0 +1,31 @@
1
+ # Work with RED
2
+
3
+ ## Ground and route
4
+
5
+ Use the entrypoint's context-loading rules. Start from the relevant Document baseline and active E summary; follow R or historical evidence to resolve current questions.
6
+
7
+ - Implement directly when Document or active E specifies the work and no decision-blocking unknown remains.
8
+ - Use Research for unknowns that can change implementation or acceptance, including Document/evidence conflicts.
9
+ - Use Evolve for changes to accepted behavior, public interfaces, data, architecture, or engineering rules.
10
+
11
+ A clear feature request may authorize direct entry to Evolve. A bug violating Document may proceed from diagnosis to repair without changing Document. Route by knowledge state rather than a mandatory R-to-E-to-D sequence.
12
+
13
+ ## Maintain active E
14
+
15
+ On resumption or new instructions, compare active E with the request and current evidence. Before dependent work, record material changes to scope, design, acceptance, decisions, or constraints, including findings that change the plan. Distinguish authorized decisions from unresolved alternatives; a user request clearly authorizing an adjustment supplies that authority. Ordinary E maintenance needs no separate approval.
16
+
17
+ After meaningful results, record concise evidence, verification status (including failed or pending checks), and remaining work. Before pause, handoff, or completion, reconcile E with actual work and current decisions. Batch minor edits until these triggers. If storage is unavailable, preserve the update in the task and identify the blocker.
18
+
19
+ Keep current scope, decisions, acceptance, verification, and next steps easy to resume. Replace stale status while retaining decision rationale, unresolved alternatives, and review evidence. Link detailed logs or experiments from R/E instead of copying output or appending every turn. Update affected sections without re-reading the whole record after each edit.
20
+
21
+ ## Persist
22
+
23
+ Persist work that crosses tasks, needs review, presents alternatives, affects public behavior or architecture, or leaves an unresolved conflict. Keep small local work in task context when persistence is unnecessary. Use the CLI when available; consult `artifacts.md` for record structure. Follow project storage and version-control policy; artifact creation does not authorize publication.
24
+
25
+ ## Execute and report
26
+
27
+ Investigate within Research; design, implement, verify, and revise within authorized Evolve scope. Seek a decision for scope expansion. Apply the entrypoint's transition boundary:
28
+
29
+ - Present R findings, uncertainty, risks, and proposed E scope for a decision.
30
+ - Present E verification evidence and proposed Document changes for acceptance.
31
+ - Record authorized promotions; synchronize accepted E behavior with Document.