Codex-oriented adapter/fork for ECC

[YBsmorom]

Hi Affaan and ECC maintainers,

I made a Codex-oriented adapter/fork of ECC here:
https://github.com/YBsmorom/ecc-codex-plugin

After your guidance, I updated the repo positioning to state explicitly that affaan-m/ECC remains the canonical upstream. This repo is meant as a Codex-oriented adapter/fork for users who want a repository-URL Codex install path today. It should not be presented as the canonical ECC package or as an upstream ECC release unless it is merged or linked from upstream.

It preserves the MIT license and attribution, links back to affaan-m/ECC, and focuses on Codex packaging: .codex-plugin/plugin.json, a Codex-facing orchestration router, generated skill/routing indexes, MCP duplicate-selection policy, bilingual install docs, and a Codex-safe hook graph that removes unsupported async declarations while keeping bounded hook behavior where possible.

I also agree that generally useful routing, MCP duplicate-selection, or Codex-safe hook changes should come back as focused PRs against ECC rather than living only in the fork.

[affaan-m]

Thanks for sharing this. This is useful context for Codex users, and the attribution/license boundary looks right from your summary.

Current ECC main is also moving toward first-class Codex packaging through the in-repo .codex-plugin/ surface and the 2.0 preview docs, so I would not present the fork as the canonical ECC package. The clean positioning is:

• affaan-m/ECC remains the canonical upstream.
• Your repo can be a Codex-oriented adapter/fork for users who want that install path today.
• Any generally useful routing, MCP duplicate-selection, or Codex-safe hook changes should come back as focused PRs against ECC rather than living only in the fork.

The main things to keep strict are attribution, MIT license preservation, clear fork language, and no claim that the fork is the official ECC release unless it has been merged or linked from upstream.

[YBsmorom]

Hi Affaan, Thanks again for the clear guidance. That makes sense. I’ve updated the repo wording to make the positioning stricter: affaan-m/ECC is now clearly described as the canonical upstream, and my repo is framed as a Codex-oriented adapter/fork for people who want a repo-URL Codex install path today. I also removed any wording that could make it sound like this is the canonical ECC package or an upstream ECC release, unless it is merged or linked from upstream. The README, NOTICE, plugin manifest, install docs, and the upstream discussion text have all been adjusted. I agree with your point about upstreaming generally useful pieces. If the routing, MCP duplicate-selection, or Codex-safe hook changes look useful beyond this adapter, I’ll split them into focused PRs against ECC instead of leaving them only in the fork. Appreciate you taking the time to review the boundary. Best, YB

…

________________________________ 发件人: Affaan Mustafa ***@***.***> 发送时间: 2026年5月26日 2:16 收件人: affaan-m/ECC ***@***.***> 抄送: 页白 ***@***.***>; Author ***@***.***> 主题: Re: [affaan-m/ECC] Codex adapter fork for ECC (Discussion #2051) Thanks for sharing this. This is useful context for Codex users, and the attribution/license boundary looks right from your summary. Current ECC main is also moving toward first-class Codex packaging through the in-repo .codex-plugin/ surface and the 2.0 preview docs, so I would not present the fork as the canonical ECC package. The clean positioning is: * affaan-m/ECC remains the canonical upstream. * Your repo can be a Codex-oriented adapter/fork for users who want that install path today. * Any generally useful routing, MCP duplicate-selection, or Codex-safe hook changes should come back as focused PRs against ECC rather than living only in the fork. The main things to keep strict are attribution, MIT license preservation, clear fork language, and no claim that the fork is the official ECC release unless it has been merged or linked from upstream. ― Reply to this email directly, view it on GitHub<#2051?email_source=notifications&email_token=BE63TGMQWRRZKHM3JBCQW6T44SEY3A5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZQGUZDSMBRUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVRTG633UMVZF6Y3MNFRWW#discussioncomment-17052901>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/BE63TGJHBOQ3EA5GKZ5IO7T44SEY3AVCNFSM6AAAAACZMBW7NGVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTOMBVGI4TAMI>. Triage notifications on the go with GitHub Mobile for iOS<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you authored the thread.Message ID: ***@***.***>