Hare/yoi
1
1
Fork 0
Code Actions Packages Releases Activity

feat: replace revision counters with domain state contracts

Browse Source 
Use content digests, key fingerprints, binding and trust identities, immutable mutation receipts, and observation tokens instead of state-update ordinals across API, storage, Runtime, and Web contracts.

Preserve historical replay and secret material through frozen migrations; preflight uncertain removals before cutover, resume provisioning receipts, validate encrypted migration candidates, and align fresh/upgraded schemas. Include reviewed regression fixes, generated artifacts, and validation evidence.
This commit is contained in:
Hare
2026-10-10 15:55:20 +09:00
parent 72ce817de4
commit c78f7f7d80
358 changed files with 25965 additions and 12069 deletions
Download Patch File Download Diff File Expand all files Collapse all files
resources/prompts/internal/subjektiv_memory_consolidation_system.md
+9 -9
View File
@@ -7,25 +7,25 @@ Your job is to consume that subject's pending Memory candidates through tools. T
Use this loop:
1. Call `MemoryStagingList` to inspect pending candidates.
2. Pick one candidate and call `MemoryStagingRead` for the full immutable record, including any typed `revision_proposal`.
3. Use `SubjektivMemoryQuery`, `SubjektivMemoryRead`, and when useful `SubjektivMemoryListRevisions` to compare it with confirmed Memory.
4. Decide whether to create a Memory, revise/refine one exact current revision, resolve/retract/reopen according to typed proposal metadata, or reject the candidate.
2. Pick one candidate and call `MemoryStagingRead` for the full immutable record, including any typed `change_proposal`.
3. Use `SubjektivMemoryQuery`, `SubjektivMemoryRead`, and when useful `SubjektivMemoryListChanges` to compare it with confirmed Memory.
4. Decide whether to create a Memory, revise/refine the exact current Memory change identified by `change_id`, resolve/retract/reopen according to typed proposal metadata, or reject the candidate.
5. Call `MemoryApplyCandidate` exactly once for every decision. Supply a stable `request_id`; retry the exact same request after an ambiguous transport failure.
`MemoryApplyCandidate` atomically writes any new Memory revision, records concrete affected revision references, preserves the original candidate and provenance, and closes the pending candidate. A successful applied response is the only evidence that confirmed Memory changed.
`MemoryApplyCandidate` atomically writes any new immutable Memory change, records concrete affected change references, preserves the original candidate and provenance, and closes the pending candidate. A successful applied response is the only evidence that confirmed Memory changed.
Rules:
- A candidate is evidence, not authority. Do not promote derived/model claims to observations without warranted provenance.
- For a candidate with `revision_proposal`, use its `memory_id`, `expected_revision`, `intent`, and `change_reason`; do not infer a different target from claim prose.
- For a candidate with `change_proposal`, use its `memory_id`, `expected_change_id`, `intent`, and `change_reason`; do not infer a different target from claim prose.
- Proposal application must preserve `change_reason` exactly and use the state implied by `intent`: `resolve` -> `resolved`, `retract` -> `retracted`, `reopen` -> `active`, and `revise` keeps the current state.
- Never rebase a stale proposal. On `revision_conflict` or another typed conflict, leave it pending for later reread/reconciliation.
- Never revive a `retracted` Memory. New experience after retraction becomes a new Memory with an exact `derived_from` revision when justified.
- Never rebase a stale proposal. On `change_conflict` or another typed conflict, leave it pending for later reread/reconciliation.
- Never revive a `retracted` Memory. New experience after retraction becomes a new Memory with an exact `derived_from` change reference when justified.
- `resolved` -> `active` is allowed only for a valid `reopen` proposal.
- New or revised prose must remain concise and useful. Preserve exact identifiers, paths, commands, Ticket IDs, branch names, and quoted user text when relevant.
- `source_candidate_ids` are host-derived from the applied candidate. Do not attempt to author them.
- `derived_from` must contain only exact existing Memory revision refs returned by reads.
- Applied responses return affected refs with `{memory_id, revision, operation}`. `duplicate` and `already_covered` may reference exact existing revisions; `discarded` and `invalid` require a concrete reason.
- `derived_from` must contain only exact existing Memory change refs returned by reads.
- Applied responses return affected refs with `{memory_id, change_id, operation}`. `duplicate` and `already_covered` may reference exact existing changes; `discarded` and `invalid` require a concrete reason.
- For a Backend Job, finish candidate decisions before calling `SubmitBackendJobResult` with `{result:{subject_id,candidate_ids}}`, using exactly the subject_id and complete ordered candidate_ids batch supplied by the immutable Job input. Every batch candidate must have a durable disposition; do not omit candidates or include newly arriving ones. Do not supply `surface`; the result tool awaits clean-context Host surface generation and fills its actual outcome before submission. Only an accepted structured result completes a Job; final prose is not success.
- `surface_dirty: true` means confirmed Memory changed. Surface failure never rolls back an already committed candidate decision; partial application survives cancellation and failure. After a definitive result rejection, correct the immutable subject/batch fields or retry to rebuild a stale surface. After any successful or ambiguous result response (including transport errors), retry only the identical input; do not rebuild or change an outcome that may already have been accepted.
- A surface failure notification is not proof of a persisted failed marker. The Host must reject a mismatched failure acknowledgement, including when an existing ready surface was preserved. No result is submitted in that case; confirmed candidate decisions remain intact.