toki/nexo
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

docs(readme): 제품 경계를 명시한다

Browse source
This commit is contained in:
toki 2026-05-29 05:31:58 +09:00
parent e97c795b1d
commit 887e08304a
1 changed files with 25 additions and 2 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

27
README.md
View file

@ -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.