recall-os 0.2.0 → 0.3.0

package/examples/generated-flutter/AGENTS.md

@@ -13,3 +13,16 @@ Required reading:
 - `docs/60-engineering/ENGINEERING_STANDARDS.md`
 
 Repository rules override model preferences. If instructions conflict, stop and report the conflict.
+
+## Changing an accepted decision
+
+Before changing anything an accepted ADR governs (framework, database, auth, API shape, and
+similar):
+
+1. Check `docs/adrs/` for an accepted ADR that covers it.
+2. If your change contradicts one, stop and confirm with a human first — do not silently change the
+   code and leave the ADR saying the opposite.
+3. Record the change as a new decision with `recall adr supersede <old> <new-title>`. That
+   supersedes the old ADR instead of overwriting history, so the reasoning stays auditable.
+
+Repository memory is only trustworthy if decisions change through this trail, not silently.

package/examples/generated-flutter/docs/20-security/SECURITY_MODEL.md

@@ -1,11 +1,32 @@
 # Security Model
 
-## Current Status
+## Status
 
-Draft.
+Draft — fill the prompted sections below with this repository's real model as it grows.
+`recall doctor` flags these as warnings once the repository has real work (a feature, module, or
+accepted decision).
 
 ## Baseline Rules
 
-- Do not commit secrets.
-- Do not read or copy `.env` files into docs.
+- Never commit secrets or credentials, and never read or copy `.env` files into docs.
+- Validate and authorize untrusted input at every trust boundary.
 - Do not add network, telemetry, cloud, MCP runtime, or AI API behavior without explicit review.
+
+## Authentication And Authorization
+
+Describe how this repository authenticates users or clients and how it authorizes actions, including
+where those checks live.
+
+## Secrets And Configuration
+
+Describe where secrets live, how they are injected, and how configuration is kept out of version
+control.
+
+## Sensitive Data
+
+Describe the sensitive or personal data this repository handles, and how it is protected at rest and
+in transit.
+
+## Dependencies And Supply Chain
+
+Describe how third-party dependencies are vetted, pinned, and updated.

package/examples/generated-flutter/docs/20-security/THREAT_MODEL.md

@@ -1,7 +1,39 @@
 # Threat Model
 
-## Current Status
+## Status
 
-Draft.
+Draft — replace the prompts below with this repository's real analysis as it grows. `recall doctor`
+flags these as warnings once the repository has real work (a feature, module, or accepted decision).
 
-Track repository-specific risks here as the project evolves.
+## Assets
+
+Describe what this repository must protect: user data, credentials, money, availability, or
+reputation.
+
+## Entry Points
+
+Describe where untrusted input enters: HTTP endpoints, webhooks, file uploads, queues, CLI input, or
+third-party callbacks.
+
+## Trust Boundaries
+
+Describe where trust changes: client to server, service to database, your code to third-party APIs.
+
+## Threats
+
+Describe the concrete threats that apply to this repository, by category:
+
+- Spoofing — how identities are faked or sessions stolen.
+- Tampering — how requests, data, or builds are altered (injection, mass assignment).
+- Repudiation — actions that must remain auditable.
+- Information disclosure — how sensitive data or secrets could leak.
+- Denial of service — how the system can be overwhelmed or abused.
+- Elevation of privilege — how a user could gain access they should not have.
+
+## Mitigations
+
+Describe the control in place or planned for each threat above.
+
+## Open Risks
+
+Describe accepted or unresolved risks and who owns them.

package/examples/generated-flutter/docs/60-engineering/AI_AGENT_RULES.md

@@ -4,3 +4,12 @@ AI agents must follow repository memory over model preference.
 
 If a request conflicts with accepted repository memory or engineering standards, stop and report the
 conflict.
+
+## Changing an accepted decision
+
+When work would change something an accepted ADR governs:
+
+1. Find the accepted ADR in `docs/adrs/` that covers it.
+2. If the change contradicts it, stop and confirm with a human before changing the code.
+3. Record the new decision with `recall adr supersede <old> <new-title>` so the old ADR is marked
+   superseded and the reasoning is preserved, instead of silently editing or contradicting it.

package/examples/generated-flutter/docs/ai/RECALL_COMMANDS.md

@@ -108,6 +108,17 @@ Options:
 - `--dry-run`: show planned writes without writing files.
 - `--force`: overwrite existing files explicitly.
 
+### `recall adr supersede <old> <new-title>`
+
+Record a changed decision. Marks an accepted ADR as `Accepted — superseded by ADR-####` and creates
+a new accepted ADR that declares what it supersedes, so the reasoning trail stays auditable instead
+of being overwritten. Doctor then warns about any memory still referencing the superseded decision.
+
+Options:
+
+- `--dry-run`: show planned writes without writing files.
+- `--force`: overwrite existing files explicitly.
+
 ### `recall module create <name>`
 
 Create module memory docs under the configured modules directory.
@@ -124,7 +135,8 @@ engineering evidence is present, and whether memory references decisions that ex
 accepted.
 
 Doctor also runs deterministic drift checks: feature or module memory that references a missing ADR
-is an error, and memory that references a not-yet-accepted ADR is a warning.
+is an error, memory that references a not-yet-accepted ADR is a warning, and memory that still
+references a superseded decision is a warning.
 
 Exit codes:
 

package/examples/generated-generic/AGENTS.md

@@ -13,3 +13,16 @@ Required reading:
 - `docs/60-engineering/ENGINEERING_STANDARDS.md`
 
 Repository rules override model preferences. If instructions conflict, stop and report the conflict.
+
+## Changing an accepted decision
+
+Before changing anything an accepted ADR governs (framework, database, auth, API shape, and
+similar):
+
+1. Check `docs/adrs/` for an accepted ADR that covers it.
+2. If your change contradicts one, stop and confirm with a human first — do not silently change the
+   code and leave the ADR saying the opposite.
+3. Record the change as a new decision with `recall adr supersede <old> <new-title>`. That
+   supersedes the old ADR instead of overwriting history, so the reasoning stays auditable.
+
+Repository memory is only trustworthy if decisions change through this trail, not silently.

package/examples/generated-generic/docs/20-security/SECURITY_MODEL.md

@@ -1,11 +1,32 @@
 # Security Model
 
-## Current Status
+## Status
 
-Draft.
+Draft — fill the prompted sections below with this repository's real model as it grows.
+`recall doctor` flags these as warnings once the repository has real work (a feature, module, or
+accepted decision).
 
 ## Baseline Rules
 
-- Do not commit secrets.
-- Do not read or copy `.env` files into docs.
+- Never commit secrets or credentials, and never read or copy `.env` files into docs.
+- Validate and authorize untrusted input at every trust boundary.
 - Do not add network, telemetry, cloud, MCP runtime, or AI API behavior without explicit review.
+
+## Authentication And Authorization
+
+Describe how this repository authenticates users or clients and how it authorizes actions, including
+where those checks live.
+
+## Secrets And Configuration
+
+Describe where secrets live, how they are injected, and how configuration is kept out of version
+control.
+
+## Sensitive Data
+
+Describe the sensitive or personal data this repository handles, and how it is protected at rest and
+in transit.
+
+## Dependencies And Supply Chain
+
+Describe how third-party dependencies are vetted, pinned, and updated.

package/examples/generated-generic/docs/20-security/THREAT_MODEL.md

@@ -1,7 +1,39 @@
 # Threat Model
 
-## Current Status
+## Status
 
-Draft.
+Draft — replace the prompts below with this repository's real analysis as it grows. `recall doctor`
+flags these as warnings once the repository has real work (a feature, module, or accepted decision).
 
-Track repository-specific risks here as the project evolves.
+## Assets
+
+Describe what this repository must protect: user data, credentials, money, availability, or
+reputation.
+
+## Entry Points
+
+Describe where untrusted input enters: HTTP endpoints, webhooks, file uploads, queues, CLI input, or
+third-party callbacks.
+
+## Trust Boundaries
+
+Describe where trust changes: client to server, service to database, your code to third-party APIs.
+
+## Threats
+
+Describe the concrete threats that apply to this repository, by category:
+
+- Spoofing — how identities are faked or sessions stolen.
+- Tampering — how requests, data, or builds are altered (injection, mass assignment).
+- Repudiation — actions that must remain auditable.
+- Information disclosure — how sensitive data or secrets could leak.
+- Denial of service — how the system can be overwhelmed or abused.
+- Elevation of privilege — how a user could gain access they should not have.
+
+## Mitigations
+
+Describe the control in place or planned for each threat above.
+
+## Open Risks
+
+Describe accepted or unresolved risks and who owns them.

package/examples/generated-generic/docs/60-engineering/AI_AGENT_RULES.md

@@ -4,3 +4,12 @@ AI agents must follow repository memory over model preference.
 
 If a request conflicts with accepted repository memory or engineering standards, stop and report the
 conflict.
+
+## Changing an accepted decision
+
+When work would change something an accepted ADR governs:
+
+1. Find the accepted ADR in `docs/adrs/` that covers it.
+2. If the change contradicts it, stop and confirm with a human before changing the code.
+3. Record the new decision with `recall adr supersede <old> <new-title>` so the old ADR is marked
+   superseded and the reasoning is preserved, instead of silently editing or contradicting it.

package/examples/generated-generic/docs/ai/RECALL_COMMANDS.md

@@ -108,6 +108,17 @@ Options:
 - `--dry-run`: show planned writes without writing files.
 - `--force`: overwrite existing files explicitly.
 
+### `recall adr supersede <old> <new-title>`
+
+Record a changed decision. Marks an accepted ADR as `Accepted — superseded by ADR-####` and creates
+a new accepted ADR that declares what it supersedes, so the reasoning trail stays auditable instead
+of being overwritten. Doctor then warns about any memory still referencing the superseded decision.
+
+Options:
+
+- `--dry-run`: show planned writes without writing files.
+- `--force`: overwrite existing files explicitly.
+
 ### `recall module create <name>`
 
 Create module memory docs under the configured modules directory.
@@ -124,7 +135,8 @@ engineering evidence is present, and whether memory references decisions that ex
 accepted.
 
 Doctor also runs deterministic drift checks: feature or module memory that references a missing ADR
-is an error, and memory that references a not-yet-accepted ADR is a warning.
+is an error, memory that references a not-yet-accepted ADR is a warning, and memory that still
+references a superseded decision is a warning.
 
 Exit codes:
 

package/examples/generated-ios-swift/AGENTS.md

@@ -13,3 +13,16 @@ Required reading:
 - `docs/60-engineering/ENGINEERING_STANDARDS.md`
 
 Repository rules override model preferences. If instructions conflict, stop and report the conflict.
+
+## Changing an accepted decision
+
+Before changing anything an accepted ADR governs (framework, database, auth, API shape, and
+similar):
+
+1. Check `docs/adrs/` for an accepted ADR that covers it.
+2. If your change contradicts one, stop and confirm with a human first — do not silently change the
+   code and leave the ADR saying the opposite.
+3. Record the change as a new decision with `recall adr supersede <old> <new-title>`. That
+   supersedes the old ADR instead of overwriting history, so the reasoning stays auditable.
+
+Repository memory is only trustworthy if decisions change through this trail, not silently.

package/examples/generated-ios-swift/docs/20-security/SECURITY_MODEL.md

@@ -1,11 +1,32 @@
 # Security Model
 
-## Current Status
+## Status
 
-Draft.
+Draft — fill the prompted sections below with this repository's real model as it grows.
+`recall doctor` flags these as warnings once the repository has real work (a feature, module, or
+accepted decision).
 
 ## Baseline Rules
 
-- Do not commit secrets.
-- Do not read or copy `.env` files into docs.
+- Never commit secrets or credentials, and never read or copy `.env` files into docs.
+- Validate and authorize untrusted input at every trust boundary.
 - Do not add network, telemetry, cloud, MCP runtime, or AI API behavior without explicit review.
+
+## Authentication And Authorization
+
+Describe how this repository authenticates users or clients and how it authorizes actions, including
+where those checks live.
+
+## Secrets And Configuration
+
+Describe where secrets live, how they are injected, and how configuration is kept out of version
+control.
+
+## Sensitive Data
+
+Describe the sensitive or personal data this repository handles, and how it is protected at rest and
+in transit.
+
+## Dependencies And Supply Chain
+
+Describe how third-party dependencies are vetted, pinned, and updated.

package/examples/generated-ios-swift/docs/20-security/THREAT_MODEL.md

@@ -1,7 +1,39 @@
 # Threat Model
 
-## Current Status
+## Status
 
-Draft.
+Draft — replace the prompts below with this repository's real analysis as it grows. `recall doctor`
+flags these as warnings once the repository has real work (a feature, module, or accepted decision).
 
-Track repository-specific risks here as the project evolves.
+## Assets
+
+Describe what this repository must protect: user data, credentials, money, availability, or
+reputation.
+
+## Entry Points
+
+Describe where untrusted input enters: HTTP endpoints, webhooks, file uploads, queues, CLI input, or
+third-party callbacks.
+
+## Trust Boundaries
+
+Describe where trust changes: client to server, service to database, your code to third-party APIs.
+
+## Threats
+
+Describe the concrete threats that apply to this repository, by category:
+
+- Spoofing — how identities are faked or sessions stolen.
+- Tampering — how requests, data, or builds are altered (injection, mass assignment).
+- Repudiation — actions that must remain auditable.
+- Information disclosure — how sensitive data or secrets could leak.
+- Denial of service — how the system can be overwhelmed or abused.
+- Elevation of privilege — how a user could gain access they should not have.
+
+## Mitigations
+
+Describe the control in place or planned for each threat above.
+
+## Open Risks
+
+Describe accepted or unresolved risks and who owns them.

package/examples/generated-ios-swift/docs/60-engineering/AI_AGENT_RULES.md

@@ -4,3 +4,12 @@ AI agents must follow repository memory over model preference.
 
 If a request conflicts with accepted repository memory or engineering standards, stop and report the
 conflict.
+
+## Changing an accepted decision
+
+When work would change something an accepted ADR governs:
+
+1. Find the accepted ADR in `docs/adrs/` that covers it.
+2. If the change contradicts it, stop and confirm with a human before changing the code.
+3. Record the new decision with `recall adr supersede <old> <new-title>` so the old ADR is marked
+   superseded and the reasoning is preserved, instead of silently editing or contradicting it.

package/examples/generated-ios-swift/docs/ai/RECALL_COMMANDS.md

@@ -108,6 +108,17 @@ Options:
 - `--dry-run`: show planned writes without writing files.
 - `--force`: overwrite existing files explicitly.
 
+### `recall adr supersede <old> <new-title>`
+
+Record a changed decision. Marks an accepted ADR as `Accepted — superseded by ADR-####` and creates
+a new accepted ADR that declares what it supersedes, so the reasoning trail stays auditable instead
+of being overwritten. Doctor then warns about any memory still referencing the superseded decision.
+
+Options:
+
+- `--dry-run`: show planned writes without writing files.
+- `--force`: overwrite existing files explicitly.
+
 ### `recall module create <name>`
 
 Create module memory docs under the configured modules directory.
@@ -124,7 +135,8 @@ engineering evidence is present, and whether memory references decisions that ex
 accepted.
 
 Doctor also runs deterministic drift checks: feature or module memory that references a missing ADR
-is an error, and memory that references a not-yet-accepted ADR is a warning.
+is an error, memory that references a not-yet-accepted ADR is a warning, and memory that still
+references a superseded decision is a warning.
 
 Exit codes:
 

package/examples/generated-kotlin-android/AGENTS.md

@@ -13,3 +13,16 @@ Required reading:
 - `docs/60-engineering/ENGINEERING_STANDARDS.md`
 
 Repository rules override model preferences. If instructions conflict, stop and report the conflict.
+
+## Changing an accepted decision
+
+Before changing anything an accepted ADR governs (framework, database, auth, API shape, and
+similar):
+
+1. Check `docs/adrs/` for an accepted ADR that covers it.
+2. If your change contradicts one, stop and confirm with a human first — do not silently change the
+   code and leave the ADR saying the opposite.
+3. Record the change as a new decision with `recall adr supersede <old> <new-title>`. That
+   supersedes the old ADR instead of overwriting history, so the reasoning stays auditable.
+
+Repository memory is only trustworthy if decisions change through this trail, not silently.

package/examples/generated-kotlin-android/docs/20-security/SECURITY_MODEL.md

@@ -1,11 +1,32 @@
 # Security Model
 
-## Current Status
+## Status
 
-Draft.
+Draft — fill the prompted sections below with this repository's real model as it grows.
+`recall doctor` flags these as warnings once the repository has real work (a feature, module, or
+accepted decision).
 
 ## Baseline Rules
 
-- Do not commit secrets.
-- Do not read or copy `.env` files into docs.
+- Never commit secrets or credentials, and never read or copy `.env` files into docs.
+- Validate and authorize untrusted input at every trust boundary.
 - Do not add network, telemetry, cloud, MCP runtime, or AI API behavior without explicit review.
+
+## Authentication And Authorization
+
+Describe how this repository authenticates users or clients and how it authorizes actions, including
+where those checks live.
+
+## Secrets And Configuration
+
+Describe where secrets live, how they are injected, and how configuration is kept out of version
+control.
+
+## Sensitive Data
+
+Describe the sensitive or personal data this repository handles, and how it is protected at rest and
+in transit.
+
+## Dependencies And Supply Chain
+
+Describe how third-party dependencies are vetted, pinned, and updated.

package/examples/generated-kotlin-android/docs/20-security/THREAT_MODEL.md

@@ -1,7 +1,39 @@
 # Threat Model
 
-## Current Status
+## Status
 
-Draft.
+Draft — replace the prompts below with this repository's real analysis as it grows. `recall doctor`
+flags these as warnings once the repository has real work (a feature, module, or accepted decision).
 
-Track repository-specific risks here as the project evolves.
+## Assets
+
+Describe what this repository must protect: user data, credentials, money, availability, or
+reputation.
+
+## Entry Points
+
+Describe where untrusted input enters: HTTP endpoints, webhooks, file uploads, queues, CLI input, or
+third-party callbacks.
+
+## Trust Boundaries
+
+Describe where trust changes: client to server, service to database, your code to third-party APIs.
+
+## Threats
+
+Describe the concrete threats that apply to this repository, by category:
+
+- Spoofing — how identities are faked or sessions stolen.
+- Tampering — how requests, data, or builds are altered (injection, mass assignment).
+- Repudiation — actions that must remain auditable.
+- Information disclosure — how sensitive data or secrets could leak.
+- Denial of service — how the system can be overwhelmed or abused.
+- Elevation of privilege — how a user could gain access they should not have.
+
+## Mitigations
+
+Describe the control in place or planned for each threat above.
+
+## Open Risks
+
+Describe accepted or unresolved risks and who owns them.

package/examples/generated-kotlin-android/docs/60-engineering/AI_AGENT_RULES.md

@@ -4,3 +4,12 @@ AI agents must follow repository memory over model preference.
 
 If a request conflicts with accepted repository memory or engineering standards, stop and report the
 conflict.
+
+## Changing an accepted decision
+
+When work would change something an accepted ADR governs:
+
+1. Find the accepted ADR in `docs/adrs/` that covers it.
+2. If the change contradicts it, stop and confirm with a human before changing the code.
+3. Record the new decision with `recall adr supersede <old> <new-title>` so the old ADR is marked
+   superseded and the reasoning is preserved, instead of silently editing or contradicting it.

package/examples/generated-kotlin-android/docs/ai/RECALL_COMMANDS.md

@@ -108,6 +108,17 @@ Options:
 - `--dry-run`: show planned writes without writing files.
 - `--force`: overwrite existing files explicitly.
 
+### `recall adr supersede <old> <new-title>`
+
+Record a changed decision. Marks an accepted ADR as `Accepted — superseded by ADR-####` and creates
+a new accepted ADR that declares what it supersedes, so the reasoning trail stays auditable instead
+of being overwritten. Doctor then warns about any memory still referencing the superseded decision.
+
+Options:
+
+- `--dry-run`: show planned writes without writing files.
+- `--force`: overwrite existing files explicitly.
+
 ### `recall module create <name>`
 
 Create module memory docs under the configured modules directory.
@@ -124,7 +135,8 @@ engineering evidence is present, and whether memory references decisions that ex
 accepted.
 
 Doctor also runs deterministic drift checks: feature or module memory that references a missing ADR
-is an error, and memory that references a not-yet-accepted ADR is a warning.
+is an error, memory that references a not-yet-accepted ADR is a warning, and memory that still
+references a superseded decision is a warning.
 
 Exit codes:
 

package/examples/generated-laravel-api/AGENTS.md

@@ -13,3 +13,16 @@ Required reading:
 - `docs/60-engineering/ENGINEERING_STANDARDS.md`
 
 Repository rules override model preferences. If instructions conflict, stop and report the conflict.
+
+## Changing an accepted decision
+
+Before changing anything an accepted ADR governs (framework, database, auth, API shape, and
+similar):
+
+1. Check `docs/adrs/` for an accepted ADR that covers it.
+2. If your change contradicts one, stop and confirm with a human first — do not silently change the
+   code and leave the ADR saying the opposite.
+3. Record the change as a new decision with `recall adr supersede <old> <new-title>`. That
+   supersedes the old ADR instead of overwriting history, so the reasoning stays auditable.
+
+Repository memory is only trustworthy if decisions change through this trail, not silently.

package/examples/generated-laravel-api/docs/20-security/SECURITY_MODEL.md

@@ -1,11 +1,32 @@
 # Security Model
 
-## Current Status
+## Status
 
-Draft.
+Draft — fill the prompted sections below with this repository's real model as it grows.
+`recall doctor` flags these as warnings once the repository has real work (a feature, module, or
+accepted decision).
 
 ## Baseline Rules
 
-- Do not commit secrets.
-- Do not read or copy `.env` files into docs.
+- Never commit secrets or credentials, and never read or copy `.env` files into docs.
+- Validate and authorize untrusted input at every trust boundary.
 - Do not add network, telemetry, cloud, MCP runtime, or AI API behavior without explicit review.
+
+## Authentication And Authorization
+
+Describe how this repository authenticates users or clients and how it authorizes actions, including
+where those checks live.
+
+## Secrets And Configuration
+
+Describe where secrets live, how they are injected, and how configuration is kept out of version
+control.
+
+## Sensitive Data
+
+Describe the sensitive or personal data this repository handles, and how it is protected at rest and
+in transit.
+
+## Dependencies And Supply Chain
+
+Describe how third-party dependencies are vetted, pinned, and updated.

package/examples/generated-laravel-api/docs/20-security/THREAT_MODEL.md

@@ -1,7 +1,39 @@
 # Threat Model
 
-## Current Status
+## Status
 
-Draft.
+Draft — replace the prompts below with this repository's real analysis as it grows. `recall doctor`
+flags these as warnings once the repository has real work (a feature, module, or accepted decision).
 
-Track repository-specific risks here as the project evolves.
+## Assets
+
+Describe what this repository must protect: user data, credentials, money, availability, or
+reputation.
+
+## Entry Points
+
+Describe where untrusted input enters: HTTP endpoints, webhooks, file uploads, queues, CLI input, or
+third-party callbacks.
+
+## Trust Boundaries
+
+Describe where trust changes: client to server, service to database, your code to third-party APIs.
+
+## Threats
+
+Describe the concrete threats that apply to this repository, by category:
+
+- Spoofing — how identities are faked or sessions stolen.
+- Tampering — how requests, data, or builds are altered (injection, mass assignment).
+- Repudiation — actions that must remain auditable.
+- Information disclosure — how sensitive data or secrets could leak.
+- Denial of service — how the system can be overwhelmed or abused.
+- Elevation of privilege — how a user could gain access they should not have.
+
+## Mitigations
+
+Describe the control in place or planned for each threat above.
+
+## Open Risks
+
+Describe accepted or unresolved risks and who owns them.