Developer Access Rules

This page defines the access boundary for official ECHO development. It is not a general support channel and it is not a public issue template.

Only people approved through the ECHO Developer Program and granted collaboration access may participate in official ECHO development, submit mergeable implementation work, access developer repositories, or use internal development materials. Regular users may report issues, suggest improvements, send documentation corrections, or maintain their own forks, but that is not the same as official ECHO development access.

Developer Status

In this context, Developer means an ECHO Developer confirmed by the maintainer. It does not mean:

• You only have ECHO Pro.
• You only joined a chat or sent feedback.
• You only can access the public GitHub repository.
• You only forked the project or can run it locally.
• You only used AI to generate code or a PR.

Developer status means your skills, contribution direction, risk awareness, and maintenance commitment have been reviewed. See the ECHO Developer Program for the application path.

Read Before Development

Before contributing development work, read at least:

• ECHO Next Rules
• ECHO Page Developer Guide
• How To Ask AI About ECHO
• External reference: Stop-Ask-Questions-The-Stupid-Ways

The external reference is intentionally blunt. It is linked here because development collaboration is not guesswork. When you report a bug, propose a feature, or ask about implementation, provide the goal, context, reproduction steps, logs, what you already tried, risks, and expected result.

Allowed Work

Developers may contribute within their granted scope:

• Fix confirmed issues.
• Improve documentation, examples, plugins, and tooling.
• Improve the desktop app, website, build, release, update feed, or diagnostics flow.
• Make small, explainable, reversible experience improvements.
• Submit verifiable implementations for audio, library, metadata, remote-source, and plugin-system work.

Before submitting, be able to explain three things: why the change is needed, what changed, and how you proved it did not break existing behavior.

Disallowed Work

Developer access does not allow crossing these boundaries:

• Do not bypass authorization, crack the app, fake activation state, or weaken ECHO Pro validation.
• Do not share internal repositories, test builds, private keys, authorization data, unreleased content, or unconfirmed plans.
• Do not wrap ECHO interfaces as hotlinking, download, infringing-source, membership-bypass, region-bypass, or platform-rule-evasion tools.
• Do not change download entry points, auto update, release scripts, authorization services, or public navigation without maintainer confirmation.
• Do not mix large refactors, style cleanup, or drive-by renames into a small fix.

If a change may affect user libraries, playback, downloads, auto updates, authorization state, database migrations, or remote services, explain the risk before implementation.

Communication Format

Do not send only “this is broken”, “can this be done”, or “AI says this works”. Provide at least:

Goal:
Behavior or request:
Impact:
Related page / file / log:
What I already confirmed or tried:
Possible risk:
Suggested validation:

For bugs, include reproduction steps, version, system, logs, and screenshots. For features, describe the real use case first, not only “add a button”.

Contribution Flow

1. Confirm you have Developer access and the required repository access.
2. Check the working tree before starting so you do not overwrite another developer or process.
3. Keep the scope small and touch only the files required for the goal.
4. Explain high-risk points before implementing.
5. Run the smallest useful validation, not long low-value tests for formality.
6. In the PR or delivery note, document the change, validation, risk, and rollback path.

Documentation changes usually only need frontmatter, link, and page-path checks. Download, update-feed, authorization, build-script, and desktop behavior changes require targeted validation for the affected path.

Direct Rejection Cases

The maintainer may reject a change even if the code runs when:

• The author is not a Developer but submits official implementation work.
• The submission has no goal, context, or validation and only drops code.
• The change attempts to bypass authorization, security boundaries, or platform rules.
• The scope is much larger than the problem.
• The change affects release, download, update, or authorization behavior without a risk note.
• The change introduces a hard-to-maintain framework, dependency, service, or abstraction.

ECHO welcomes development that is maintainable, risk-aware, and provable. Development access is not a trophy. It is a commitment to users, the project, and long-term maintenance cost.