feat: add productivity category schema and examples

[devprashant19]

Resolves #7

Description

This PR introduces the productivity category schema for apps that understand work and task preferences, fulfilling the requirements for the SSoC26 issue.

Following the maintainer's note, this PR is kept intentionally focused. It adds the necessary documentation, input/output examples, and safe context-shaping tests without doing a broad refactor of engine.mjs.

Changes Made

• Added Documentation: Created docs/productivity.md defining context fields, normalized examples, Wiki entry templates, and permission suggestions (productivity.read_preferences, productivity.write_summary).
• Data Privacy Guidelines: Explicitly marked fields requiring extra care. Productivity context should summarize habits (e.g., "time-blocking") rather than exposing raw private task lists or calendar details.
• Added Raw Examples: Added examples/productivity-raw.json demonstrating valid app context alongside an overbroad-data case.
• Minimal Engine Updates: Updated src/engine.mjs to extract productivity attributes (like organization_style and focus_preference) and shape them into schema_packet attributes.
• Added Tests: Added tests in test/schema-packets.test.mjs verifying that:
  • Valid productivity preferences are successfully packed.
  • Overbroad/private data (such as raw_task_name and private_note) is completely filtered out of the resulting schema packet attributes.

Acceptance Criteria Checklist

• Schema separates useful preferences from raw work data
• Raw app input examples exist
• Normalized output examples exist
• Wiki entry examples are human-readable
• Tests cover at least one valid and one overbroad-data case

All tests pass (npm run check).

[keepsloading]

@devprashant19 Thanks, this is a strong first PR.

The scope is good: docs, examples, normalized output, Wiki templates, permissions, and tests without a broad engine refactor.

Two small changes before merge:

1. In examples/productivity-raw.json, please avoid memact.inference.v0 as the schema version. We are trying not to bring back old Inference product language. Use something like memact.app_activity.v0 or memact.schema_input.v0.

2. In docs/productivity.md, please mention that productivity.read_preferences and productivity.write_summary are suggested draft permission names, not finalized Access contract scopes yet.

Other than that, this matches the issue well. The overbroad-data test is especially important.

---

@MohitBareja16 @adikulkarni006 Can you please review the PR once?

[adikulkarni006]

Thanks for tagging me. I'll review the PR and share my feedback soon. 👍

[keepsloading]

Small support note: if you like what Memact is trying to build, please consider following the Memact GitHub org and starring the repo. It helps the project get a little more visibility while SSoC26 contributions come in.

[adikulkarni006]

Reviewed the latest changes. The requested feedback appears to be addressed and the implementation looks good to me. LGTM 👍

[keepsloading]

@devprashant19 thanks for the focused PR. Please make these adjustments before we merge so this lines up with the newer Schema direction:

1. Move the productivity logic out of the generic src/engine.mjs path and into a category-style module, similar to the news-articles shape. Schema should be moving toward app-category schemas, not one growing central engine.
2. Add explicit Wiki proposal examples/templates, not only normalized packet attributes. The category should show how messy productivity app input becomes user-readable memory that a user can accept, edit, reject, or delete.
3. Keep the raw/private examples, but make the boundary clearer: raw task names, private notes, calendar details, and doc titles should be treated as overbroad source material and must not become app-readable context by default.
4. Please avoid final permission names like productivity.read_preferences / productivity.write_summary unless they are framed as suggested category permissions. Access/Contracts still own the final shared permission contract.

The philosophy to preserve is: Activity is not Identity. Productivity activity can suggest context, but it should not silently become identity or accepted memory without the Wiki/user-control step.

[devprashant19]

@keepsloading please review the changes you told me to make