Skip to content

template: an existing extension adopts just finish after the update #427

New issue
New issue
Closed
Closed
template: an existing extension adopts just finish after the update#427
Labels
2-type:taskSupporting work such as maintenance, documentation, refactoring, or verification3-pty:p1High priority; takes precedence over ordinary planned work
Milestone
COR-104 verification map

Description

@pascalandy
pascalandy
opened on Nov 2, 2026

This issue is the card COR-104-T10.

Problem

ncly-video-convert uses template v0.23.4. Template v0.25.0 adds just finish to just signoff, and just release needs that signoff. So after an update, video-convert cannot release until just finish passes.

COR-104-T9 solved the first part of this issue. "Adopt just finish" in docs/north-star/contract/update-an-extension.md (lines 34-47) and the template skill say how an existing extension adopts just finish. scripts/template-adoption-test.sh proves it on a rendered extension.

The remaining work is the first real use of the loop on a real extension. The six day-1 trial rounds (#405) never reached "Done when" on a new extension.

Goal

ncly-video-convert releases through the loop on the latest template. The time and the findings of each gate are known.

Before you start

  • Install the latest nicely release on the host that runs the build. On 2026-11-03, om1 ran a development build of 2026-10-28.
  • Read the card COR-104-T10 in docs/backlog/COR-104-verification-map.md.

Acceptance rules

  1. In ncly-video-convert, find the latest published nicely tag with gh release view -R pascalandy/nicely --json tagName. Run just update <tag>, and follow "Adopt just finish".
  2. The first build follows the card COR-104-T10:
    • Its publication proof runs through sdk/verification, and keeps its model, mapping, probes, and expected results.
    • It declares its publications and acceptance cases.
    • Each correction gets a ledger row. A correction of A or B gets the step of D068.
  3. The pull request in ncly-video-convert has a table with one row for each gate: intake, spec, scenario, handler, review, finish, and signoff. Each row gives the time that the gate took and each finding. Each finding says whether it was a real defect.
  4. The pull request gives the session ID of each author and of the reviewer.
  5. Each table names the commit that just signoff signed. After the release, a comment on this issue gives the same table, plus a row for the release and its tag.
  6. A pull request in nicely sets COR-104-T10 to done and links the pull request of ncly-video-convert.

Examples

  • Success: just signoff and just release pass in ncly-video-convert, and the comment gives the time and findings of each gate.
  • Failure: the release passes, but nobody can say how long a gate took or which finding was real.

Check

  • just signoff and just release pass in ncly-video-convert on the latest template.
  • The gate table is in the pull request and in a comment on this issue.
  • COR-104-T10 is done in docs/backlog/COR-104-verification-map.md.

by Opus-5.5 via Claude Code

Activity

  1. pascalandy
    added
    1-needs-triageScope, approach, or direction needs evaluation
    2-type:taskSupporting work such as maintenance, documentation, refactoring, or verification
    on Nov 2, 2026
  2. pascalandy
    added a commit that references this issue on Nov 3, 2026

    📝 docs: plan: map each check to an owner and a level, as COR-104

    f3b29fd
  3. pascalandy
    added a parent issue on Nov 3, 2026
  4. pascalandy
    marked this as blocked on Nov 3, 2026
  5. pascalandy
    added
    1-ready-for-agentValidated work, sufficiently specified for an autonomous agent
    3-pty:p1High priority; takes precedence over ordinary planned work
    and removed
    1-needs-triageScope, approach, or direction needs evaluation
    on Nov 3, 2026
  6. pascalandy
    added this to the COR-104 verification map milestone on Nov 3, 2026

  7. pascalandy commented on Nov 4, 2026

    @pascalandy
    pascalandy
    on Nov 4, 2026
    OwnerAuthor

    COR-104-T10 delivery evidence for ncly-video-convert PR #17. Signed commit: 4ad77bd5e19ddab9d79c3c5d692087a2789c64d2.

    Times are measured intervals on 2026-11-03 and 2026-11-04, America/Montreal. Overlapping work is not counted as serial time. Author: Codex 01a1a2e1-797b-77c3-9f7c-99717bd94a8a. Reviewers: readiness round 1 Codex 01a1a302-b36b-7983-be12-9f3ccc38b45f, independent round 2 Codex 01a1a758-936e-7a61-9988-736f31049c78; every barrage session is in PR #17.

    Gate Time / state Findings and disposition
    Intake 14:31:11–14:32:11, 60 s Sourced adapter/program facts and publication-capability uncertainty. No new defect
    Spec 14:32:11–14:32:58, 47 s Publication/matrix forms were adoption work, not a product defect
    Scenario Initial 14:32:58–14:35:31, 153 s Real: missing pending operation C1, undocumented privacy C2, accepted-limit evaluator A1/#462, and public staging leak A2/#468. Privacy disposition is the declared limit + #18; SDK defects follow D068. C11 records the spec.md truncation in intermediate amended commit 721b3ec (317 bytes). The next amend, 62161e4, restored its sections before the public failure replay; the bad blob and reflog are preserved. The gate counts the failed H-core cleanup case below. Real evidence gap C42 is now corrected: the baseline is H-only; H and installed P are measured separately and each driver is named. The post-update host-floor probe found real owner-A defect A3: old cores leave one stage. Chef 2 filed nicely#484 on the Head Chef’s order; D068 steps 1–2 are the issue and accepted core-minimum limit. Step 3 waits for a future release. Paired post-TERM times: v0.23.0 15.029793 s / 1 stage; v0.26.0 15.028706 s / 1; v0.26.1 13.222759 s / 0. Input and previous output stayed safe
    Handler Initial 14:34:57–14:44:58, 601 s; later corrections validated separately Real regressions: unsupported strip flag C3 and the later timestamp assertion C8, both fixed without a new worker floor. Retention assertion C20 was stronger than CAN-retain and is corrected with paired-toolchain evidence. Model-result duplication and editorial maintenance are not product defects
    Review Prior phase windows 6,566 s; post-update independent round 645.700 s (2026-11-04 11:16:02.573–11:26:48.273) Real findings include ineffective case/orientation readers, missing real checks, incomplete proof recovery, release-doc closure and C20. Fixed readers reject meaningful bad variants. C31 now demonstrates before/after reader-error handling through public acceptance. Three executable outcomes remain explicit as adoption evidence. A default macOS CPU checksum failure was not established and is not counted. All four barrage budgets ended; fixes after their final reports are unconfirmed by those SOPs. The reader fix has its own measured negative control. Independent round 2 at 1c8e0e8 finds no new defect: five fixed findings and R1-F3/R1-F4 under the accepted privacy limit; records-only cherry-pick is 4ad77bd
    Finish First independent run 0.35 s, exit 1; round-2 independent pass 0.152 s; frozen 4ad77bd pass 0.156 s Real round-1 cleanup-form/ledger findings are resolved by the recorded second round. No new finding on the passing runs
    Signoff 2026-11-04 11:56:14.511–11:56:34.674, 20.163 s, exit 0 No new finding. just signoff signs 4ad77bd5e19ddab9d79c3c5d692087a2789c64d2 after detached finish/check passes; the original publication scenario fails again at 62161e4 on its recorded pending_checks assertion (expected exit 1)
    Waiting for Nicely release Update-only wait: 2026-11-03 19:36:15–2026-11-04 09:49:48.464, 51,213.464 s (14 h 13 min 33.464 s) Real upstream dependencies #462 and #468; no waiver. Interval ends at the first resumed T3 run after Chef released the hold
    Hosted macOS queue Attempt 1: 2026-11-04 11:28:01–11:43:02, 901 s Not a finding or test result: no runner and no steps. GitHub reports the hosted runner was never acquired and macOS arm64 capacity constraints. The one authorized failed-job-only rerun passes on the same frozen SHA. Attempt 2 queues for 306 s (11:47:15–11:52:21), then runs for 168 s (11:52:21–11:55:09), including its 82 s check step. No new commit or empty push; no second retry
    Merge 2026-11-04 12:06:52 PR #17 merged by a fast-forward of main from 708ad0a to the signed SHA 4ad77bd5e19ddab9d79c3c5d692087a2789c64d2, with no squash, so just release finds the signoff receipt for main's head. No deploy is required. No finding
    Release 2026-11-04 12:07:19–12:13:24 (receipt times), about 365 s, exit 0. Tag v0.2.2 → 4ad77bd5e19ddab9d79c3c5d692087a2789c64d2 (annotated tag object 233cffe) just release v0.2.2 with the checksum-verified run copy of IMG_1642.MOV. Receipt steps: finish 0.146 s exit 0; real-fixture acceptance 228.164 s exit 0; hosted checks read 0.534 s; tag and push exit 0; host build, README install, describe and uninstall exit 0; not-found exits 2 with NOT_FOUND after the uninstall, which is the expected answer. No notes. No finding

    The release keeps the documented limits: the cleanup guarantee needs Nicely ≥ v0.26.1 (nicely#484), and the output can keep descriptive metadata (#18). This comment does not close #427. Rule 6 belongs to batch 4.

    Gate rows by GPT-6.1-Sol via Codex. Merge and Release rows by Opus-5.5 via Claude Code

  8. pascalandy
    added
    1-wip-by-agentAn agent has started work on this issue
    and removed
    1-ready-for-agentValidated work, sufficiently specified for an autonomous agent
    on Nov 4, 2026

  9. pascalandy commented on Nov 4, 2026

    @pascalandy
    pascalandy
    on Nov 4, 2026
    OwnerAuthor

    Rule 6 is met. nicely#487 merged on 2026-11-04 at 13:40 (America/Montreal) as 6aaebd34. It sets COR-104-T10 to done in docs/backlog/COR-104-verification-map.md and links ncly-video-convert#17, the tag v0.2.2, and the gate table.

    Check:

    Still open, under COR-104's After: Pascal's UAT of video-convert, and the removal of gates that took time and found no real defect. Follow-ups: ncly-video-convert#14, ncly-video-convert#18, #484, #485, #486.

    Closing #427.

    by Opus-5.5 via Claude Code

  10. pascalandy
    closed this as completedon Nov 4, 2026
  11. pascalandy
    removed
    1-wip-by-agentAn agent has started work on this issue
    on Nov 4, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    2-type:taskSupporting work such as maintenance, documentation, refactoring, or verification3-pty:p1High priority; takes precedence over ordinary planned work

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions