Define Wiki entry lifecycle states

[keepsloading]

Goal

Define the user-facing lifecycle states for Memact Wiki entries.

The Wiki is where users see, edit, approve, reject, delete, and control context proposed by apps or written by users themselves.

States to define

Suggested states:

• proposed
• accepted
• edited
• rejected
• deleted
• expired
• hidden

Work to do

• Define each lifecycle state in plain language
• Explain what actions are available in each state
• Add example user-facing copy for each state
• Describe how app-proposed entries differ from user-created entries
• Describe when an entry should become Memory
• Add edge cases and examples

Important product rule

Apps can suggest context, but users control what survives.

Acceptance criteria

• Lifecycle states are easy to understand
• User actions are clear for each state
• App-proposed and user-created entries are treated differently
• Copy examples are simple and human-readable

---

SSoC26 Contributor Notice:

Since this repository (Memact/Notebook) is outside the main Context repository, and the registered project for tracking contributions is specifically Context (Memact/Context), please make sure to create a dummy PR in the Context repository linking to your actual PR or commits in this repository. This is required for your contribution to be correctly tracked and counted.

If you have already created a dummy PR in Memact/Context linking to your work here, please ignore this message!

[mahakagarwal7]

Hi @keepsloading
I want to work on this issue as a part of SSOC26.

Please assign me this issue.

[keepsloading]

@mahakagarwal7 Assigned. This is your second active Memact issue under the current contributor cap.

Please keep the contribution focused on defining lifecycle states, user actions available in each state, example user-facing copy, the distinction between app-proposed and user-created entries, when accepted entries become Memory, and a few clear edge cases. Keep the language simple and user-facing.

[keepsloading]

Alignment Update: Under the V1 architecture, we use the terms 'Notebook' and 'Suggestions' instead of 'Wiki' and 'proposals'. Please update the lifecycle state definitions and documentation to refer to 'Notebook entries' and 'Suggestions' instead of 'Wiki entries' and 'proposals'.

[GonuDvc]

Hit this same issue — the root cause was the missing null check before deserialization. Wrapping in a try/catch fixed it on our end.

[keepsloading]

Attention @mahakagarwal7:

Maintainer Notice regarding SSoC26 contributions:

Since this repository (Memact/Notebook) is outside the main Context repository, and the registered project for tracking contributions is specifically Context (Memact/Context), please make sure to create a dummy PR in the Context repository linking to your actual PR or commits in this repository. This is required for your contribution to be correctly tracked and counted.

If you have already created a dummy PR in Memact/Context linking to your work here, please ignore this message!

[keepsloading]

Hi @mahakagarwal7! As part of Memact's architectural updates, we are phasing out "Wiki" terminology in favor of "Claims" and "Context Suggestions".

For this issue, please align the state machine design to cover the lifecycle of a suggestion / claim (e.g., Suggested, Approved, Rejected, Hidden, Junk, Expired). It is also critical to ensure that all state transitions are fully reversible by the user at any time (e.g. allowing them to hide, edit, or restore previously unapproved or approved claims). Refer to the active design discussion here: Memact/Context#70