Status: historical, non-canonical design; automation retired Date: 2026-08-28
This design is retained for provenance only. Its write-capable workflows were retired because the canonical ACE stack already owns observation, capacity, task-generation, and safety policy. Do not reactivate ONE as a parallel controller; transplant independently useful ideas into ACE through a bounded, reviewed change.
ONE means One Next Evolution.
Its purpose is to make IDKMesh continuously ask and answer one question:
Given the repository state right now, what is the single highest-value bounded action that improves verified capability, community reproduction, or the repository’s ability to improve itself?
ONE is deliberately conservative. It is not a bot that manufactures activity. It is a control loop that turns GitHub activity into evidence, chooses at most one next bounded task, and measures whether that task produced useful descendants.
IDKMesh already has:
The missing operational behavior is continuous convergence.
Without a controller, a self-evolving repository can become a self-expanding repository: more issues, more documents, more agents, and more automation without enough verified integration.
ONE therefore optimizes:
verified useful improvement * community multiplication * information gain
-------------------------------------------------------------------------
review attention + implementation cost + coordination noise + risk
and initially allows only one active generated execution task at a time.
A GitHub event is not an iteration.
ONE defines an iteration as an evolution epoch:
observe
-> construct repository state
-> estimate review/community capacity
-> generate candidate actions
-> score candidates
-> choose one bounded action
-> expose it as a public GitHub task
-> independent agent/human works it
-> verify/integrate/reject
-> measure outcome + descendants
-> next epoch
Formally:
E_t = (S_t, A_t, a*_t, X_t, S_(t+1))
where:
S_t = observable GitHub/repository state;A_t = candidate bounded actions;a*_t = selected next action;X_t = evidence generated by execution/review/tests/community response;S_(t+1) = measured next state.A rejected idea can be a successful iteration when it removes uncertainty cheaply.
Runs continuously through GitHub Actions and GitHub events.
Responsibilities:
[ONE] Continuous Evolution Queue issue;This plane works without an LLM.
ChatGPT can be connected to GitHub and can be run as a scheduled recurring task where the product/account supports it.
The cognitive worker should:
one:agent-task;GitHub Actions cannot invoke this exact ChatGPT web conversation by magic. The bridge is a ChatGPT scheduled task or another explicitly configured agent integration. The repository-side algorithm must therefore remain useful even when no ChatGPT cognitive worker is active.
ONE derives a compact state vector:
S_t = [P, I, A, C, V, L, D, N, R]
where:
P = open pull-request pressure;I = open priority/blocking issue pressure;A = active ONE-generated execution tasks;C = contributor/community capacity proxy;V = verification/review availability proxy;L = current review load;D = community descendant evidence;N = newcomer-ready task inventory;R = risk/coordination debt.These are signals, not truth.
Self-reproduction must slow down when verification becomes the bottleneck.
Use a logistic capacity gate:
Capacity(L) = 1 / (1 + exp((L - K) / tau))
Initial values:
K = 8
Tau = 2
A simple v0 load proxy is:
L = open_PRs
+ 0.5 * stale_PRs
+ 1.5 * active_ONE_tasks
Interpretation:
The coefficients are hypotheses and must be calibrated from evidence.
ONE does not ask an LLM to invent an unlimited plan. It first chooses among typed actions.
VERIFY_OR_UNBLOCK_PRUse when an open PR is a high-value integration bottleneck.
Possible generated task:
Independently inspect PR #N, identify the smallest blocker, and return test/review evidence or a minimal corrective PR.
Community value: reviewers/security/test contributors can participate without owning the whole subsystem.
ADVANCE_PRIORITY_ISSUEUse when no integration bottleneck dominates but a P0/high-priority issue blocks the product loop.
Possible generated task:
Reduce issue #N to one independently verifiable next artifact and implement or document that artifact.
ONBOARDING_SEEDUse only when newcomer-ready inventory is too low and review capacity is healthy.
Possible paths:
PUBLISH_EVIDENCEUse after a meaningful verified experiment/result when the result is difficult for outsiders to discover or reproduce.
The output should be a reproducible public artifact, not promotional copy without evidence.
CONSOLIDATEUse when review pressure or structural debt is high.
Actions include:
Consolidation is a growth strategy because lower contributor friction and reviewer load increase future carrying capacity.
For candidate action a:
ONE(a) =
ExpectedVerifiedDelta(a)
* InformationGain(a)
* DependencyUnlock(a)
* CommunityMultiplier(a)
* Reversibility(a)
* Capacity(L)
-------------------------------------------------
1
+ ReviewCost(a)
+ ImplementationCost(a)
+ CoordinationNoise(a)
+ SafetyRisk(a)
Select:
a* = argmax ONE(a)
subject to hard constraints.
A useful community multiplier is:
CommunityMultiplier =
1
+ newcomer_accessibility
+ reusable_surface
+ ownership_transfer
+ descendant_potential
+ reproducibility/shareability
This favors work that makes the next contribution easier.
The fastest sustainable growth comes from increasing conversion and reproduction, not manufacturing stars/comments.
Model the public contribution funnel as:
visitor
-> understands
-> finds bounded task
-> claims task
-> produces candidate
-> receives review
-> produces verified contribution
-> returns
-> enables another contributor
A conceptual viral coefficient is:
K_community =
p_understand
* p_claim
* p_complete
* p_reviewed
* p_return
* descendants_per_success
The target is eventually:
K_community > 1
but only while reviewer load remains stable.
The v0 controller intentionally uses max_active_generated_tasks = 1. Increase the branching factor only after measured evidence shows healthy completion, independent review, and return/descendant behavior.
The repository should hack friction and conversion, not people.
High-leverage mechanisms:
ONE must not use:
These may create short-term attention while damaging the actual community reproduction number.
The GitHub workflow maintains one issue:
[ONE] Continuous Evolution Queue
It reports:
The queue is the hand-off boundary between deterministic GitHub observation and humans/ChatGPT/other agents.
A ONE-generated issue must be bounded and contain:
The controller should avoid duplicates and should not create a second active generated task while one is already open in v0.
A suitable recurring cognitive-worker instruction is:
Inspect MSKazemi/idkmesh through the connected GitHub app. Read the ONE queue,
CURRENT_PRIORITIES, the repository improvement loop, and open ONE agent tasks.
If one ONE task is open, advance the highest-priority bounded task with an
inspectable GitHub artifact (branch/PR/test/research/review evidence) when safe.
Do not merge or approve your own changes. Do not create duplicate work. If the
repository is review-saturated, prefer verification/consolidation. If no ONE task
exists, inspect the repository and propose at most one high-value bounded issue
only when it passes the capacity and duplication gates. Record community impact
and evidence. Stop after one bounded outcome.
An hourly schedule is the maximum useful cadence for the ChatGPT scheduled-worker path. GitHub events remain the faster sensor path.
ONE should earn autonomy.
Reports only.
Maintains one public queue/recommendation issue.
Allowed only when:
A human or external/scheduled ChatGPT agent may implement the task on a branch and open a PR.
Independent checks/review decide whether to integrate.
ONE does not autonomously self-approve/self-merge constitutional, governance, security, verification-policy, or evolution-controller changes.
Measure at least:
A fast-growing community with exploding review latency is not healthy growth.
For the initial controller:
if active_ONE_tasks >= 1:
do not spawn
recommend EXECUTE_OR_VERIFY
elif review_load > K:
do not spawn
recommend CONSOLIDATE
elif high_value_open_PR_exists:
spawn one VERIFY_OR_UNBLOCK_PR task
elif high_priority_issue_exists:
spawn one ADVANCE_PRIORITY_ISSUE task
elif newcomer_inventory_is_low and Capacity(L) is healthy:
spawn one ONBOARDING_SEED
else:
maintain queue and collect evidence
This is intentionally simple enough to audit and falsify.
The repository should not try to become busy by itself. It should become better at creating the next independently useful contribution.
The desired long-term behavior is an autocatalytic community where each verified iteration increases the probability, quality, or independence of the next one—without requiring one maintainer to manually manufacture the community.