Add YYLO

[InsightFactoryAPP]

Tool

YYLO — command-line orchestrator for coding agents, repeatable workflows, and receipt-backed repository changes.

• Category: orchestrators
• Classification: agent-native
• Pricing: open-source (MIT)
• Website / source: https://github.com/yylo-dev/yylo · npm: @yylo/cli

Inclusion test

1. Classification: agent-native — coding agents are the core actor YYLO coordinates. The README's first line: "YYLO is a command-line orchestrator for coding agents, repeatable workflows, and receipt-backed repository changes."
2. Concrete agent outcome: agents receive typed tasks in dedicated exact-base worktrees, produce receipt-backed commits, and land changes through a fenced merge queue with risk-based review.
3. First-party evidence: the repository README (linked in evidenceSources) documents the agent runs (yy pi, agent aliases), the typed task/merge flow (task start → worktree; merge queue with 0/1/2 sequential reviewers by risk), and the npm distribution.
4. Substantive capability: task lifecycle, validation evidence, merge orchestration, and release-readiness gating are the product itself, not a thin wrapper.
5. Defensible: every claim in the tool file is quotable from the current README.

Changes

• tools/yylo.md — new tool entry (frontmatter + short body with a "So agents can..." section)
• tool-submitters.json — registers yylo

npm test (71/71) and npm run validate:content -- --require-submitters pass locally.

Disclosure

I'm part of the YYLO team; this PR was prepared with an AI coding agent and reviewed by me before submission. YYLO is used daily in our own repositories. Happy to adjust the entry or evidence to fit the editorial policy.

[foo-bender]

Outcome: evidence-requested

Policy assessment

@InsightFactoryAPP YYLO otherwise has a supportable agent-native inclusion case: its documented coding-agent runs, exact-base task worktrees, typed task boundaries, validation receipts, and risk-based merge queue are substantive orchestration capabilities. The Orchestrators category fits, the limitations are appropriately bounded, and no duplicate was found on current main. SEO metadata was not evaluated because one submitted evidence URL could not be inspected.

Evidence checked

• https://github.com/yylo-dev/yylo — validated the CLI orchestration, agent commands, typed task/worktree lifecycle, receipts, merge queue, limitations, and MIT licence.
• https://github.com/yylo-dev/yylo#typed-task-and-merge-flow — validated the exact-base worktree, preflight/finish gates, and risk-sized review flow.
• https://www.npmjs.com/package/@yylo/cli — inaccessible to this review client (HTTP 403 Cloudflare interstitial), so the submitted package-distribution claim could not be substantiated from this URL.

Evidence requiring correction or removal

• https://www.npmjs.com/package/@yylo/cli — the submitted URL returned an HTTP 403/Cloudflare interstitial rather than inspectable package content. Replace it with an accessible first-party HTTPS source that directly supports distribution of the yylo and yy commands, or remove the evidence item and any dependent claim.

• https://www.npmjs.com/package/@yylo/cli — The submitted npm URL returned an HTTP 403 Cloudflare interstitial, so its package-distribution claim could not be substantiated from that URL.

Please correct or remove each evidence item above.

Checks run

• Reviewed the PR body, complete diff, listing, classification, category fit, duplicate search, limitations, pricing/licence claims, and current GitHub check (enrich: success).
• On the exact head merged with current main (af5b0fc05df21cf7cff658bd64be4d01ae2b5648), Node 24.19.0: npm run validate:content passed; npm test passed 84/84.

[InsightFactoryAPP]

Done — the npm evidence URL is now https://registry.npmjs.org/@yylo/cli (registry JSON, no Cloudflare interstitial), which directly shows the published @yylo/cli package with bin commands yylo and yy (plus ypl); the PR body link was updated to match and accessedAt refreshed to 2026-09-25. No claims changed.

[foo-bender]

Outcome: meets-policy

Policy assessment
YYLO passes as agent-native: coding agents are the actors in a substantive task lifecycle that creates exact-base worktrees, records validation receipts, and gates repository changes through a risk-based merge queue. The orchestrators category fits, external agent/provider and release-authority limits are disclosed, and no duplicate listing was found. @bradvin, this is ready for the inclusion decision.

Evidence checked
Validated the first-party repository/README and typed-task section (https://github.com/yylo-dev/yylo and https://github.com/yylo-dev/yylo#typed-task-and-merge-flow), npm registry metadata (https://registry.npmjs.org/@yylo/cli), and MIT license. They support the orchestration, worktree, receipt, merge-review, distribution, and licence claims.

Checks run
Against current main 66026dc9943c8c8c4b2fa344e033206116b90c11 with final head: npm run validate:content passed; npm test passed (84/84).

Reviewer-owned SEO metadata

• agentSummary: written — “YYLO is for developers and project operators who want coding agents to work through explicit repository boundaries. It creates exact-base task worktrees, collects receipt-backed validation evidence, and routes completed changes through a fenced merge queue with review depth based on risk. Agent providers and release or deployment authority remain external.” This adds the supported workflow and limits without replacing the product description.
• seoTitle: written — “YYLO: Typed Task Orchestration for Coding Agents” — names the supported agent-facing use.
• seoDescription: written — “Explore YYLO's CLI workflow for isolated coding-agent worktrees, receipt-backed validation, and risk-based merge review before repository changes land.” — summarizes the validated differentiators.

Reviewer commit: 62044959f6b88150cde1b309e7443550b37e679a — InsightFactoryAPP@6204495. The existing description was preserved byte-for-byte.

[bradvin]

@InsightFactoryAPP I am not convinced this is the right fit for agentfirst.directory
I had a look at your site, and YYLO seems like a CLI + harness to use as a development tool.

I am not sure I want to include any and all agent-related dev tools to this directory.

Convince me.

[InsightFactoryAPP]

Hi @bradvin — thanks for engaging directly; fair challenge, and it's the right bar for this directory. Let me make the case as concretely as I can.

The distinction that matters here is who the actor is. A dev tool has a human actor and treats agents as something to build or manage. YYLO inverts that: coding agents perform the repository work. task start hands an agent a typed task in a dedicated exact-base worktree; the agent edits, tests, and commits there; task finish independently verifies the result; merge land composes and records it. "Process exit is not completion" is a stated invariant — the orchestrator, not the agent's own claim, defines done. Humans hold the authority points (merge, release, production mutation), not the task execution.

Mapped against the Orchestrators inclusion points, all quotable from the README:

• Coordinates multiple agents or runs — typed task records with dependency edges; a controller workspace prepares per-task worktrees; the agent runtimes (yy pi and its aliases) are the configured executors.
• Shared state — the YYLO Ledger Record/task store: task state, wiki, and evidence records held in the repository.
• Observability — validation receipts and run evidence; watch is a read-only observer that can never launch, retry, or complete work.
• Approvals / governance — finish enforces scope, dirty-byte, hydration, ownership, and validation checks before queueing; merge land composes in a private detached candidate under Git expected-old-ref protection; publish requires separate authority.

On "agent-related dev tools" generally: agreed — generic compatibility ("an agent can call it") shouldn't qualify, and I wouldn't ask it to. YYLO's claim is by construction: the workflow only advances through agent-performed, receipt-backed work that a human gates. That's also why the policy review landed on agent-native orchestration rather than a compatibility rationale.

For what it's worth, this PR itself went through that lifecycle — prepared by a coding agent inside a YYLO task worktree and admission-checked before submission, as disclosed in the PR body.

Happy to adjust the entry — sharpen the "So agents can…" framing, or recategorize — if a different framing reads more honestly to you. And if it still doesn't clear the bar, closing with your reasoning is a fair outcome and we'll leave it there.

[foo-bender]

Thanks for the detailed response. I reviewed YYLO against the live listings, especially Symphony, AgentGrid, Paperclip, Mission Control, OneCLI and Local CI.

You have convinced me that being a local CLI or coding development tool is not, by itself, a reason to exclude YYLO. The documented task lifecycle, isolated worktrees, retained evidence and separate landing authority can make it materially different from a launcher or thin wrapper. Based on the directory’s current policy and existing listings, YYLO has a credible inclusion case.

My broader concern still stands. I do not want this decision to create a precedent that every open source coding-agent tool belongs in the directory. I have opened two PRs to make that boundary explicit going forward:

• Content and category policy: Define coding-agent orchestrator inclusion boundary #82
• Public site policy: docs: define coding-agent orchestrator inclusion boundary agentfirst.directory-site#38

The proposed rule is that a coding-agent orchestrator must own a material lifecycle across agent runs, including task assignment, isolation, retained or shared state or validation evidence, and a separate completion, review or landing gate. Launchers, prompt packs, API or MCP wrappers, compatibility claims and ordinary developer automation do not qualify on their own.

Before I can approve this listing, the PR needs a few corrections:

1. The listing says the merge queue chooses zero, one or two reviewers based on risk. The current YYLO documentation says native merge performs no model calls, reviewer selection or test scheduling. That claim needs to be removed or rewritten against a specific, supported release.
2. Pin the capability claims to an exact published version and channel. The current listing mixes stable 0.2.2, prerelease 0.2.3-rc.3, current repository behaviour and npm 0.2.10.
3. Make it clear that the stronger orchestration case applies to Advanced mode. The current docs describe Simple mode as a shared checkout where task completion is local bookkeeping rather than managed delivery.
4. Use https://yylo.dev as websiteUrl, with GitHub retained as githubUrl and supporting evidence.
5. Keep the description narrow and accurate. YYLO is a local coding-agent task and worktree lifecycle tool, not the same type of broad agent control plane as Paperclip or Mission Control.

If the listing is updated to match the current first-party evidence and it passes the clarified boundary, I am open to publishing it. This is not a rejection. I want the listing, and the precedent it creates, to be defensible and consistently applied.

[foo-bender]

Outcome: changes-requested

Prior review: #59 (comment)

The prior conclusion was incomplete or incorrect: YYLO remains eligible in Advanced mode, but the accepted listing contains a retired risk-based reviewer/merge-queue claim, overgeneralizes Advanced-mode behavior, and does not use the canonical product website.
New/current evidence that changed the conclusion: current first-party documentation says native Git delivery launches no models, chooses no reviewers, schedules no test suites, and leaves tests and semantic review to explicit external project checks; it also distinguishes Simple mode's shared-checkout bookkeeping from Advanced mode's isolated worktrees and managed landing.
The earlier comment remains preserved as audit history.

Policy assessment

@InsightFactoryAPP YYLO still clears the current coding-agent orchestrator boundary in Advanced mode: it owns task assignment, exact-base isolation, retained validation evidence, finish gating, and a separate protected landing step. The profile is not currently accurate enough to accept. Please remove or rewrite the fenced merge-queue and zero/one/two-reviewer claims throughout the profile, scope exact-base worktree and managed-landing claims to Advanced mode, and set websiteUrl to https://yylo.dev while keeping the implementation repository in githubUrl.

Evidence checked

• https://github.com/yylo-dev/yylo supports the CLI, agent commands, typed task lifecycle, Advanced-mode worktrees, receipts, and native Git delivery boundaries.
• https://registry.npmjs.org/@yylo/cli supports package version 0.2.10, MIT metadata, and the yylo, yy, and ypl bins.
• https://yylo.dev is the canonical first-party product website named by repository/package metadata.

Evidence requiring correction or removal

• https://github.com/yylo-dev/yylo#typed-task-and-merge-flow — the current section still supports exact-base Advanced-mode worktrees and finish gating, but it expressly says tests and semantic review are external project checks, merge launches no models, chooses no reviewers, schedules no suites, and uses native Git delivery rather than the claimed risk-based merge queue with zero, one, or two reviewers.

Please correct or remove each evidence item above.

No duplicate was found on current main, the published directory, or another open PR.

Checks run

On exact head 7add1cfb3a5913d873ec46d31b398204e68e2b9e merged with current main 0fd239df948dbfa9f2927852b15dd9b4ad20e4ac: npm run validate:content passed; npm test passed 84/84. Structural checks do not resolve the factual contradictions above.

[InsightFactoryAPP]

Hi @foo-bender (and @bradvin) — thank you for the thorough reassessment. All three corrections are applied in 06d3060 (only tools/yylo.md changed; npm run validate:content and npm test pass on the branch):

1. Retired merge-queue / zero-one-two-reviewer claims removed throughout the profile. agentSummary, seoDescription, classificationRationaleMd, inclusionRationaleMd, bestForMd, the body, and the merge-queue tag no longer describe a risk-based merge queue or any reviewer count. They now match the current docs: delivery is a managed one-task native Git merge ("Merge uses native Git and automatically records verified integration in Ledger"; "Tests and semantic reviews are explicit project checks outside merge. Merge launches no models, chooses no reviewers, schedules no suites, and maintains no validation cache"). The second evidence claim was rewritten to the same effect with accessedAt refreshed to 2026-09-28.

2. Exact-base worktree and managed-landing claims scoped to Advanced mode. Every such claim now says "Advanced workspaces"/"Advanced-mode", and the first body bullet notes that Simple mode keeps one shared checkout for bookkeeping — matching "Choose Simple or Advanced" (Simple: one shared checkout; Advanced: separate controller, isolated task worktrees and managed merging).

3. websiteUrl set to https://yylo.dev, with the implementation repository kept in githubUrl.

Happy to adjust anything further.

[foo-bender]

Outcome: changes-requested

Policy assessment

@InsightFactoryAPP YYLO still clears the current coding-agent orchestrator boundary in Advanced mode, and this revision resolves the prior requests to remove risk-based reviewer/merge-queue claims, scope isolated worktrees and managed landing to Advanced mode, and use https://yylo.dev as the canonical website. The profile is not yet internally supportable across current first-party release surfaces.

Please make these remaining changes in one revision:

1. Pin the Advanced-mode and native-Git capability claims to a coherent published version/channel, or have the first-party surfaces reconciled. The current website/docs call 0.2.2 stable and 0.2.3-rc.3 prerelease, while npm marks 0.2.10 latest; the repository and the published 0.2.10 package README still call 0.2.10 unreleased source.
2. Rewrite “preflight and finish gating”: current documentation describes preflight as optional, read-only diagnostics, while finish is the gate.
3. Qualify “recorded in Ledger” throughout. Current documentation says Git success and Ledger projection are separate and projection is retryable; use wording such as “with separate, retryable Ledger projection.”

Evidence checked

• https://github.com/yylo-dev/yylo supports the CLI, agent commands, typed tasks, Advanced-mode exact-base worktrees, validation evidence, native-Git delivery, expected-old protection, and separate release authority. It also states that preflight is optional and Ledger projection is separate and retryable.
• https://github.com/yylo-dev/yylo#typed-task-and-merge-flow supports Advanced-mode isolation, finish gating, and native-Git landing, but not the submitted “preflight ... gating” wording.
• https://registry.npmjs.org/@yylo/cli currently reports 0.2.10 as latest, MIT, and the yylo, yy, and ypl bins.
• https://yylo.dev and https://yylo.dev/docs/yylo identify 0.2.2 as stable and 0.2.3-rc.3 as prerelease; the docs scope the relevant task/landing path to Advanced mode.
• https://github.com/yylo-dev/yylo/releases has no 0.2.10 release or tag.
• https://github.com/yylo-dev/yylo/blob/main/LICENSE confirms MIT licensing.

Evidence requiring correction or removal

• https://github.com/yylo-dev/yylo#typed-task-and-merge-flow — the submitted claim calls both preflight and finish “gating,” but current documentation makes preflight optional, read-only diagnostics and makes finish the admission gate. The same source says Ledger projection is separate and retryable, which conflicts with unqualified “recorded in Ledger” wording added in this revision.
• https://registry.npmjs.org/@yylo/cli — the exact registry response supports the package/binary facts, but its latest: 0.2.10 channel conflicts materially with the current website, docs, repository README, and the published package README, which identify 0.2.2 as stable and 0.2.10 as unreleased source. Reconcile the first-party channel/version record or rewrite and pin the listing to a coherent published release.

Please correct or remove each evidence item above.

No duplicate was found on current main, the published directory, or another open PR. SEO metadata was not evaluated and no reviewer commit was made because the substantive evidence/version conflicts remain.

Checks run

On exact head 06d3060fc4a50452b5c100ec4e408d61cb6b1cc8 merged cleanly with current main 755fb203681550170c5bb80014318322d80fe6b4, using Node 24.21.0: npm run validate:content passed; npm test passed 84/84. Structural checks do not resolve the factual conflicts above.

[InsightFactoryAPP]

Hi @foo-bender — thanks for the precise remaining items. All three are applied in 29b8af0 (only tools/yylo.md changed; npm run validate:content passes and npm test passes 84/84 on the branch):

1. Version channels pinned and disclosed, not conflated. The npm evidence claim no longer presents 0.2.10 as the coherent latest. It now states the channels verbatim: the product website identifies 0.2.2 as the current stable release and 0.2.3-rc.3 as prerelease, while the registry's latest tag points at 0.2.10, an artifact whose own README marks it unreleased source; capability claims in the listing are pinned to the documented stable channel and current repository documentation, not to the 0.2.10 artifact. unknownsMd now discloses the same first-party surface disagreement so the boundary is visible in the listing itself.

2. "Preflight and finish gating" rewritten. The evidence claim now reads "finish gating that verifies a clean committed result and queues it without merging (preflight is optional, read-only diagnostics, not a gate)" — matching the current documentation that finish is the admission gate.

3. "Recorded in Ledger" qualified throughout. agentSummary, classificationRationaleMd, and the body now say the verified Git result is recorded "with separate, retryable Ledger projection" (merge land records the verified Git result; Ledger projection is separate and retryable via merge project). The unqualified phrasing is gone — grep-clean across the profile.

Happy to adjust anything further.

[foo-bender]

Outcome: changes-requested

Policy assessment

@InsightFactoryAPP YYLO still clears the coding-agent orchestrator boundary: the documented lifecycle owns task assignment, isolated worktrees, retained validation evidence, finish admission, and a separate protected landing step. This revision correctly makes preflight optional/read-only and qualifies Ledger projection as separate and retryable. The version/channel request is not resolved, however.

“Pinned to the documented stable channel and current repository documentation” is not one coherent version or channel. The current website/docs call 0.2.2 stable, explicitly say 0.2.2 uses the earlier merge-queue surface, label Simple/Advanced behavior as source-candidate behavior rather than a stable-release claim, and verify native-Git delivery for 0.2.3-rc.3. Meanwhile npm currently marks 0.2.10 latest; the published 0.2.10 README is byte-for-byte the current repository README and supplies the listing's Simple/Advanced, optional-preflight, and current native-Git wording, even though that README calls itself “unreleased source.” The profile therefore relies on 0.2.10/current-source behavior while saying it does not.

Please make the capability record internally consistent in one revision. Pin the relevant claims throughout the profile and evidence to one exact published artifact/channel. One defensible path is to identify npm 0.2.10 explicitly as the published artifact that contains the submitted behavior and disclose that the website's stable-channel text is stale; alternatively, use an earlier exact release and remove or rewrite capabilities that release does not contain. Also split the website/version facts into their own exact first-party evidence item instead of attributing them to the registry URL.

Evidence checked

• https://github.com/yylo-dev/yylo and https://github.com/yylo-dev/yylo#typed-task-and-merge-flow support the current-source CLI, agent commands, typed tasks, Advanced-mode exact-base worktrees, finish gating, native-Git landing, expected-old protection, optional preflight, and separate retryable Ledger projection. Current package.json is 0.2.10 and the README calls that source unreleased.
• https://registry.npmjs.org/@yylo/cli reports latest: 0.2.10 and next: 0.2.3-rc.3; the exact 0.2.10 artifact has MIT metadata, the yylo, yy, and ypl bins, and the same README as current repository main.
• https://yylo.dev and https://yylo.dev/docs/yylo identify 0.2.2 as stable and 0.2.3-rc.3 as prerelease; the docs say Simple/Advanced is source-candidate behavior, 0.2.2 uses the earlier merge queue, and native-Git delivery is verified for 0.2.3-rc.3.
• https://github.com/yylo-dev/yylo/releases has no 0.2.2, 0.2.3-rc.3, or 0.2.10 release/tag. https://github.com/yylo-dev/yylo/blob/main/LICENSE confirms MIT licensing. The repository contains substantive implementation code rather than a README-only stub.

Evidence requiring correction or removal

• https://registry.npmjs.org/@yylo/cli — the exact registry response supports the package, bins, MIT metadata, dist-tags, and embedded 0.2.10 README, but it does not support the product website's version labels. More importantly, the submitted claim says capabilities are not pinned to the 0.2.10 artifact even though the submitted current-repository behaviors and the artifact README are the same, while stable 0.2.2 lacks those behaviors.

Please correct or remove each evidence item above.

No duplicate was found on current main, the published directory, or another open PR. Schema, category, classification, website/source identity, pricing/licensing, and stated external-provider/release-authority limitations were otherwise supportable. Optional SEO metadata was not evaluated and no reviewer commit was made because the version/evidence conflict remains substantive.

Checks run

On exact head 29b8af033bb424df7cff118e9efc8aafaca14c90 merged cleanly with current main 755fb203681550170c5bb80014318322d80fe6b4, using Node 24.21.0: npm run validate:content passed; npm test passed 84/84. GitHub's current enrich check is successful. Structural checks do not resolve the factual conflict above.

[InsightFactoryAPP]

Hi @foo-bender — thank you for the precise reassessment. You are right: "pinned to the documented stable channel and current repository documentation" still left two anchors in one profile, while the listing's capability wording (Simple/Advanced, optional read-only preflight, current native-Git delivery, separate retryable Ledger projection) is in fact the 0.2.10/current-repository README — the artifact's own text. Applied in fe4ccc9 (only tools/yylo.md changed; npm run validate:content passes and npm test passes 84/84 on the branch):

1. One artifact anchor throughout. Capability claims are now pinned to the exact published npm 0.2.10 artifact (registry latest), and the registry evidence item states that the 0.2.10 artifact's embedded README is byte-for-byte the current repository README, so the repository-README-derived wording in the listing is the published artifact's own wording. I verified the byte-identity directly before writing it.

2. Website facts split out. The website's version labels (0.2.2 stable, 0.2.3-rc.3 prerelease, Simple/Advanced as source-candidate behavior, native-Git verified for 0.2.3-rc.3) now live in their own evidence item citing https://yylo.dev, which explicitly discloses that the stable-channel text lags the registry's latest artifact, that the stable channel does not contain the listed capabilities, and that the discrepancy is disclosed rather than relied on.

3. Registry item scoped to registry facts. The npm evidence item now claims only what the registry response supports (package, yylo/yy/ypl bins, MIT metadata, dist-tags, embedded README) and says so explicitly, per your correction list.

unknownsMd was rewritten to match: the website's stable-channel text is treated as stale relative to the published 0.2.10 artifact and is not relied on for any capability claim.

[foo-bender]

Outcome: evidence-requested

Policy assessment

@InsightFactoryAPP YYLO still clears the coding-agent orchestrator boundary in Advanced mode: the documented lifecycle owns task assignment, exact-base isolation, retained validation evidence, finish admission, and a separate protected native-Git landing step. This revision resolves the prior version/channel request by anchoring the capability record to the published npm 0.2.10 artifact and explicitly disclosing the disagreement with the website channel labels. Classification, category, pricing/licensing, limitations, and the remaining profile wording are supportable.

One submitted evidence item cannot be validated at its exact URL. Please replace it with exact first-party HTTPS URL(s) that return the cited content directly, and split the homepage and documentation facts if needed.

Evidence checked

• https://github.com/yylo-dev/yylo — supports the CLI, agent commands, Advanced-mode task/worktree lifecycle, finish gate, native-Git landing, optional preflight, separate retryable Ledger projection, and MIT licence.
• https://github.com/yylo-dev/yylo#typed-task-and-merge-flow — supports the submitted Advanced-mode and delivery-boundary claim.
• https://registry.npmjs.org/@yylo/cli — supports latest: 0.2.10, next: 0.2.3-rc.3, MIT metadata, the submitted bins, and the current README. I also verified that the registry README, repository README, and README inside the 0.2.10 tarball are byte-identical.
• The current canonical website and docs were checked as a contradiction pass: they still label 0.2.2 stable and 0.2.3-rc.3 prerelease and describe later behavior separately, consistent with the profile's disclosed channel disagreement.

Evidence requiring correction or removal

• https://yylo.dev — the exact submitted URL returns HTTP 308 with only a redirect body, so it does not itself contain or substantiate the claimed website-and-docs version facts. The redirected homepage also does not contain all of the documentation-specific Simple/Advanced and native-Git assertions combined into this one claim. Use exact 200-response first-party URL(s) and scope each claim to the content at that exact URL.

Please correct or remove each evidence item above.

Checks run

On exact head fe4ccc9b2acfdfbf8ee27174809f4ff290ca67dd merged with current main 755fb203681550170c5bb80014318322d80fe6b4, using Node 24.21.0: npm run validate:content passed; npm test passed 84/84. GitHub's current enrich check is successful. SEO metadata was not evaluated and no reviewer commit was made because the evidence item above remains invalid.

[InsightFactoryAPP]

Hi @foo-bender — thank you for the precise evidence pass. You are right: the submitted https://yylo.dev URL returns HTTP 308 with only a redirect body, and that one item combined homepage version facts with documentation-specific assertions the redirected page does not itself contain. Applied in 6d565a2 (only tools/yylo.md changed):

1. Exact 200-response URLs, one scope per item. The single website item is replaced by two items, each scoped to the content at its exact URL:

   • https://www.yylo.dev/ — the homepage's Stable 0.2.2 version chip and install quickstart pinned to @yylo/cli@0.2.2 (identifying 0.2.2 as the current stable release on that page). The item states explicitly that the homepage does not itself describe Simple/Advanced modes, the earlier merge-queue surface, or native Git delivery.
   • https://www.yylo.dev/docs/yylo — the documentation page's install-channel labels (Stable 0.2.2; Prerelease 0.2.3-rc.3 · opt in), its statement that Stable 0.2.2 uses the earlier merge-queue surface and that the native commands below should not be run on that version, its presentation of the Simple/Advanced workspace-mode selection as source behavior that is not a claim about the stable release, and its task-lifecycle and native-Git-delivery documentation under the Prerelease 0.2.3-rc.3 heading.

2. Verification done before pushing. Both URLs were fetched fresh and return direct 200 responses with no redirect hop (the 308 only occurs on the bare apex yylo.dev). npm run validate:content passes and npm test passes 84/84 on 6d565a2. The disclosure framing is unchanged: the stable-channel labels lag the registry's latest artifact, the listing's version anchor remains the npm 0.2.10 artifact, and the disagreement is disclosed rather than relied on. The frontmatter websiteUrl stays https://yylo.dev as the canonical website per your earlier direction (the site's own rel=canonical also points there); only the evidence-item URLs changed.

[foo-bender]

Outcome: meets-policy

Policy assessment

YYLO passes as an agent-native coding-agent orchestrator in Advanced mode: it owns task assignment, exact-base worktree isolation, retained validation evidence, finish admission, and a separate protected native-Git landing step. The profile scopes those capabilities to the published npm 0.2.10 artifact, distinguishes Simple mode, discloses the website channel disagreement, preserves external test/review and release authority, fits Orchestrators, and has no duplicate on current main, the published directory, or another open PR. @bradvin, this is ready for the inclusion decision.

Evidence checked

• https://github.com/yylo-dev/yylo and https://github.com/yylo-dev/yylo#typed-task-and-merge-flow support the CLI, agent runs, Advanced-mode task/worktree lifecycle, optional read-only preflight, finish gate, protected native-Git landing, and separate retryable Ledger projection.
• https://registry.npmjs.org/@yylo/cli supports latest: 0.2.10, next: 0.2.3-rc.3, MIT metadata, the submitted bins, and the current README; the 0.2.10 tarball README and current repository README have identical bytes.
• https://www.yylo.dev/ directly returns 200 and identifies 0.2.2 as stable. https://www.yylo.dev/docs/yylo directly returns 200 and documents the stable/prerelease/source-candidate distinctions described in the profile.
• The official website, docs, repository, package/tarball metadata, and license were checked for conflicting capability, version/channel, distribution, and licensing claims; the disclosed channel disagreement is accurately bounded.

Checks run

On exact final head 34a51d3ef8404e3fb715b3a5f346991f26183966 merged cleanly with current main 755fb203681550170c5bb80014318322d80fe6b4, using Node 24.20.0: npm run validate:content passed; npm test passed 84/84. GitHub's pre-review enrich check was successful.

Reviewer-owned SEO metadata

tools/yylo.md

• agentSummary: accepted — “YYLO is for developers and project operators who want coding agents to work through explicit repository boundaries. In Advanced workspaces it creates exact-base task worktrees, collects receipt-backed validation evidence, and lands completed changes through a managed one-task native Git merge whose verified Git result is recorded with separate, retryable Ledger projection; tests and semantic review remain explicit external project checks. Agent providers and release or deployment authority remain external.” The validated 0.2.10 artifact supports the workflow, mode boundary, and external-authority limits.
• seoTitle: accepted — “YYLO: Typed Task Orchestration for Coding Agents” accurately names the documented agent-facing use.
• seoDescription: accepted — “Explore YYLO's Advanced-mode workflow for isolated coding-agent task worktrees, receipt-backed validation, and managed native Git delivery for repository changes.” It summarizes the validated differentiators without extending the evidence.

Reviewer commit: 34a51d3ef8404e3fb715b3a5f346991f26183966 — InsightFactoryAPP@34a51d3. The existing description was preserved byte-for-byte.

[bradvin]

@InsightFactoryAPP thanks for sticking with this, and getting this across the line. Bender can seem picky at times, but he is a good boy :D

Approved!

[InsightFactoryAPP]

Thank you @bradvin — really glad it made it across the line!

And thanks @foo-bender for the thorough policy review along the way; the pickiness made the profile better. Much appreciated.