[Tracking] SearchSpace distillation coverage and knowledge consolidation #91

Activity

1. Dong1017

   added

   kind:trackingTracking umbrella that follows child workTracking umbrella that follows child work

   area:knowledgeKnowledge line: packs, skill library, knowledge admissionKnowledge line: packs, skill library, knowledge admission

   on Oct 22, 2026
2. Dong1017 commented on Oct 22, 2026

   

   Dong1017

   on Oct 22, 2026 – with ChatGPT Codex Connector

   CollaboratorAuthor

   More actions

   Suggested execution order

   Prioritize bounded gaps with existing source evidence and canonical owners before descriptor-only intake. These are recommendations, not blanket execution or paid-evaluation authorization.

   Track	Suggested order	Why
   Incremental distillation	1. fastsafetensors TP transfer → 2. awesome-ascend-skills host KV / HCCL → 3. DLRover persistence / replica transport → 4. AKG bounded compiler mechanism → 5. afd-plugin / vllm-rlt preflight	Start with identified gaps and reusable owners; unpinned descriptor-only candidates require source selection before extraction
   Knowledge consolidation	1. llama.cpp → 2. vLLM-Ascend → 3. Diffusers → 4. SGLang → 5. vLLM / vLLM-Omni → 6. TensorRT-LLM / PyTorch	Reconcile multi-pin applicability and navigation; this is an overlap-review order, not a claim that all pairs conflict
   Paper recovery	Recover/check the recorded missing archive first; then prioritize PagedAttention / Sarathi-Serve → DistServe / Mooncake → ZeRO-Infinity / FlexGen according to the selected task	Avoid redoing existing extraction; exact versions and readsets must be established before crediting coverage

   Link with #88 without another registry

   flowchart LR
       A["Tracker gap or consolidation"] --> B["Bounded delivery PR"]
       B --> C["Skill Eval plan"]
       C --> D["Authorized run and evidence"]
       D --> E["Update tracker row"]
   

   Loading

   • This tracker answers what source/scope and where. Skill Eval v1.1: automated evaluation for skill additions and updates #88 delivers tools answering what changed in task behavior.
   • New skill: absent/new comparison. Updated skill or behavioral consolidation: old/new comparison, retaining meaningful old-version regression cases. Pure index/link/provenance changes: deterministic integrity checks; no mandatory paid agent run.
   • Start the first joint pilot with one bounded llama.cpp consolidation only if overlap review identifies an actual skill-content change. Do not invent a rewrite to manufacture an eval demonstration.
   • Until Skill Eval v1.1: automated evaluation for skill additions and updates #88's comparison/PR automation ships, keep evaluation manual or mark not evaluated/uncovered. Offline Fake-client tests validate the evaluation tool, not skill efficacy.
   • Update the existing row with delivery/eval evidence and remaining limits. A landed extraction can remain candidate/unvalidated; neither “merged” nor “no observed regression” proves added benefit.
3. david6666666

   closed this as completedin #114on Oct 23, 2026
4. Dong1017

   reopened this on Oct 23, 2026
5. Dong1017 commented on Oct 23, 2026

   

   Dong1017

   on Oct 23, 2026 – with ChatGPT Codex Connector

   CollaboratorAuthor

   More actions

   Reopened at the owner's request. This is a living SearchSpace coverage/consolidation tracker, not the acceptance issue for a single distillation PR. A merged scoped delivery updates its relevant row; it does not complete the whole tracker. Please reference this issue with Refs #91 / Related to #91, rather than closing keywords. Pinning is for visibility, not protection against closure.
6. Dong1017

   pinned this issue on Oct 23, 2026
7. hsliuustc0106

   added a commit that references this issue on Oct 24, 2026

   docs: clarify vLLM-Ascend guidance versions and responsibilities (#130)

   ...

   e6bedfa
8. Dong1017

   added sub-issues on Oct 25, 2026

   • [Task] Distill Flare preparation contracts and session-state lifetimes #148
   • [Task] Distill LoopX goal authority and quota decision boundaries #149
9. Dong1017 commented on Oct 27, 2026

   

   Dong1017

   on Oct 27, 2026

   CollaboratorAuthor

   More actions

   Skill → coverage reverse view, Round 1

   Baseline: main 6b13cf00ccf2e98fcb3144eda69e2442bcb1d652 (2026-10-27).
   Delivery: #194.

   Counting unit. One row per registered skill ID (60 at that revision). The
   21 other SKILL.md documents — five engine entrypoints, their fifteen
   sub-skills, and workflows/inference-engine-research — are listed in their own
   section with a kind and excluded from every count. The historical 41-directory
   figure at the end of the SearchSpace Matrix stays a historical record and is
   not a coverage denominator.

   Scope this round. ID, canonical path, backend, declared task from the
   SKILL.md frontmatter, status/validation/readsets from the sidecar, SearchSpace
   resource layer and lifecycle stage, Reference Matrix section and source,
   and evaluation selection from frozen plans. Anything not read is unknown;
   mechanism, prerequisites and explicit non-goals wait for Round 2.

   Current snapshot, not a capability claim. 60 registered; 47 recorded on a
   resource layer and 24 on two or more; 55 in the Reference Matrix; 55 with a
   sidecar; 2 selected by a frozen plan (inference-benchmark-design,
   dense-performance-evidence in skill-eval-v1-20261021). Thirteen have no
   resource-layer row, five have neither a sidecar nor a Reference Matrix row, and
   58 have no evaluation linkage. Recording the absence is the point; it does not
   assert a gap in the underlying knowledge.

   Mechanics. tools/build_skill_coverage.py is the only writer and
   --check diffs a fresh build against the committed file, so drift is
   detectable and the view stays a projection rather than a third maintained
   matrix. It records an input digest over the files it reads instead of a commit
   SHA, so an unrelated commit does not force regeneration.

   No skill body, sidecar, matrix or maturity was changed; no evaluation, GPU or
   acceptance-rule work was done. Round 2 batches will be chosen from the recorded
   gaps, starting with the five workflow sidecars.

   Refs #91
10. Dong1017

    added 4 commits that reference this issue on Oct 27, 2026

    docs: fix coverage view portability, guidance mappings and state test

    ...

    3e08b15

    docs: regenerate the coverage view on current main

    ...

    54dfee5

    docs: make the coverage digest order stable across platforms

    ...

    b49679e

    test: build the expected digest instead of comparing two calls

    ...

    df5d79f
11. 12 remaining items

    Load more
12. Dong1017

    added 2 commits that reference this issue on Oct 29, 2026

    docs: settle the workflow sidecar shape and let sidecars supply recom…

    ...

    5076062

    docs: settle the workflow sidecar shape and let sidecars supply recom…

    ...

    401ee8a
13. Dong1017 commented on Oct 30, 2026

    

    Dong1017

    on Oct 30, 2026

    Last edited by Dong1017

    CollaboratorAuthor

    More actions

    Batch 2 scope and sidecar semantics

    Updated 2026-10-30 after review. The open question in the earlier text is
    settled: extending batch 1's four typed keys to methods/ is accepted, on the
    condition that each field keeps a stated meaning rather than becoming a free
    text slot. The section on per-key semantics below is new; the frozen ID
    selection and acceptance rules are unchanged.

    Batch 1 merged as 401ee8a2 (#243) and settled the sidecar shape on the six
    registered workflows/ skills. Batch 2 fills applicability and
    recommendations for methods/, reusing the same four typed keys.

    Frozen ID selection

    Read at main = 401ee8a2: 77 registered ids, 41 with an absent or empty
    applicability. methods/ holds 20 registered ids. Three already declare one
    (performance-ceiling-analysis, repository-evolution-analysis,
    video-diffusion-optimization) and are not touched. Batch 2 is the remaining 17:

    assess-serving-preemption, assess-split-backward-schedule,
    audit-fixed-workload-claim, calibrate-serving-simulation,
    checkpoint-recovery-consistency, choose-parallel-training-plan,
    dense-performance-evidence, evaluate-elastic-serving-placement,
    inference-benchmark-design, inference-optimization-casebook,
    kernel-writing-guide, optimization-search-policy,
    plan-activation-residency, skill-evolution-playbook,
    training-input-pipeline, training-resource-budget,
    weight-loading-optimization.

    Why the typed keys fit methods/

    These 17 bodies are already written in that shape. Each names the evidence it
    requires before it will answer, what it returns, the conditions that make its
    conclusion unsafe, and the point at which it withholds a recommendation. The
    section headings at this revision:

    Skill	Input	Output	Refusal
    assess-serving-preemption	"Evidence required for a candidate"	"Decision output"	"Withhold a preemption recommendation if the apparent gain can be explained by different kernels, unmatched parallelism, or an incomparable latency metric"
    assess-split-backward-schedule	"Required evidence"	"Output, checks and stopping point"	"reasons to withhold an enablement recommendation"
    calibrate-serving-simulation	"Inputs and prerequisites"	"Output"	"Failure / stop conditions"
    plan-activation-residency	"Evidence needed"	"Decision procedure"	"Verification proposal and stopping point"
    audit-fixed-workload-claim	"Recover the declared decision"	"Return an auditable conclusion"	"Do not replace missing evidence with a pass"

    Writing the four keys projects text that already exists.

    Field semantics each sidecar must keep

    Key	States	Must not
    scope	What the procedure applies to	Become a capability or efficacy claim
    prerequisites	What must already hold before use: access, tooling, authorization	Restate the input contract
    input_contract	What the caller supplies for the procedure to run	Enumerate the procedure's own steps
    produced_artifact	What the procedure emits, at the evidence level its body supports	Upgrade a proposal into a validated configuration or a measured result
    failure_modes	Conditions under which the procedure yields a wrong or unusable result	Restate limitations
    refusal_point	The point at which the body states it withholds a conclusion	Invent a refusal the body does not state
    hardware	A device dependency the body establishes	Be inferred from a source's hardware

    Two of these carry most of the drift risk across 17 files.

    produced_artifact is the sharper one. Almost every skill in this batch emits a
    proposal, a shortlist or an audited conclusion, explicitly not a validated
    configuration: plan-activation-residency returns "a preferred candidate,
    simpler fallback, resource ledger"; choose-parallel-training-plan returns "the
    best supported candidate and a simpler fallback". A sidecar that wrote
    "an optimized parallel plan" would promote the skill in the one field a reader
    scans first. The declared artifact stays at the body's evidence level.

    failure_modes is distinct from the existing limitations field, which is not
    owner-only: tools/build_skill_index.py emits four generator-owned sentences
    about indexing, authorization and backend categorization, then appends the
    sidecar's own entries. limitations records what the record does not
    establish; failure_modes records how the procedure goes wrong in use. A
    sidecar repeating "Source-derived candidate; no local efficacy validation" under
    failure_modes states nothing new.

    Cross-cutting, unchanged from batch 1: these fields are descriptive, never
    evidential. Filling them raises no verification.locally_verified, and changes
    no status or empirical_validation. recommendations is procedure advice,
    separate from limitations and from #215's evidence-derived PR guidance.

    No mechanical key allowlist in this batch

    The natural way to hold a vocabulary is a closed key set in skill_catalog.
    Batch 2 does not add one. The library currently uses nine distinct
    applicability keys: the seven above, plus architectures and
    excluded_mechanisms in hardware/cuda/reason-hopper-kernels. A closed set
    would either reject that existing sidecar or grandfather it, which is a
    compatibility decision of its own and not a side effect of filling methods/.
    Batches 3 and 4 cover hardware/, repositories/ and frameworks/ and will
    show whether those two keys generalize. Proposed: revisit a closed key set at
    batch 4, when the real vocabulary is known.

    Until then the semantics live in docs/knowledge-base.md under field ownership,
    and batch 1's shape validation still rejects malformed values.

    What this changes in the view

    tools/build_skill_coverage.py renders every key other than scope,
    hardware and prerequisites in the Conditions column. Extending the keys to
    methods/ populates that column for 17 more rows and clears no-applicability
    for them. No new column, generator field or gap type is added; batch 1's
    rendering is reused unchanged.

    Acceptance

    Both --check runs pass with generated output regenerated in the same commit as
    its sources. No verification, status, empirical_validation or sources
    change: the diff in those 17 sidecars touches applicability and
    recommendations only, which is checkable as a mechanical filter. Every
    condition cites its origin in the skill body, a pinned source or an owner-local
    case; a condition with no origin is refused in review. Negative and missing
    results are kept.

    Batch 1's test_applicability_is_descriptive_and_never_promotes_validation
    iterates every sidecar in the library, so it covers these 17 once they are
    filled. Meaning itself is not mechanically checkable; the per-key table above is
    the review standard, not a validator.

    No evaluation, verdict or promotion; no-eval stays in Round 3.
14. Dong1017 commented on Oct 30, 2026

    

    Dong1017

    on Oct 30, 2026 – with ChatGPT Codex Connector

    CollaboratorAuthor

    More actions

    Scoped technical review of Batch 2 question, against main 1147c5bb41724826b64ad13cebc8a4dce5cc278b:

    Recommendation: reuse the four keys for method procedures where their bodies support them, alongside scope/prerequisites—not instead of them. The current applicability validator already accepts string/string-list conditions without a workflows-only restriction. For example, assess-serving-preemption explicitly specifies required evidence, decision output and withholding/stop conditions. No parallel schema or generator behavior change is needed for that projection.

    Two clarifications keep the proposed batch bounded:

    • Conditions is an inventory of key names, not their values. Coverage rendering lists input_contract, …, refusal_point and advice count; the generated catalog preserves the actual applicability values. Clearing no-applicability records a declaration, not validation that every required condition is complete or enforced.
    • Keep per-skill source/section pointers for each extracted condition. Do not turn proposed rules into established configurations, add a new refusal policy, or force all four keys where the body provides no basis. Review the 17 selected IDs individually; this spot-check is not blanket content approval.

    The existing acceptance corrections in 6470996080 still apply, including committed-source --source-revision, regenerated projections and unchanged maturity/evidence fields. Preserve the three excluded owners. Also coordinate training-resource-budget with the already-open #257 source slice: if it lands first, extract against that updated body rather than overwrite its provenance/prerequisites.

    This is a technical recommendation on the proposed extension, not a scope-acceptance decision, task claim, or authorization to begin another implementation. Existing owners and the living tracker remain unchanged.
15. Dong1017

    added a commit that references this issue on Oct 30, 2026

    docs(knowledge): integrate historical MindSpeed provenance (#257)

    ...

    436c950
16. Dong1017 commented on Oct 31, 2026

    

    Dong1017

    on Oct 31, 2026 – with ChatGPT Codex Connector

    CollaboratorAuthor

    More actions

    Round 2 Batches 3–5: scoped continuation

    The requester authorized this Codex session to proceed with the parallel delivery plan: Batch 3 and Batch 4 content work in parallel, with Batch 5 layer analysis alongside them; one integrator owns shared projections and each batch is a separate PR. This session coordinates these three slices under the existing tracker. Other source owners and acceptance responsibilities remain unchanged; #91 stays open.

    Baseline: main ffb77f9a168ba1cb22f7ba261f289d24dbb6698f. Batch 1 is merged. Batch 2 remains in #263 at a559b12a1dcf1d549e801dd645a949b0f730a75f, with 17 selected sidecars, current Ready checks passing and review recheck still pending. This continuation does not merge or independently approve #263.

    • Batch 3: all 22 registered hardware IDs below; preserve the 2 existing applicability declarations, fill source-supported conditions and procedure advice. Current gaps: 20 absent applicability, 22 absent recommendations.
    • Batch 4: all 29 registered repository/framework IDs below, replacing the historical count of 21. Preserve 25 existing applicability declarations; current gaps are 4 absent applicability and 29 absent recommendations. A closed key allowlist remains deferred, not silently adopted.
    • Batch 5: the 15 current unassigned resource-layer IDs below, replacing the historical count of 13. Real mappings remain in the SearchSpace Matrix; reasoned not-applicable belongs to the sidecar. Unknown, N/A, covered, supplementary and contradictory states must remain distinguishable. A missing mapping is not proof that the skill is non-resource work.

    Each condition/advice/layer decision must trace to its existing body, pinned source or owner-local case. Preserve sources/readsets, maturity and empirical-validation fields. No new source extraction, device/model execution, paid evaluation or efficacy claim. Existing #277–#279 source slices retain their owners; shared matrix rows must be preserved during integration.

    Validation: scoped semantic review against source sections; exact allowed-field diff audit; reachable committed source snapshot followed by a separate generated-projection commit; both generator checks and applicable tests, then current-head Ready CI. No amend may remove the source commit referenced by the generated catalog.

    Frozen registered ID selections

    Batch 3 (22): ascend-aclgraph-capture-replay, ascend-device-health, ascend-distributed-parallel, ascend-graph-mode, ascend-model-adaptation, ascend-operator-profiling, ascend-operator-tuning, ascend-optimization-casebook, ascend-performance-analysis, ascend-video-diffusion-optimization, ascendc-tiling-design, cann-attribution-overlap, cgroup-resource-controls, diagnose-attention-bottlenecks, host-memory-management, host-overhead-optimization, host-overhead-profiling, os-process-placement, reason-hopper-kernels, storage-io-measurement, torchnpu-device-memory-lifecycle, torchnpu-pinned-host-memory-lifecycle.

    Batch 4 (29): audit-afd-p2p-exchanges, audit-flare-session-lifecycle, audit-h3-metal-fasth3-semantics, audit-h3-runtime-residency, audit-llama-runtime-state, audit-recurrent-kv-finalization, audit-sd-cpp-residency, audit-sglang-diffusion-lifetimes, audit-vllm-kv-lifetimes, bound-windowed-attention-replay, budget-speculative-verification, comfy-ui, dcp-async-save-performance, diagnose-vllm-admission-pressure, diffusers-invocation-state, dwarfstar, generation-cache-lifecycle, husky, kv-tier-management, lazy-evaluation-stream-lifetimes, lily, local-dream, mistral-rs, mlc-llm, mlx-swift-lm, project-maya, splash, vllm-metal, lithos-metal.

    Batch 5 (15): ascend-video-diffusion-optimization, audit-fixed-workload-claim, audit-recurrent-kv-finalization, cite-check-downstream-pr, competitor-scan, draft-acceptance-issue, dwarfstar, husky, inference-benchmark-design, lily, npu-skill-factory, repository-evolution-analysis, skill-evolution-playbook, splash, video-diffusion-optimization.

    Acting author/integrator: Codex, user-confirmed gpt-6-astra / xhigh; parallel contributors use the same explicitly selected model/effort. Delivery checks are software/source evidence; independent acceptance is not claimed.
17. Dong1017

    added a commit that references this issue on Oct 31, 2026

    docs: complete applicability metadata for 17 methods skills (#263)

    ...

    ac4c54b
18. Dong1017 commented on Nov 1, 2026

    

    Dong1017

    on Nov 1, 2026 – with ChatGPT Codex Connector

    CollaboratorAuthor

    More actions

    The existing Batch 3–5 integrator remains the coordination owner. The next integration needs to preserve the newly merged FlexGen source slice #288, alongside earlier deliveries; #282/#283/#285 currently conflict with main.

    • Start with feat: distinguish resource-layer exclusions and unresolved coverage #282's canonical-source integration, then regenerate shared projections from a reachable source commit under the existing protocol. Avoid resolving generated JSON by selecting one side and losing other source additions.
    • Its earlier scoped review does not cover the new integrated head; retain fresh generator checks and Ready evidence for independent review.
    • docs: describe conditions and advice for 22 hardware skills #283 still needs review of its newer integration, and docs: describe conditions and advice for 29 repository and framework skills #285 retains the MLX discovery regression-test finding. Integrate siblings without duplicating the shared projection work.

    No new scope, reassignment or efficacy acceptance is introduced by this integration update.
19. zengchuang-hw

    assigned

    Dong1017

    on Nov 3, 2026
20. agent-ci-infra-bot commented on Nov 3, 2026

    

    agent-ci-infra-botBot

    on Nov 3, 2026 – with agent-CI-Infra-bot

    More actions

    The reporter maintains #91 as a living SearchSpace distillation tracker and just refreshed its top status block: Batch 3–5 (#282/#283/#285) are now recorded as merged, and the queued faster-cosyvoice source is recorded as a proposed bounded delivery in the still-open #339, with the SkillEval plan unexecuted. I verified the edit against GitHub: the three merge commits match, #339 is open at 881159057101c639504bd16d889c81cb5d514ee1 and does add the dependency-aware TTS playout/source record and matrix rows to the existing inference-benchmark-design owner, and comment 6615860297 is indeed planned/unexecuted with zero comparisons and blocked budget state; "checks in progress" also held at the edit time. Verdict: no code change requested — the refresh itself is accurate, but two retained sections still contradict merged PR state.

    F1 — Batch 2 is recorded as both merged and still open in the same body

    • Where: ## Current decisions and bounded delivery — 2026-10-30 section: “Current outcome: Recover historical MindSpeed provenance and allocator prerequisites #257's bounded source slice is merged; docs: complete applicability metadata for 17 methods skills #263 remains open with the findings below.”, the bullet “Batch 2 partial PR remains open: [docs: complete applicability metadata for 17 methods skills #263]…” and “docs: complete applicability metadata for 17 methods skills #263 remains the existing author's next unresolved partial delivery.”
    • Problem: docs: complete applicability metadata for 17 methods skills #263 actually merged on 2026-10-31 as ac4c54bc06d44e11b067f5efb92de93c17dc4312, and its final review (pullrequestreview-5721673228) cleared the P2 source-snapshot provenance finding and the P2 unsupported-variant finding. The body already says the opposite of itself elsewhere, in the backlog deduplication paragraph: “The former docs: complete applicability metadata for 17 methods skills #263 partial delivery and foundation slices docs: qualify Sarathi chunked-prefill budget case #277/docs: retain DistServe topology-constrained phase planning #278/docs: add Mooncake prefix reuse feasibility reference #279 are now merged”. The refreshed top block jumps from Batch 1 to Batch 3–5 and never records Batch 2 landing.
    • Impact: The tracker's stated purpose is “what has been extracted, where it lives, what remains missing”. As written, a reader takes Batch 2's 17 sidecars to be an open, unreviewed PR with live P2 findings, and may re-review or re-integrate work already in main — exactly the duplicate-slice risk the body warns about.
    • Fix: Record docs: complete applicability metadata for 17 methods skills #263 as merged with its merge commit in the 2026-10-30 section (and in the new top block as the Batch 2 delivery), and mark the two P2 records as cleared rather than “unresolved review records”; keep the historical snapshot text but stop asserting present-tense “remains open”.

    ---

    F2 — Dated delta table still lists merged or closed PRs as open

    • Where: the ## Current delivery and consolidation delta — 2026-10-27 table and the paragraph under it.
    • Problem: several states are now wrong: #138 is listed as “multi-pin navigation proposed, not merged” but merged; the “bounded additions/extensions proposed, not merged” row names Lithos knowledge: add source-grounded Lithos Metal candidate skills #117, RLT feat: distill recurrent KV finalization and retirement #121 and SD.cpp loader feat: distill diffusion loader and storage boundaries #122, all of which merged; and “knowledge: add bottleneck-driven mechanism decision cases #133 and docs: guide stalled optimization from whole-system bottlenecks #156 are overlapping open proposals under [RFC] Bottleneck-driven optimization: scheduling, caching, and parallelism/pipelining #131” — both are now closed unmerged. The body's own Next action (“check current claims before starting another overlapping slice”) depends on these rows being current.
    • Impact: Anyone using the table to pick the next non-overlapping slice will treat already-landed coverage as pending and closed proposals as claimable. The section is explicitly dated 2026-10-27, which limits the harm, but the merged/open column is read as present state.
    • Fix: Add a one-line status refresh to the affected rows (merged commit / closed unmerged) or mark the table header as superseded, without rewriting the historical records.

    Reviewed commit: 663f3b3
    Coverage: Checkout: 2645 files at 663f3b3 in a git worktree with the repository's history
21. agent-ci-infra-bot

    added

    bot-reviewed

    on Nov 3, 2026
22. agent-ci-infra-bot commented on Nov 3, 2026

    

    agent-ci-infra-botBot

    on Nov 3, 2026 – with agent-CI-Infra-bot

    More actions

    The edit refreshes the tracker's status paragraph: #282/#283/#285 are merged, #339 is the open bounded faster-cosyvoice proposal at head 8811590, and the Codex review summary now reports completed with no findings while security review, SkillEval and efficacy remain unestablished. Those new claims check out against the GitHub API (merge SHAs, #339 head/state, review payload, SkillEval plan comment), and no code change or decision is requested. Verdict: no code change requested — remaining problems are stale statements elsewhere in the same tracker body, not the #339 status text.

    F1 — tracker body still describes merged Batch 2 (#263) as an open partial PR

    • Where: Issue body, section "Current decisions and bounded delivery — 2026-10-30", the #263 bullets plus the section's "Current outcome" sentence.
    • Problem: the text reads "docs: complete applicability metadata for 17 methods skills #263 remains open with the findings below", "Batch 2 partial PR remains open … proposes 15 of the 17 selected method sidecars … this is not full Batch 2 delivery", "the existing author must make the canonical snapshot reachable …", and names docs: complete applicability metadata for 17 methods skills #263 "the existing author's next unresolved partial delivery". Verified instead: PR docs: complete applicability metadata for 17 methods skills #263 merged on 2026-10-31T06:42Z as ac4c54bc06d44e11b067f5efb92de93c17dc4312 ("docs: complete applicability metadata for 17 methods skills"); that commit is in this checkout, and the merged sidecars carry the six applicability keys, e.g. src/inferrsi/data/skill_library/methods/assess-serving-preemption/metadata.json (scope, prerequisites, input_contract, produced_artifact, failure_modes, refusal_point). The same block also still calls feat: distinguish resource-layer exclusions and unresolved coverage #282/docs: describe conditions and advice for 22 hardware skills #283/docs: describe conditions and advice for 29 repository and framework skills #285 "active metadata slices" and "open-PR" status, which this very edit supersedes.
    • Impact: the update's purpose is to stop readers acting on superseded PR state, but Batch 2 is still presented as unlanded and as carrying an unresolved P2 provenance finding. Anyone following the block's own instruction ("check current claims before starting another overlapping slice") can re-open or duplicate Batch 2, or treat delivered sidecars as unowned.
    • Fix: replace the #263 bullets with the merged record (PR docs: complete applicability metadata for 17 methods skills #263, merge ac4c54bc, all 17 selected methods sidecars, no validation/status change) and state the disposition of the P2 provenance item and the two former deferrals at merge; reword the feat: distinguish resource-layer exclusions and unresolved coverage #282/docs: describe conditions and advice for 22 hardware skills #283/docs: describe conditions and advice for 29 repository and framework skills #285 references from "active" to merged. Note that the current generated index points at a different snapshot (7aa3344b… in src/inferrsi/data/repo_packs/inferrsi/knowledge/README.md), so the old 058fc76b… provenance item can be recorded as superseded rather than left as an open reviewer obligation.

    ---

    F2 — the queued faster-cosyvoice row does not record the #339 proposal the status paragraph announces

    • Where: Issue body, research-distillation-backlog block, row [faster-cosyvoice](…/tree/f1049c59…) under "Next: runtime and workload contracts".
    • Problem: the row still lists only the queue text ("PCM-playout/deadline scheduling, dependent-chunk batching, TTFP/underrun/quality and full-pipeline costs. Resolve licensing before copying code…") with no proposal link, while the new status paragraph says the source "now has a proposed bounded delivery in Add source-bound TTS playout benchmark guidance #339". Verified: Add source-bound TTS playout benchmark guidance #339 modifies src/inferrsi/data/skill_library/methods/inference-benchmark-design/{SKILL.md,metadata.json} plus references/dependency-aware-tts-playout.md and references/faster-cosyvoice-source.json, i.e. it is exactly the row's work unit at the same upstream pin. Every other queued row that has a delivery records it inline ("Bounded source delivery: [knowledge: distill JustGoal controlled evaluation contracts #302] merged as …"), and the delta table records open proposals (e.g. feat: distill diffusion loader and storage boundaries #122, knowledge: add source-grounded Lithos Metal candidate skills #117), so the omission is inconsistent with the block's own convention.
    • Impact: the row is the navigation entry a contributor checks before claiming a slice; without the proposal it looks like an unclaimed task, which is how an overlapping delivery against the same pin gets started — the outcome the next-action line asks readers to avoid.
    • Fix: append to the faster-cosyvoice row something like "Proposed, not merged: Add source-bound TTS playout benchmark guidance #339 (head 8811590), extending inference-benchmark-design; licensing/rights remain UNKNOWN and efficacy not_evaluated", keeping the row unchecked.

    ---

    F3 — "hosted full checks are still in progress" is no longer true at head 8811590

    • Where: Issue body, first paragraph: "current-head hosted full checks are still in progress at this snapshot".
    • Problem: at edit time (2026-11-03T21:32:13Z) that was accurate, since full-check (3.10) finished at 21:32:19Z. At review time all 10 check runs on 881159057101c639504bd16d889c81cb5d514ee1 are completed — full-check (3.10), full-check (3.11), installed-package (3.10/3.11), declarations, kv-task-qualification, pr-references, plan, publish all success, execute skipped — and the knowledge-model-policy commit status is success. Nothing is pending.
    • Impact: a living tracker's status line sends readers to wait for evidence that already exists, and under-reports what is available (while the adjacent caveat correctly keeps it separate from approval or efficacy).
    • Fix: change the clause to record the completed successful hosted checks at head 8811590, keeping "that is not formal approval, source/efficacy acceptance or a completed security review".

    Reviewed commit: 663f3b3
    Coverage: Checkout: 2645 files at 663f3b3 in a git worktree with the repository's history
23. agent-ci-infra-bot commented on Nov 3, 2026

    

    agent-ci-infra-botBot

    on Nov 3, 2026 – with agent-CI-Infra-bot

    More actions

    Intent: the reporter maintains #91 as a living SearchSpace distillation tracker and refreshed its status block to record Batch 3–5 (#282/#283/#285) as merged, #339 as the open bounded faster-cosyvoice proposal, and the now-completed current-head checks and reviews. I verified the refreshed claims against GitHub and the checkout: the merge SHAs, #339 head 8811590 and its touched owner files, the six Ready-lane jobs on that head (all success), the Codex "completed, no findings" summary and the independent bot review all match the new text, so that edit is accurate and the earlier "checks still in progress" finding is fixed. Verdict: no code change requested — three older tracker records still present merged or closed PRs as pending.

    F1 — merged Batch 2 (#263) is still recorded as open, unreviewed and "the next unresolved partial delivery" (earlier finding, still open)

    • Where: Issue body, section ## Current decisions and bounded delivery — 2026-10-30: the sentence "Current outcome: Recover historical MindSpeed provenance and allocator prerequisites #257's bounded source slice is merged; docs: complete applicability metadata for 17 methods skills #263 remains open with the findings below."; the bullet "Batch 2 partial PR remains open: [docs: complete applicability metadata for 17 methods skills #263]…" (claims "proposes 15 of the 17 selected method sidecars", "this is not full Batch 2 delivery", "the existing author must make the canonical snapshot reachable …", "These are unresolved review records"); and "docs: complete applicability metadata for 17 methods skills #263 remains the existing author's next unresolved partial delivery." The deduplication paragraph also still says "Preserve the active metadata slices feat: distinguish resource-layer exclusions and unresolved coverage #282/docs: describe conditions and advice for 22 hardware skills #283/docs: describe conditions and advice for 29 repository and framework skills #285", which the new status block has just declared merged.
    • Problem: docs: complete applicability metadata for 17 methods skills #263 merged on 2026-10-31T06:42Z as ac4c54bc06d44e11b067f5efb92de93c17dc4312, and that commit is in this checkout (git log ac4c54bc resolves). Its final scoped review (pullrequestreview-5721673228) records no remaining blocker and clears the earlier P2 items. All 17 selected methods/ sidecars now carry the six typed keys, e.g. src/inferrsi/data/skill_library/methods/assess-serving-preemption/metadata.json (applicability.scope … refusal_point); I counted 20/20 methods/ sidecars with a non-empty applicability. The refreshed status block jumps from Batch 1 to Batch 3–5 and never records Batch 2 landing.
    • Impact: The tracker's stated job is "what has been extracted, where it lives, what remains missing", and its own next action says to "check current claims before starting another overlapping slice". As written, a reader treats 17 landed sidecars as an open PR with live P2 provenance findings and can re-review or re-integrate delivered work.
    • Fix: Record docs: complete applicability metadata for 17 methods skills #263 as merged with ac4c54bc, note the P2 items were cleared and that all 17 selected sidecars landed with no verification/status/empirical_validation promotion; replace "Preserve the active metadata slices feat: distinguish resource-layer exclusions and unresolved coverage #282/docs: describe conditions and advice for 22 hardware skills #283/docs: describe conditions and advice for 29 repository and framework skills #285" with their merged record; drop the present-tense "remains open" / "next unresolved partial delivery" phrasing while keeping the dated history.

    Reviewed commit: 663f3b327998526a13aa31e72ad729025c18983c
    

    ---

    F2 — the queued faster-cosyvoice row still omits the #339 proposal that the refreshed status block announces (earlier finding, still open)

    • Where: Issue body, research-distillation-backlog block, row [faster-cosyvoice](…/tree/f1049c59…) under "Next: runtime and workload contracts".
    • Problem: The row still carries only the queue text ("PCM-playout/deadline scheduling, dependent-chunk batching, TTFP/underrun/quality and full-pipeline costs. Resolve licensing before copying code…") and no proposal link, while the new status block states the source "now has a proposed bounded delivery in Add source-bound TTS playout benchmark guidance #339". Verified that Add source-bound TTS playout benchmark guidance #339 is that work unit at the same pin: it modifies src/inferrsi/data/skill_library/methods/inference-benchmark-design/{SKILL.md,metadata.json}, adds references/dependency-aware-tts-playout.md and references/faster-cosyvoice-source.json (source commit f1049c59196c2c1a890079abc56056b43f27cd1d, rights.repository_license: UNKNOWN), plus matrix and regenerated projection updates. Every other queued row with a delivery records it inline ("Bounded source delivery: [knowledge: distill JustGoal controlled evaluation contracts #302] merged as …"), and the delta table records open proposals, so the omission is inconsistent with the block's own convention.
    • Impact: The row is the navigation entry a contributor checks before claiming a slice; without the proposal it reads as unclaimed, which is exactly how overlapping work against the same pin starts — the outcome the status block's next action asks readers to avoid.
    • Fix: Append to the faster-cosyvoice row, e.g. "Proposed, not merged: [Add source-bound TTS playout benchmark guidance #339] (head 8811590), extending inference-benchmark-design; licensing/rights UNKNOWN and efficacy not_evaluated", keeping the row unchecked and the licensing caveat intact.

    ---

    F3 — the 2026-10-27 delta table still lists merged or closed proposals as pending (earlier finding from the previous review, still open)

    • Where: Issue body, ## Current delivery and consolidation delta — 2026-10-27 table and the paragraph after it: rows "Multi-pin navigation proposed, not merged | vLLM docs: route vLLM engine, admission and KV knowledge #138" and "Bounded additions/extensions proposed, not merged | RLT feat: distill recurrent KV finalization and retirement #121; SD.cpp loader feat: distill diffusion loader and storage boundaries #122; Lithos knowledge: add source-grounded Lithos Metal candidate skills #117 via knowledge: distill lithos-metal into source-grounded candidate skills #115"; the sentence "knowledge: add bottleneck-driven mechanism decision cases #133 and docs: guide stalled optimization from whole-system bottlenecks #156 are overlapping open proposals under [RFC] Bottleneck-driven optimization: scheduling, caching, and parallelism/pipelining #131"; and the affected source rows "Repo · InferMatrixLab/vllm-rlt … recurrent KV candidate submitted in open feat: distill recurrent KV finalization and retirement #121, not yet merged" and "Repo · stable-diffusion.cpp … loader/storage extension submitted in open feat: distill diffusion loader and storage boundaries #122; not yet main coverage".
    • Problem: Each state is now wrong: docs: route vLLM engine, admission and KV knowledge #138 merged 2026-10-28 as f5bb4a109ba175d428b8329046719ba479880338; feat: distill recurrent KV finalization and retirement #121 merged as cac287f62375c643254af850fd294b4bdc21cb86, feat: distill diffusion loader and storage boundaries #122 as 25d6d5a603824e3893415841e1709521cd0eeb04, knowledge: add source-grounded Lithos Metal candidate skills #117 as ab03f3ffb8f2e5bc02c304828c5c41890eef673e; knowledge: add bottleneck-driven mechanism decision cases #133 and docs: guide stalled optimization from whole-system bottlenecks #156 are closed unmerged.
    • Impact: A reader picking the next non-overlapping slice treats landed coverage as pending and closed proposals as claimable. The section header is dated, which limits the harm, but the merged/open column is read as present state and sits beside the updated status block.
    • Fix: Add a one-line status refresh to the affected rows (merge commit / closed unmerged), or mark the table header as superseded by the current status block, without rewriting the historical record.

    Reviewed commit: 663f3b3
    Coverage: Checkout: 2645 files at 663f3b3 in a git worktree with the repository's history
24. agent-ci-infra-bot commented on Nov 3, 2026

    

    agent-ci-infra-botBot

    on Nov 3, 2026 – with agent-CI-Infra-bot

    More actions

    The maintainer refreshed the living SearchSpace distillation tracker to record Batch 2 (#263) and the older PRs as merged/closed and to mark the dated 2026-10-27 and 2026-10-30 sections as superseded; I verified the merge SHAs (ac4c54bc for #263, f5bb4a10, cac287f6, 25d6d5a6, ab03f3ff), the unmerged closures of #133/#156, and #339's open head 8811590 against GitHub and the checkout. Verdict: no code change requested — the new status block is accurate, but two live records still contradict it. F1 (merged Batch 2 shown as open): fixed — the top block now records #263 merged as ac4c54bc and declares the dated sections historical. F2 (faster-cosyvoice row omits #339): still open. F3 (10-27 delta table lists merged/closed PRs as pending): partially fixed — the 10-27 table is now covered by the supersession notice, but the 2026-10-22 inventory rows remain uncovered.

    F2 — the queued faster-cosyvoice row still omits the #339 proposal that the refreshed status block announces (earlier finding, still open)

    • Where: Issue body, live research-distillation-backlog block (2026-11-01), row [faster-cosyvoice](…/tree/f1049c59…) at body line 21, under "Next: runtime and workload contracts".
    • Problem: the row carries only the queue text — "PCM-playout/deadline scheduling, dependent-chunk batching, TTFP/underrun/quality and full-pipeline costs. Resolve licensing before copying code; retain voice-quality and repeatability gaps." — with no proposal link, while the new first paragraph says the source "now has a proposed bounded delivery in [Add source-bound TTS playout benchmark guidance #339]". Verified: Add source-bound TTS playout benchmark guidance #339 is open at head 881159057101c639504bd16d889c81cb5d514ee1 and is exactly this work unit at the same pin — it modifies src/inferrsi/data/skill_library/methods/inference-benchmark-design/{SKILL.md,metadata.json}, adds references/dependency-aware-tts-playout.md and references/faster-cosyvoice-source.json whose readset pins commit f1049c59196c2c1a890079abc56056b43f27cd1d, status: candidate, efficacy: not_evaluated, rights.repository_license: UNKNOWN. Every other queued row that has a delivery records it inline ("Bounded source delivery: [knowledge: distill JustGoal controlled evaluation contracts #302] merged as …", knowledge: distill AutoTuneBench treatment and trial validity #306, docs: add cache-aware ASR stream-boundary reference #301), so the omission is inconsistent with the block's own convention.
    • Conditions: a contributor reads the backlog block (the navigation entry checked before claiming a slice) without scrolling to the status paragraph.
    • Impact: the row reads as unclaimed work, which is how an overlapping delivery against the same pin gets started — the outcome the status block's own next action ("check current claims before starting another overlapping slice") asks readers to avoid.
    • Fix: append to the row something like "Proposed, not merged: Add source-bound TTS playout benchmark guidance #339 (head 8811590), extending inference-benchmark-design; licensing/rights UNKNOWN and efficacy not_evaluated", keeping the checkbox unchecked and the licensing caveat intact.

    ---

    F3 — two rows of the 2026-10-22 inventory still assert merged PRs are open, outside the new supersession notice (earlier finding, partially fixed)

    • Where: Issue body, section ## 1. Accelerator row at body line 146 — "Repo · InferMatrixLab/vllm-rlt … recurrent KV candidate submitted in open feat: distill recurrent KV finalization and retirement #121, not yet merged" — and section ## 3. SSD / Storage row at body line 208 — "Repo · stable-diffusion.cpp … loader/storage extension submitted in open feat: distill diffusion loader and storage boundaries #122; not yet main coverage".
    • Problem: both PRs merged (feat: distill recurrent KV finalization and retirement #121 as cac287f6, feat: distill diffusion loader and storage boundaries #122 as 25d6d5a6, both 2026-10-28) and the commits are in this checkout, but these rows still present them as open. The new first paragraph declares only "the dated 2026-10-27 and 2026-10-30 sections below … historical snapshots" as superseded; the 2026-10-22 inventory tables these rows live in are not covered by that notice, so they are still read as present state. The 2026-10-27 delta table that the earlier finding also named is now adequately covered.
    • Impact: the same failure mode the tracker's next action guards against — a reader picking the next non-overlapping slice treats landed recurrent-KV and SD.cpp loader coverage as pending and claimable.
    • Fix: add a one-line status refresh to these two rows ("merged as cac287f6 / 25d6d5a6") or widen the top-block supersession notice to state that all pre-2026-11 dated inventories are historical, without rewriting the recorded history.

    Reviewed commit: 663f3b3
    Coverage: Checkout: 2645 files at 663f3b3 in a git worktree with the repository's history
25. agent-ci-infra-bot commented on Nov 3, 2026

    

    agent-ci-infra-botBot

    on Nov 3, 2026 – with agent-CI-Infra-bot

    More actions

    Intent: the maintainer maintains #91 as a living SearchSpace distillation tracker and refreshed its status block to record a later source review on the still-open #339. I verified the new text against GitHub and the checkout: review 5760900838 exists at head 8811590, is COMMENTED, and itself states the quoted numbers (33 upstream files, 117-entry tree, 87 changed paths, 12 owner-resource hashes); the six Ready jobs in run 41721795418 are success at that head, the Codex summary is completed with no findings, and the SkillEval comment shows 0 comparisons with blocked/unknown budget, so the refresh is accurate. Verdict: no code change requested — F1 (Batch 2 recorded as open) stays fixed, while F2 and F3 remain open in the same body, plus one new attribution note about the source review the edit records.

    F2 — the live faster-cosyvoice queue row still omits the #339 proposal the status block announces (earlier finding, still open)

    • Where: Issue body, live research-distillation-backlog block (2026-11-01), row [faster-cosyvoice](…/tree/f1049c59…), body line 21.
    • Problem: the row still carries only the queue text ("PCM-playout/deadline scheduling, dependent-chunk batching, TTFP/underrun/quality and full-pipeline costs. Resolve licensing before copying code…") with no proposal link, while line 1 says the source "now has a proposed bounded delivery in Add source-bound TTS playout benchmark guidance #339". Verified: Add source-bound TTS playout benchmark guidance #339 is open at 881159057101c639504bd16d889c81cb5d514ee1 and is exactly this work unit at the same pin — it changes inference-benchmark-design/{SKILL.md,metadata.json}, adds references/dependency-aware-tts-playout.md and references/faster-cosyvoice-source.json (pinning f1049c59), 87 paths in total. Every other queued row with a delivery records it inline ("Bounded source delivery: [knowledge: distill JustGoal controlled evaluation contracts #302] merged as …", knowledge: distill AutoTuneBench treatment and trial validity #306, docs: add cache-aware ASR stream-boundary reference #301), so the omission is inconsistent with the block's own convention.
    • Impact: the row is the navigation entry a contributor checks before claiming a slice; without the proposal it reads as unclaimed, which is how overlapping work against the same pin starts — the outcome the status block's next action asks readers to avoid.
    • Fix: append to the row, e.g. "Proposed, not merged: Add source-bound TTS playout benchmark guidance #339 (head 8811590), extending inference-benchmark-design; licensing/rights UNKNOWN and efficacy not_evaluated", keeping the checkbox unchecked and the licensing caveat intact.

    ---

    F3 — 2026-10-22 inventory rows and the backlog dedup sentence still present merged or closed PRs as pending (earlier finding, still open)

    • Where: Issue body: line 146 vllm-rlt row ("recurrent KV candidate submitted in open feat: distill recurrent KV finalization and retirement #121, not yet merged"); line 208 stable-diffusion.cpp row ("loader/storage extension submitted in open feat: distill diffusion loader and storage boundaries #122; not yet main coverage"); line 119 vLLM row ("navigation proposed in open [docs: route vLLM engine, admission and KV knowledge #138] … Not yet main delivery"); line 147 PagedAttention row ("New bounded slices in open docs: guide stalled optimization from whole-system bottlenecks #156 under [RFC] Bottleneck-driven optimization: scheduling, caching, and parallelism/pipelining #131 are not merged"); line 34 backlog dedup sentence ("Preserve the active metadata slices feat: distinguish resource-layer exclusions and unresolved coverage #282/docs: describe conditions and advice for 22 hardware skills #283/docs: describe conditions and advice for 29 repository and framework skills #285").
    • Problem: all of these states are now wrong and none is covered by the new supersession notice, which names only the dated 2026-10-27 and 2026-10-30 sections. Verified via the GitHub API and the checkout: feat: distill recurrent KV finalization and retirement #121 merged as cac287f6, feat: distill diffusion loader and storage boundaries #122 as 25d6d5a6, docs: route vLLM engine, admission and KV knowledge #138 as f5bb4a10, knowledge: add source-grounded Lithos Metal candidate skills #117 as ab03f3ff, feat: distinguish resource-layer exclusions and unresolved coverage #282/docs: describe conditions and advice for 22 hardware skills #283/docs: describe conditions and advice for 29 repository and framework skills #285 as 1fca842a/ebdbf5af/5d16e522 (all commits present in this worktree), while docs: guide stalled optimization from whole-system bottlenecks #156 is closed unmerged (and knowledge: add bottleneck-driven mechanism decision cases #133 likewise), so "open" is wrong there too.
    • Impact: the tracker's stated job is "what has been extracted, where it lives, what remains missing", and its own next action says to check current claims before starting another overlapping slice. As written, readers treat landed coverage as pending and closed proposals as claimable, and the dedup sentence still asks contributors to "preserve" slices the top block has just declared merged.
    • Fix: add a one-line status refresh to these rows (merge commit / closed unmerged) and reword line 34 to "feat: distinguish resource-layer exclusions and unresolved coverage #282/docs: describe conditions and advice for 22 hardware skills #283/docs: describe conditions and advice for 29 repository and framework skills #285 are merged (1fca842a, ebdbf5af, 5d16e522)", or widen the top-block notice so it covers all pre-2026-11 dated inventories — without rewriting the recorded history.

    ---

    F4 — the newly recorded source review is the owner's own COMMENTED self-review, not independent verification

    • Where: Issue body, line 1, the new sentence "The later current-head source review reports source-only LGTM after independently fetching all 33 recorded upstream files …", next to "The current-head independent bot review …".
    • Problem: review 5760900838 is authored by Dong1017 — the tracker owner and the author of the knowledge change under review — with state COMMENTED at head 8811590. The body reproduces the review's evidence faithfully (I confirmed the review text, head, 87 changed paths and the inference-benchmark-design files), but it labels only the bot item "independent"; the self-review's evidence is presented as a separate corroborating check without saying who wrote it.
    • Impact: readers comparing the two adjacent sentences can take the second as independently verified source evidence for the same claim, which is the same over-claiming the surrounding sentences carefully avoid for checks, SkillEval and efficacy.
    • Fix: name the authorship in that sentence, e.g. "the owner's later COMMENTED source self-review reports …", keeping the existing "not formal APPROVE, merge authorization or broader goal acceptance" caveat.

    Reviewed commit: 663f3b3
    Coverage: Checkout: 2645 files at 663f3b3 in a git worktree with the repository's history