ecode: Enable line-wrap by default on new installations.

Added Code of Conduct and Contributing documents.
Added templates for bug reports and feature requests.

CONTRIBUTING.md

@@ -0,0 +1,119 @@
+# Contributing and Community Support
+
+Contributions and pull requests are welcome. Before posting, search existing
+Issues and Discussions to avoid duplicates and choose the appropriate channel
+below.
+
+Maintainer time is limited. Reports that do not follow these guidelines may be
+closed or moved without investigation.
+
+## Where to post
+
+### Issues: actionable bugs and defined feature requests
+
+Use the repository's GitHub Issues for:
+
+* **Actionable bugs**: observable behavior where the affected project or
+  component does not behave as documented or intended, produces an error or
+  crash, or behaves inconsistently under equivalent conditions. A difference in
+  preference or desired behavior is not by itself a bug.
+* **Well-defined feature requests**: a specific problem, use case, and proposed
+  outcome whose scope can be evaluated and acted upon.
+
+A report may still be valid when the cause is uncertain. What matters is that
+the unexpected behavior is concrete and reproducible enough to investigate.
+
+### Discussions: questions, support, and ideas
+
+Use the repository's GitHub Discussions for:
+
+* Questions about using or building the project.
+* Troubleshooting where a project defect has not been established.
+* Early-stage, exploratory, or broad ideas.
+* Proposals that need feedback before their scope or desired behavior is clear.
+
+Starting even a defined feature request in the **Ideas** discussion category is
+encouraged, especially when the change is large, affects existing behavior, or
+has significant design tradeoffs. Once the proposal is concrete and a
+maintainer agrees it is suitable, it may be tracked as an Issue.
+
+Issues are not a support forum. Repeatedly opening questions as Issues after
+being redirected may be treated as disruptive behavior under the
+[Code of Conduct](CODE_OF_CONDUCT.md).
+
+## Bug report requirements
+
+A bug report must contain enough information for another person to understand
+and investigate the problem. Include, as applicable:
+
+* A concise description of the observed and expected behavior.
+* Exact reproduction steps and the smallest reproducible example.
+* Project version, commit, or build date.
+* Operating system, architecture, compiler, graphics backend, and other relevant
+  environment details.
+* Complete logs, error messages, crash stack traces, or sanitizer reports as
+  text when available.
+* Screenshots or a short recording for visual or interaction problems.
+* Whether the problem is reproducible and whether it previously worked.
+
+Remove passwords, tokens, private files, and other sensitive information before
+posting. Do not replace essential evidence with vague summaries such as "it
+doesn't work" or "it crashes sometimes."
+
+Maintainers may request additional information or ask the reporter to test a
+change. If requested information cannot be provided, explain why and share the
+best alternative evidence available. Reports may be closed when there is not
+enough information to investigate or when the reporter does not respond or
+provide requested information within a reasonable time, or does not cooperate
+in a meaningful way. They can be reconsidered when the missing information
+becomes available.
+
+## Feature request requirements
+
+A feature request should explain the concrete problem or use case, who benefits,
+the desired behavior, relevant constraints and alternatives, and which project
+or component it affects.
+
+A request is not a commitment that the feature will be implemented. Maintainers
+may decline requests that do not fit the project's scope, priorities, design,
+or maintenance capacity.
+
+## Pull requests
+
+Pull requests for bug fixes, features, documentation, tests, and other project
+improvements are welcome. Keep each pull request focused, explain the problem
+and the chosen solution, follow the existing code style, and include relevant
+tests or clear verification steps when practical. For large or potentially
+breaking changes, start a Discussion before investing substantial work.
+
+Opening a pull request does not guarantee acceptance. Changes must fit the
+project's scope and technical direction, and may require revision after review.
+
+## Automated and AI-assisted submissions
+
+Do not use automated systems to create Issues or Discussions without meaningful
+human review. Bulk-generated, unattended, or unverified submissions are not
+welcome and may be treated as spam. If AI tools help prepare a post, the person
+submitting it must verify its accuracy, ensure it follows these guidelines, and
+take responsibility for its content and any follow-up.
+
+Automated or AI-assisted pull requests are welcome when they provide clear
+value and are reviewed by the submitter. They are evaluated by the same quality,
+verification, and responsiveness standards as any other contribution.
+
+## Posting responsibly
+
+Open one report per independent problem. Do not split one problem across
+several Issues, repost closed content, or open a rapid batch of reports before
+maintainers can triage them. If you have found many possible problems, start a
+Discussion or prioritize the clearest and best-supported reports first.
+
+Repeated vague, duplicative, unsupported, or noncompliant reports may be closed,
+and continued behavior may lead to interaction limits or a block. These
+standards apply to everyone; contribution history may help maintainers assess
+good-faith participation but does not exempt anyone from the rules.
+
+Do not use alternate accounts to evade moderation or posting controls. Account
+evasion may result in an immediate block without an additional warning.
+
+All participation is subject to the [Code of Conduct](CODE_OF_CONDUCT.md).