Add productivity category schema

[keepsloading]

Goal

Add a productivity category schema for apps that understand work and task preferences.

This should help Memact turn productivity app signals into user-readable Wiki entries that users can approve, edit, reject, or delete.

Context examples

Productivity apps may know things like:

• preferred task organization style
• recurring project areas
• calendar or planning habits
• preferred notification style
• document formatting preferences
• meeting preparation patterns
• focus-time preferences
• collaboration preferences

Work to do

• Define useful context fields for the productivity category
• Add example raw app context dumps
• Add normalized context examples
• Add user-facing Wiki entry templates
• Mark fields that require extra care clearly
• Suggest category-level permissions apps should request
• Add tests for safe context shaping

Important product rule

Productivity context should summarize preferences, not expose full task lists, private documents, or full calendars by default.

Acceptance criteria

• 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

[keepsloading]

Maintainer note for SSoC26 contributors:

Please comment before starting so work does not get duplicated. Keep the first PR small and focused.

For category schemas, apps should propose context; users control what becomes accepted memory. Prefer user-readable summaries over raw personal data, avoid sensitive trait inference, and do not write fake certainty.

Before opening a PR, read MEMACT.md and make sure your schema includes examples, Wiki entry outputs, permission suggestions, and at least basic tests.

[devprashant19]

Hi! I'd like to work on this issue. Before I start, I wanted to propose an implementation approach to make sure it aligns with your expectations:

1. Documentation (Category Schema Definition)

I'll create the documentation covering the required points (useful fields, examples, Wiki templates, permissions, and care instructions).
Question: Where should this documentation live? Should I create a new schemas/productivity/README.md or a single schemas/productivity.md file in the root or a docs/ folder?

2. Code Updates (src/engine.mjs)

I'll update the engine to shape the productivity context, similar to how it handles reading_preferences:

• Add a buildProductivityAttributes(records) function to extract preferences from raw data.
• Update createSchemaPacket to call buildProductivityAttributes when schemaType === "productivity".
• Ensure inferSubSchema correctly identifies productivity sub-schemas (like task organization or focus patterns).

3. Tests

• Add examples/productivity-raw.json with example raw dumps of productivity data.
• Add tests to test/schema-packets.test.mjs (or a new file) to ensure context shaping is safe. This will include one valid case and one overbroad-data case.
  Question: For the "overbroad-data case", should the engine.mjs actively strip out recognized task lists/names if they are passed in the raw context, or is this primarily a documentation rule for app developers?

Let me know if this sounds good or if you'd like me to adjust the plan!

[keepsloading]

Assigned to you, @devprashant19.

Your plan looks good. For docs, use docs/productivity.md.

For the first PR, keep it focused:

• define the productivity category schema
• add raw input examples
• add normalized output examples
• add Wiki entry examples
• add permission suggestions
• add basic tests

Avoid a broad engine.mjs refactor in the first PR unless it is strictly needed. For the overbroad-data case, treat it as both: document that apps should not send raw task names by default, and add tests/examples showing that normalized output should summarize patterns instead of preserving private task details.