Propose a module

A strong module proposal starts with a shared problem, not a folder structure. Early discussion helps contributors agree on the feature boundary, avoid duplicate work, and identify contracts that belong in portal core.

Before you propose

Search the Customer Portal issues and existing modules. If the capability is specific to one deployment, it may still be valuable as an external layer without becoming part of the default portal.

Open the reusable layer proposal form. GitHub begins the title with Module proposal: and asks for the boundary evidence below.

Proposal outline

## Problem
Who needs this capability, and what cannot they do today?

## Reusable boundary
What belongs in this layer? What is explicitly outside it?

## Audiences and permissions
Which users participate? List proposed actions for owner, admin, and member.

## Product surface
List routes, navigation, module menus, dashboard widgets, and major states.

## Data ownership
Describe tenant-owned records, the PostgreSQL schema, retention, and cross-schema references.

## Integrations
List external services, secrets, webhooks, files, or background work.

## Security and privacy
Describe sensitive data, organization isolation, destructive actions, and audit needs.

## Delivery plan
Suggest reviewable milestones, migrations, tests, translations, and documentation.

What maintainers will evaluate

Discussion should establish whether the capability is reusable, whether it needs a new layer or an existing one, and whether any proposed core change is genuinely cross-cutting. Maintainers will also look for a clear authorization vocabulary, tenant boundaries, migration safety, and a first milestone small enough to review.

Agreement on a proposal is not a promise to merge every implementation detail. Keep design choices visible in the issue and link follow-up pull requests so later contributors can understand the reasoning.

Once the boundary is clear, follow create a feature layer and testing contributions.