원클릭으로 Manus에서 모든 스킬 실행

freed-canary

스타7

포크1

업데이트2026년 7월 13일 20:41

Judge an installed Freed Desktop build against comparable historical runtime windows. Use after a release has run long enough, when a soak looks worse than usual, or when deciding whether a metric regressed. Require event-derived build identity, immutable time bounds, healthy evidence sources, matching workload cohorts, and at least three comparable baselines before declaring a regression.

설치

Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.

Manus에서 실행

출처

freed-project

freed-project/freed

GitHub 저장소 열기 Creator 저장소 보기

다운로드

Manus에서 실행

Canary

Judge a build from attributable evidence. The installed version observed at report time is not proof of which build produced an earlier sample.

Workflow

Record the task ID and allowed authority. Observation may be automatic. Committing a ledger record, opening a PR, or starting a bisect requires the corresponding authority.
Select an immutable window whose events identify one app version, channel, git SHA, app session, collector session, and app PID. Split windows at releases, relaunches, sleep transitions, and process-generation changes where the metric requires it.
Check source health, parse failures, sample gaps, app-alive coverage, network state, scenario, and document-size bucket. Return an analytical inconclusive result when required identity or coverage is missing, and preserve it even when it cannot become a task lifecycle outcome.
Build canary-context.json from the finished soak with node scripts/canary-context.mjs --verdict <soak-dir>/soak-verdict.json --install-id <id> --installed-at <iso>. The helper rebuilds the stored soak before copying build, runtime, workload, host, source coverage, cloud duration, and optional artifact digest. Caller workload or host values may only assert an exact match. They cannot relabel the window.
Run node scripts/canary-summarize.mjs --context <canary-context.json> --collector-metrics <soak-dir>/metrics.tsv. The context owns the exact start and end bounds. The summarizer hashes and copies runtime-health JSONL, collector-metrics TSV, and the ordered bounded collector-events JSONL into the ledger. By default it reads the rotated collector-events archive before the live file. Do not attribute an arbitrary trailing window to the currently installed version or a manually supplied version label.
Compare only cohorts with compatible operating system, RAM tier, document-size bucket, provider state, workload, and process-generation semantics. Every lifecycle window requires at least six credited app-alive hours. A baseline's credited app-alive duration must be between 0.8 and 1.25 times the current credited duration, inclusive. Use wall bounds only for ordering and overlap.
Require at least three comparable historical windows before an automatic regression verdict. With fewer, record the current observation as a provisional baseline and return inconclusive.
Judge each metric through the versioned metric registry. Use app-alive time for runtime rates and verified cloud-eligible time for cloud rates. A missing denominator makes that metric unavailable. Worker-init outcomes automatically carry the registered p95 app-memory-pressure guardrail.
Preserve every observation window. Records and raw sidecars are content addressed and published atomically. Reuse an existing path only when its bytes are identical. Changed evidence must create a new bundle and must never overwrite history.
If authorized, publish the ledger record and all three evidence sidecars through a small PR to dev. Include the exact build identity, time bounds, cohort definition, coverage, and verdict. The JSON and sidecars are one portable provenance bundle.
If a metric regressed, create a plan-only bisect with scripts/bisect-regression.mjs. Do not execute bisection until a harness can build each commit, install it, verify the installed SHA, collect an isolated window, and restore the prior app.
Map a confirmed regression to one stable task ID. A provisional or inconclusive signal does not authorize product changes.
Record a task verification outcome only when its canonical task is in soaking. Convert the exact JSON canary record with build-outcome-verdict.mjs --canary-verdict. For a measured outcome, name one registered canary metric. The converter derives the before and after values, unit, direction, limit, and tolerance from the canary comparison and checked-in registry, then hashes the source record. A canary pass can prove verified_neutral, not verified_effective. Pass only that generated outcome verdict to record-outcome.mjs. Its build, evidence window, source health, and composite fingerprint must match the canonical installed task. Record a lifecycle inconclusive only for a nonempty, attributable, build-bound canary window with a complete fingerprint. Missing or mixed identity and empty evidence remain analytical results. Keep the task in soaking and repair the evidence path instead of inventing attribution.

Required output

Report the metric table, evidence quality, comparable baseline count, build identity, immutable window, and the canary comparison status: pass, regression, or inconclusive. Every conclusion must cite the raw evidence or ledger record that supports it. A canary pass proves only that the window did not regress against its matched baselines. It does not prove a task was effective. Record task outcomes separately as verified_effective, verified_neutral, regressed, or recordable inconclusive only when task-specific, build-bound evidence satisfies the lifecycle contract.

이 저장소의 다른 Skills

같은 저장소

freed-build-feature

freed-project/freed

Build governed Freed product work in a worktree based on origin/dev, verify the runnable slice, and publish a correctly staged pull request to dev. Use for Desktop, PWA, shared packages, sync, capture, release tooling, product behavior, and product documentation. Also use for stability tasks that require a stable task identity, a measurable counter, native validation, or an installed-build verification handoff. Do not use for public website work targeting www.

2026-07-247

freed-ship-build

freed-project/freed

Ship and verify a versioned Freed Desktop build through GitHub Actions. Use when asked to cut a dev or production release, publish a reviewed build, or repair a failed release pipeline. Preserve source and installed build identity, require exact-head validation including native tests, and create a governed post-install verification task.

2026-07-247

freed-stability-controller

freed-project/freed

Reconcile Freed stability observations, tasks, approvals, releases, soaks, and outcomes into one governed lifecycle. Use when coordinating the continuous background agents, deduplicating repeated findings, selecting the next stability action, advancing task state, or deciding that no fresh actionable work exists. This skill coordinates authority and handoffs but does not implement product code.

2026-07-247

freed-triage

freed-project/freed

Reconcile fresh Freed stability evidence into governed, deduplicated GitHub debt issues. Use after runtime alarms, soak verdicts, canary results, or CI failures, and when deciding what to fix next. Require healthy evidence sources, temporal and build matching, issue identity, atomic evidence generations, explicit authority, and instrumentation-first handling of contradictory metrics.

2026-07-247

freed-soak

freed-project/freed

Run and judge an installed-build soak of Freed Desktop from terminal evidence. Use for release observation, overnight stability windows, or post-change verification. Require the canonical release-verifier lease, the exclusive collector session lock, event-derived build identity, immutable time bounds, source-health checks, comparable process generations, and explicit inconclusive results when identity or coverage is insufficient.

2026-07-227

freed-provider-risk-review

freed-project/freed

Prepare and verify both owner gates for any Freed change that could alter behavior visible to X, Facebook, Instagram, LinkedIn, or another provider. Use before implementation that changes WebView loads, navigation, requests, retries, cadence, cookies, headers, scrolling, clicking, extraction scripts, media loading, login behavior, or provider timing, and again before making the pull request ready. Preparing a review never grants approval.

2026-07-167

name	freed-canary
description	Judge an installed Freed Desktop build against comparable historical runtime windows. Use after a release has run long enough, when a soak looks worse than usual, or when deciding whether a metric regressed. Require event-derived build identity, immutable time bounds, healthy evidence sources, matching workload cohorts, and at least three comparable baselines before declaring a regression.
disable-model-invocation	true

Canary

Judge a build from attributable evidence. The installed version observed at report time is not proof of which build produced an earlier sample.

Workflow

Record the task ID and allowed authority. Observation may be automatic. Committing a ledger record, opening a PR, or starting a bisect requires the corresponding authority.
Select an immutable window whose events identify one app version, channel, git SHA, app session, collector session, and app PID. Split windows at releases, relaunches, sleep transitions, and process-generation changes where the metric requires it.
Check source health, parse failures, sample gaps, app-alive coverage, network state, scenario, and document-size bucket. Return an analytical inconclusive result when required identity or coverage is missing, and preserve it even when it cannot become a task lifecycle outcome.
Build canary-context.json from the finished soak with node scripts/canary-context.mjs --verdict <soak-dir>/soak-verdict.json --install-id <id> --installed-at <iso>. The helper rebuilds the stored soak before copying build, runtime, workload, host, source coverage, cloud duration, and optional artifact digest. Caller workload or host values may only assert an exact match. They cannot relabel the window.
Run node scripts/canary-summarize.mjs --context <canary-context.json> --collector-metrics <soak-dir>/metrics.tsv. The context owns the exact start and end bounds. The summarizer hashes and copies runtime-health JSONL, collector-metrics TSV, and the ordered bounded collector-events JSONL into the ledger. By default it reads the rotated collector-events archive before the live file. Do not attribute an arbitrary trailing window to the currently installed version or a manually supplied version label.
Compare only cohorts with compatible operating system, RAM tier, document-size bucket, provider state, workload, and process-generation semantics. Every lifecycle window requires at least six credited app-alive hours. A baseline's credited app-alive duration must be between 0.8 and 1.25 times the current credited duration, inclusive. Use wall bounds only for ordering and overlap.
Require at least three comparable historical windows before an automatic regression verdict. With fewer, record the current observation as a provisional baseline and return inconclusive.
Judge each metric through the versioned metric registry. Use app-alive time for runtime rates and verified cloud-eligible time for cloud rates. A missing denominator makes that metric unavailable. Worker-init outcomes automatically carry the registered p95 app-memory-pressure guardrail.
Preserve every observation window. Records and raw sidecars are content addressed and published atomically. Reuse an existing path only when its bytes are identical. Changed evidence must create a new bundle and must never overwrite history.
If authorized, publish the ledger record and all three evidence sidecars through a small PR to dev. Include the exact build identity, time bounds, cohort definition, coverage, and verdict. The JSON and sidecars are one portable provenance bundle.
If a metric regressed, create a plan-only bisect with scripts/bisect-regression.mjs. Do not execute bisection until a harness can build each commit, install it, verify the installed SHA, collect an isolated window, and restore the prior app.
Map a confirmed regression to one stable task ID. A provisional or inconclusive signal does not authorize product changes.
Record a task verification outcome only when its canonical task is in soaking. Convert the exact JSON canary record with build-outcome-verdict.mjs --canary-verdict. For a measured outcome, name one registered canary metric. The converter derives the before and after values, unit, direction, limit, and tolerance from the canary comparison and checked-in registry, then hashes the source record. A canary pass can prove verified_neutral, not verified_effective. Pass only that generated outcome verdict to record-outcome.mjs. Its build, evidence window, source health, and composite fingerprint must match the canonical installed task. Record a lifecycle inconclusive only for a nonempty, attributable, build-bound canary window with a complete fingerprint. Missing or mixed identity and empty evidence remain analytical results. Keep the task in soaking and repair the evidence path instead of inventing attribution.