docs(profile): reconcile the third contact address introduced in profile/README.md

[kyle-sexton]

Summary

profile/README.md gives the org contact address as info@melodicsoftware.com. That is a third address, alongside two documented in the policy files:

Address	Documented in	Purpose
security@melodicsoftware.com	SECURITY.md	vulnerability reports where private reporting is unavailable
support@melodicsoftware.com	SUPPORT.md	"anything else"
info@melodicsoftware.com	profile/README.md only	undocumented

profile/README.md is the org's public profile page — for many visitors it is the first and only thing they read — so the address it gives is the one people will actually use.

The question

Is info@ a real, monitored inbox with a purpose distinct from support@? If so, the policy files should say what it is for. If not, profile/README.md should point at support@ so contact routing has one answer rather than three.

Scope

Trivial to change; needs a human who knows which inboxes are actually monitored.

Provenance

Surfaced as a deferred item by an automated repository-wide documentation-staleness sweep (/code-tidying:batch-simplify repo docs). profile/README.md is excluded from automated edits, so this is filed rather than fixed.

[kyle-sexton]

[kyle-sexton]

This was generated by AI during triage.

Verification: confirmed. profile/README.md's Contact section reads <info@melodicsoftware.com>. SECURITY.md documents only security@melodicsoftware.com (vulnerability reports when private reporting is unavailable) and SUPPORT.md documents only support@melodicsoftware.com ("anything else"). Neither policy file mentions info@ anywhere — the report's claim holds.

Agent Brief

Type: Task
Summary: Reconcile the undocumented info@melodicsoftware.com address in profile/README.md's Contact section against the two addresses the org's policy files actually document.

Current behavior:
profile/README.md — the org's public profile page, likely the first thing many visitors read — tells visitors to email info@melodicsoftware.com. That address appears nowhere else: SECURITY.md and SUPPORT.md establish security@melodicsoftware.com and support@melodicsoftware.com as the org's two documented contact addresses, with support@ covering "anything else." Contact routing currently has three candidate addresses and no single source of truth.

Desired behavior:
Exactly one of two forks, depending on a fact only a maintainer can supply — which inboxes are actually monitored:

1. info@ is a real, actively-monitored inbox with a purpose distinct from support@ → that purpose gets documented (in SUPPORT.md or wherever fits), and profile/README.md keeps pointing at info@.
2. info@ is not a distinct monitored inbox → profile/README.md's Contact section is changed to point at support@melodicsoftware.com instead, so contact routing resolves to one documented answer.

Key interfaces: None — documentation-only, no code interfaces involved.

Acceptance criteria:

• The contact-routing decision is recorded: either info@'s distinct purpose is documented in the policy files, or profile/README.md's Contact section references support@melodicsoftware.com.
• No remaining contradiction between profile/README.md and SECURITY.md/SUPPORT.md over which address to use for general contact.

Out of scope:

• Changing security@'s or support@'s existing documented purposes.
• Adding any new contact channel beyond resolving the third address.

Why this needs a human

Both forks are equally plausible from the repo alone, and they produce different work products (a purpose statement added to a policy file, vs. an edit to profile/README.md) rather than one shared default — this isn't a single reversible edit with a safe fallback. Resolving it requires knowing which inboxes actually exist and are monitored, a fact outside repo content. Please answer:

1. Is info@melodicsoftware.com a real, actively-monitored inbox, distinct in purpose from support@melodicsoftware.com? If yes, what is that purpose (so it can be documented)?
2. If no, confirm profile/README.md's Contact section should be changed to support@melodicsoftware.com.

[kyle-sexton]

This was generated by AI in a documentation lane (dotgithub).

Resolved. Merged as ac80c0f7fb3f285208688b0fdeba1acd513536a2 (PR #102, squashed to main 2026-08-27T10:11:35Z). Confirmed on main: profile/README.md's Contact section now reads <support@melodicsoftware.com>.

What was decided, and why it matches neither fork verbatim. The issue's premise contained a factual error that changed the answer. Its table lists info@melodicsoftware.com as documented in "profile/README.md only" with an "undocumented" purpose. It is not undocumented: CODE_OF_CONDUCT.md line 39 uses it as the Contributor Covenant enforcement contact, i.e. the address for reporting abusive or harassing behavior. (The triage comment's own sentence, "Neither policy file mentions info@ anywhere," was scoped to SECURITY.md and SUPPORT.md and was true as written; its conclusion that "the report's claim holds" is what carried the error forward, because the search covered two policy files rather than all five.)

So fork 1 ("info@ is distinct and monitored, document its purpose, keep the profile pointing at it") was already half-satisfied: the purpose is documented. But that documented purpose is conduct reports, which is not what a public profile page's Contact section means, so keeping the pointer would route general enquiries into the conduct-report inbox. Fork 2's edit was right; its reasoning ("info@ is not a distinct monitored inbox") was not. The resolution takes fork 2's edit on fork 1's facts.

Each address now has exactly one documented purpose: security@ for vulnerabilities (SECURITY.md), support@ for "anything else" (SUPPORT.md), info@ for conduct reports (CODE_OF_CONDUCT.md). That satisfies the second acceptance criterion — no contradiction remains between profile/README.md and the policy files. CODE_OF_CONDUCT.md was not touched: it is verbatim Contributor Covenant v2.1 and its use of info@ is correct.

No inbox-monitoring fact was needed in the end, which is why this did not have to wait on the escalated question.

How it was verified. A fresh-context verifier (opus, no authoring context) judged the final state, not the diff: checked out the branch, confirmed CODE_OF_CONDUCT.md:39 on main, confirmed CODE_OF_CONDUCT.md was unmodified and the GFM autolink form preserved, ran markdownlint-cli2@0.23.2 against the repo's own config (0 issues), read all 14 CI checks (all pass), and walked both acceptance criteria to met. Scope confirmed at one file, one line. Verdict: PASS.

One thing left for a maintainer: this issue's body still asserts info@ is undocumented. Anyone reading it later inherits the error. Worth an edit to the body, or at least a note, since the issue text outlives this comment in search.