# Main/dev branch differences

`main` maps to kiduna.club and `dev` maps to kiduna.dev. This inventory intentionally includes both so designs do not omit capabilities already moving through development.

## kinship-shared

`dev` is 99 changed files from the reviewed `main` snapshot. Product-significant additions/changes include:

- DUNA genesis and registration endpoints plus a DUNA start form.
- DUNA registration data model and role helpers.
- Proposal redemption endpoint, redemption model/history, and a wallet redemption route.
- Expanded proposal lifecycle actions and redemption card.
- Significant updates to chat, agent detail/list management, approvals, platform switching, team/market creation, wallet, and proposal pages.
- Updated authorization/permissions across market, objectives, operators, proposals, treasury, and launch actions.
- Additional redemption history and current-user redemption endpoint.
- Revised predefined avatars and role setup.

Design implication: DUNA identity/registration and proposal redemption must be present in the new IA even if the first production release still gates them.

## kinship-agent-be

`dev` is 56 changed files and 7,197 insertions from `main`. Product-significant changes include:

- Agent knowledge moves from a Pinecone service to PostgreSQL `pgvector` KB chunks.
- Dedicated raw-text ingestion endpoint.
- Knowledge/graph lifecycle listeners and event ingestion (single and batch).
- More capable graph retrieval, guarded Cypher, and graph lookup tools.
- Token and cost tracking with monthly usage endpoint/model.
- Approval retry action and much deeper approval execution support.
- Expanded deep-agent event mapping/orchestration and chat streaming.
- Authentication enforcement changes across agent services.
- Expanded tools API and agent configuration changes.

Design implication: vector backend status, graph events/sync, usage/cost, approval retry, and richer action events are dev capabilities with insufficient v1 UI.

## kinship-knowledge

The reviewed `main` and `dev` application trees are nearly identical; the diff is limited to one removed initial migration and two small schema/game-plan edits. The capability set should be treated as shared across both for UI planning.

## kinship-assets

The reviewed `main` and `dev` trees are effectively identical. Asset, scene, platform, project, game, score, storage, metadata, and asset-knowledge capabilities can be treated as common to both environments.

## Branch-aware design recommendations

- Add a design annotation for production, dev, gated, admin-only, legacy, and retired.
- Do not remove a `dev` capability from the design merely because the v1 production screen is absent.
- Avoid designing separate incompatible flows for main/dev; use feature flags and state gating within one information architecture.
- Re-run the generated inventories when branches merge. Diff `resources/api-endpoints.csv`, `data-models.csv`, and `review-v1-screens.csv` to catch new capabilities.

