From 887e08304a205c78d06c78ec98a3ba10c9380966 Mon Sep 17 00:00:00 2001 From: toki Date: Fri, 29 May 2026 05:31:58 +0900 Subject: [PATCH] =?UTF-8?q?docs(readme):=20=EC=A0=9C=ED=92=88=20=EA=B2=BD?= =?UTF-8?q?=EA=B3=84=EB=A5=BC=20=EB=AA=85=EC=8B=9C=ED=95=9C=EB=8B=A4?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- README.md | 27 +++++++++++++++++++++++++-- 1 file changed, 25 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index 34b90864..9afbf3f9 100644 --- a/README.md +++ b/README.md @@ -3,18 +3,40 @@ `nexo` is a Flutter messaging and notification package workspace. The main deliverable is `packages/messaging_flutter`: a reusable package that lets many Flutter apps integrate messaging and push-notification behavior without each app -reimplementing the same native runtime. +reimplementing the same native runtime. It is intended to be a shared messaging +layer for sibling products such as IOP, NomadCode, and ALT when they need +Mattermost-compatible messaging behavior without inheriting the full Mattermost +product shape. Mattermost upstream repositories are kept as references around the package: `apps/mattermost` for the original Mattermost app, `services/core` for the server, and `services/push-proxy` for the push server. This repository does not -contain a dedicated nexo product app. +contain a dedicated nexo product app, and it does not aim to become a broad +Mattermost fork. Mattermost snapshots are kept as upstream baselines and +validation references so Nexo-specific customization can stay in the plugin, +compose/runtime wrappers, docs, or small explicit patches. ## Name `nexo` comes from `nexus`: a connection point where apps, messages, notifications, and service infrastructure meet. +## Product Boundary + +- `packages/messaging_flutter/` is the Nexo-owned product surface. It should + hold reusable messaging, push notification, native bridge, and notification + tap/intake behavior that multiple Flutter apps can consume. +- Consuming apps such as IOP, NomadCode, and ALT own their product UI, workflow + semantics, and app-specific business logic. They should depend on Nexo for the + common messaging runtime instead of copying native push/messaging integration. +- Mattermost upstream code is a comparison and validation baseline, not the main + customization surface. Keep `apps/mattermost`, `services/core`, and + `services/push-proxy` close to their recorded upstream snapshots unless an + explicit upstream refresh or small targeted patch is being reviewed. +- When Mattermost product behavior does not fit a consuming app, prefer adding a + narrow Nexo plugin contract, wrapper, configuration point, or documented + integration path over changing the upstream snapshots directly. + ## Current Status - `packages/messaging_flutter/` is the main product surface: an Android-first Flutter messaging and push-notification plugin package. @@ -85,6 +107,7 @@ any skipped checks in work reports. - Follow path-specific domain rules under `agent-ops/rules/project/domain/*/rules.md`. - For standard tasks such as README, plan, review, or commit/push, route through `agent-ops/skills/common/router.md`. - Treat `packages/messaging_flutter/` as the primary product. App-specific product UI and business logic belong in consuming apps outside this repository. +- Treat IOP, NomadCode, and ALT as expected sibling consumers of the Nexo messaging layer; keep shared behavior in the plugin and app-specific behavior in those projects. - Treat `apps/flutter-test/` only as the plugin integration test host; do not grow it into a product app or duplicate plugin internals there. - Treat `apps/mattermost`, `services/core`, and `services/push-proxy` as original Mattermost repository clones, not as nexo-owned app or server products. - Do not change `services/core/UPSTREAM.md` baseline information without an explicit upstream decision.