Rebuild Odoo site testing lanes when platform main moves

Objective

Once a site runs Odoo 20, every platform input it builds from is pinned exactly and moved by an automatic update PR, so a platform merge reaches that site's testing lane through its normal PR, preview and merge train path. Option C under Q196; scope at #131 (comment).

Why

A platform change should reach every site without anyone remembering to move it. That is the "I changed it, why doesn't it apply?" problem. Exact pins keep each build reproducible, and an update PR makes each move visible: it either reaches testing or leaves a failed check on the PR.

Finish line

Once a site's main builds Odoo 20, the shared Renovate preset (renovate/devkit-pin.json, or its successor) also moves that site's [repos.shared_addons] pin, so a shared-addons merge opens an update PR there with no human step.
Prod still moves only through the site's Client release acceptance.

Operator decision needed before building

Settled: Q196 chose option C. Scope and wait corrected at #131 (comment). No grant, credential or new route is needed.

Current Status

State: Complete; issue already closed as completed.
Next actor: agent:01a1a78b-2c93-7c91-af85-11d5396a26d1
Next action: finish the exact current-head CI and tenant build-only checks, record their evidence, use checked Ready and let the enrolled merge train land the PR, then verify main and close out this own claim.
Evidence: #408 (comment) weighs the Anthropic review. Actual Renovate extraction/replacement controls and source tests/statics pass. Native inspection remains UNKNOWN with its exact unsupported JSON/Markdown reason under the current standing exception linked in the PR; no bypass or false GREEN.
Consumer runs: https://github.com/cbusillo/odoo-tenant-cm-website/actions/runs/42452896827 and https://github.com/cbusillo/odoo-tenant-opw/actions/runs/42452898209 (candidate80312840f804f477a59405db5c7b28072e5a8533).
Scope: CM main20 only is eligible for shared-addons updates. OPW and website main19 shared pins remain unchanged under #131 (comment) and reviewed clear event #131 (comment). No OPW314 migration work/gate, consumer pin move, Renovate force run, runtime/config/data action, Client acceptance, production release or access change.

Landing reconciliation: #408 at 1e93fec. Original evidence and retained artifact custody above are preserved.

GO-ODK capacity selection: gh-plan.py next ranked this first. Full issue and linked launchplane#2583/#2600 decision records were read. The claim helper refused with claim_wait_unresolved because the recorded Current Status includes wait/hold wording; write_outcome is not_started. Under this brief's refused-claim rule I leave it unclaimed and move to the next independent candidate, #194. No worktree, source change, grant or runtime action for #131. This refusal does not establish a new Director decision: the current status already records approved source investigation; the next assigned agent can verify that resolution through the supported claim path.

GOC-ODK selection check, October 10, 2026, 9:59 PM ET (Claude Code session, capacity run). I ran gh-plan.py next, which ranked this issue first. I read the issue, its comment, launchplane#2583 and the merged launchplane#2600, then checked how the sites build today. I did not claim it, create a worktree or change any source. This item is cross-repository design work, not the quick item that needs no decision that this capacity run is for. Here is what I found:

The "sites track platform main" premise holds only for shared addons. Each site's workspace.toml pins devkit to an exact commit (cm-website de8ed57, cm and opw e45c916). The site build.yml rejects any devkit ref that is not a 40-character commit. Only shared_addons uses ref = "main". launchplane#2583 decided that our own code tracks main, but it deferred removing the devkit pin to its own slice. The CM website release workflow (odoo-tenant-cm-website#157) now relies on those exact refs.
Launchplane rejects a rebuild of an unchanged site commit. control_plane/build_provenance.py (_select_build_run, launchplane b92402ac) accepts only push and pull_request runs of build.yml, matched by the tenant head_sha. Recording a second manifest for an existing artifact with different content raises "already recorded with different content". The GitHub App webhook (_target_shapes) maps only push and pull_request build runs to testing or preview. A scheduled run, a dispatched run or a polling rebuild of the same tenant commit therefore never reaches testing.
So every trigger needs Launchplane work:
- One option is for Launchplane to accept a platform-triggered rebuild, with its own artifact identity (tenant commit plus platform commits) and a trusted trigger event.
- The other is a new tenant commit per platform move. That is the bump bot launchplane#2583 rejected ("a pin nobody remembers to move is worse than no pin, and a bot adds credentials, train-author grants and three PRs per update").
- Shared-addons moves need the first option even with no devkit pin.

My recommendation is that the next agent with Launchplane scope designs the rebuild identity in Launchplane first. It would accept a rebuild whose recorded platform commits differ for the same tenant commit, and it would add a non-push trigger to the site build.yml with no new credentials. The devkit-pin removal slice deferred on #2583 would then follow, coordinated with odoo-tenant-cm-website#157's release. I am leaving labels and Current Status unchanged: the next actor is an agent, and the wait refusal earlier sessions hit stays for the claiming agent to resolve with --wait-resolved.

ODK-131-D1 — stopped before claim or code under Q177's Client-release scope rule.

Read #131's full body and both comments, linked launchplane#2583's complete decision history and launchplane#2600, then checked the current CM website manifest/build workflow and Launchplane provenance source. Fresh #131 read has no claim, no native blockers or children, and no implementation PR among the open devkit PRs. The previous capacity claim attempt was refused without starting a write; this session did not claim or clear that refusal.

The source confirms the previous investigation's concrete blocker: CM website build.yml runs only on push/pull_request and requires a 40-character devkit commit matching runtime. Its workspace.toml pins both to de8ed57 while shared addons follows main. Launchplane's _select_build_run queries only push for release or pull_request for preview. Adding a dispatched platform trigger in devkit alone therefore cannot deliver this issue's testing finish line. The exact CM devkit/runtime input is part of the ongoing Client production-repair/release workstream #157; changing it to floating main touches that release contract. Q177 explicitly says to post and stop when the item touches a Client release or production, so this capacity brief is not the implementation path.

Next action: Supervisor routes the existing #131 to a coordinated Launchplane/tenant source session. First define and test a trusted platform-rebuild event and distinct artifact identity for unchanged tenant commits; then coordinate the deferred devkit-pin change with the existing tenant release owner. Preserve launchplane#2600's artifact-only handoff, existing Client acceptance, and production gates. No new grant, credential, route or Director decision is inferred by this intake. This is an agent coordination step, so #131 remains open and plan:active, not plan:waiting. No new issue is opened.

Admission context: current overall DIRECTION Order 3 admits tooling when every milestone's available work already has the sessions it can use and provider capacity would otherwise go unused, under the supplied capacity brief and codex-skills#1043 comment 5982761132. There is no claim comment because the scope stop happened first.

No worktree, branch, source edit, push, PR, label, merge, deployment, live-data change or access action. Tests, model review and JetBrains inspection are not applicable to this no-code intake. Primary checkout and all existing worktrees remain unchanged; temporary read snapshots are removed at closeout. No ongoing process or monitoring remains. Safe to exit: yes for this stopped intake; #131 is not complete.

Claimed by DKA-D2

Session: 01a12d35-48f6-7740-9d30-6a81835566ef
Branch: work/dka-d2-131
Claimed at: 2026-10-11T19:05:21-04:00
Next action: Define and test platform-triggered testing rebuilds with verifiable provenance; preserve Client production acceptance. Admission: milestone under current DKA-D2 Supervisor brief and Q187; capacity rule admits work when every milestone available work has the sessions it can use and provider capacity would otherwise go unused.

Admission: milestone; no Track link found in the readable graph: Director Supervisor brief explicitly selects #131 as Lane A milestone work after Oct 11 backlog triage; issue currently has no native Track link. Source implementation authorized by this brief, not a new milestone or production grant.; cbusillo/codex-skills#1043

Wait resolution: Current Status explicitly says Waiting for: None for agent coordination and requests no new Director decision. Earlier Q177 intake scope is superseded for source work by current DKA-D2 milestone brief; Client acceptance and production delivery remain gated. No grant, credential, live deployment or production wait is lifted.

Previous Current Status:

State: Active for coordinated source work; ODK-131-D1 stopped before claim/code under Q177's Client-release scope rule. This issue is not complete.
Next action: Supervisor assigns the existing #131 to a coordinated Launchplane/tenant session to define and test trusted platform-rebuild events and artifact identity, then sequence deferred devkit-pin changes with the tenant release owner. A devkit-only dispatch does not satisfy the testing finish line.
Blocked by: No native issue blocker. Launchplane currently verifies push/pull_request build runs only; CM website requires matching exact devkit/runtime commits and its input participates in Client release workstream odoo-tenant-cm-website#157.
Waiting for: None for agent coordination. Existing Client acceptance and production gates remain on release delivery; this intake requests no new Director decision and grants no access, credential or deployment authority.
Last verified: October 11, 2026, 11:09 AM ET (ODK-131-D1). Full #131 discussion, linked #2583/#2600 decisions, live CM manifest/build workflow, live Launchplane provenance source, open devkit PRs and registered worktrees checked. Evidence and scoped handoff: #131 (comment). No claim, worktree, source edit, PR or runtime change.

Owner question: Should #131 use a Launchplane-owned platform-rebuild route, rather than a cross-repository credential in platform CI? Recommend yes to the Launchplane route. Yes authorizes the coordinated source slice below; no leaves automatic rebuilds unimplemented until another mechanism is selected. This is a route decision, not permission to install an App, enlarge its grants, create a secret, or release production.

Applicable Launchplane DIRECTION stop boundary: “creating credentials that can reach a live site, granting access, or changing who can merge”. This issue explicitly requires the grant or route decision before building, and the agreed #2583 design defers that decision to this slice. The confirmed #130 dispatch decision (#130 (comment)) approves agent-run build-only checks; it leaves automated Launchplane dispatch as a later step. The capacity/milestone assignment authorizes source work but does not itself settle the dispatch-credential route. I interpret this as requiring the recorded route decision before introducing automated credential use and expanding release-build verification; no missing installation permission is asserted as fact.

Concrete proposed slice:

Launchplane receives platform source events through its existing signed source-control adapter, discovers affected Odoo products from their authoritative repository/build inputs, and durably requests a rebuild of each tenant's default branch. No platform-owned site catalog and no platform-repo call into Launchplane.
Use the existing Launchplane delivery App's repository-scoped workflow_dispatch path for the tenant's build only. Dispatch supplies no build refs or secrets; the tenant's own manifest remains the build-input authority. Effective installation permissions and secret bindings for each tenant are unverified for this proposed path; if unavailable, report the exact refusal rather than generating credentials or expanding access.
Tenant workflows accept the rebuild event and resolve approved floating platform inputs together (devkit/runtime stay the same checkout). Coordinate the deferred pin change with the tenant release contract; do not change an existing accepted production artifact.
Verify the resulting run's immutable repository identity, reviewed default-branch first-parent commit, event, current attempt, uploaded manifest and digest. Keep source-control-adapter details out of the generic rebuild contract. Preserve testing holds and forward movement. Persist dispatch uncertainty instead of blindly sending another request; record a failed rebuild in the site's testing status. Production keeps its existing exact Client-accepted release path.

Fresh findings, DKA-D2:

Claim succeeded: Rebuild Odoo site testing lanes when platform main moves #131 (comment). Admission is milestone under the supplied Lane A brief/Q187, with the current overall capacity-admission rule and an explicit missing Track-link explanation.
No retained implementation PR exists in devkit. All three live tenant build.yml files accept only push/PR and enforce an exact matching devkit/runtime commit.
Current Launchplane verification and testing selection accept push release builds only; its webhook ignores a dispatched build. A devkit-only dispatcher cannot reach the finish line.
Correction to the earlier handoff: the artifact key already comes from verified repository/run/attempt/upload identity, and lane movement already orders same-tenant-commit rebuilds by verified run identity. A new immutable artifact-key format is unnecessary. The remaining work is event/dispatch admission, freshness selection, tenant inputs and visible failures.
#2606 remains open; do not infer its remaining caller/data/access retirement is complete or reopen its completed Client drill as a new wait.

No code, commit, push, PR, test/runtime execution, credential, grant, deploy or production change. Tests, model review and JetBrains inspection are not applicable to this no-code decision preparation. Two newly created task worktrees have no edits or unique commits and will be retired under work-closeout; previous checkouts and worktrees remain untouched. #131 stays open for the decision, not completed or marked Ready.

Released claim 6114906091

DKA-D2, Codex session 01a12d35-48f6-7740-9d30-6a81835566ef, stops at the recorded route decision in #131 (comment). The issue remains open and plan:waiting for Director cbusillo; no source work continues. Corrected the prior handoff's obsolete artifact-identity premise: verified run-based identity and same-commit ordering already exist. Current testing selection and all three tenant workflows still need the rebuild event/input work. Both session-created clean, unchanged dka-d2-131 worktrees and local branches in devkit and Launchplane were retired successfully with dev-worktree retire; there were no unique commits, ignored/untracked files, IDE preparation, SDKs or leases from this task. No code, commit, push, PR, grant, credential, runtime, deployment or production change. Tests, independent-model review and inspection are not applicable. Other workers' checkouts and artifacts remain untouched. Primary checkouts remain clean, unchanged and stale; refresh before default-branch audits. Full-history #131 attention scan is clear. Only this task's temporary read/draft/inventory snapshots are disposable after durable readback. No background work or monitoring remains. Love: the next decision is concrete and the obsolete identity premise is corrected. Do not love: automatic rebuilding is still unimplemented. Safe to exit: yes for this parked decision handoff, not completion of #131.

Sol design review (Q196):

Recommend C: exact platform inputs in each site repo, advanced by one grouped update PR per site per batch, with a scheduled reconciliation scan to catch missed updates. Keep Launchplane's existing PR → preview → merge train → testing path and exact-artifact Client production acceptance. Do not build a new floating-input deployment path first.

I agree with the Supervisor's leaning, but “add Dependabot” is not a complete design. All effective build inputs must be pinned, compatible inputs must move together, and the updater must coalesce changes instead of creating three PRs for every platform commit.

Facts checked from source

Fresh default-branch snapshots:

Site	Tenant commit	Devkit and runtime in `workspace.toml`	Shared addons	Runtime/devtools bases
CM	`81735ed82902d732bdfc2bfacde984749f869e4b`	`e45c916b111add6906ef13ff0bd44c0837679be7`	`main`	Mutable `19.0-runtime` / `19.0-devtools` tags
CM website	`ddf2523e4c23ed3e0836beccc7716a6d3af3b525`	`de8ed5751a897d8ff3a49d7bcff76016cde8f124`	`main`	Same mutable tags
OPW	`b2660b9039ab6a1f12958520496f7530a8b27fd8`	`3b72effb1fb987aa395a7303a5cabdb8ede0005d`	`main`	Same mutable tags

Sources: CM manifest, website manifest, OPW manifest.

All three build.yml workflows accept push/PR events, require a 40-character devkit SHA, and require runtime to match it. They build in the tenant repository with existing source-read and registry bindings and upload a manifest; they do not call Launchplane. Thus #131's premise that devkit already follows main is false today. Sources: CM build, website build, OPW build.

The build is still only partly pinned. Each site's artifact-inputs.toml follows our disable_odoo_online fork's main; the website also selects shared-addons main there. OPW declares an exact OCA OpenUpgrade revision in its testing override. Addon-test workflows have a separately pinned devkit action and floating shared-addon checkouts. C must align those executed inputs with the artifact build, rather than pinning one manifest field while CI tests a different combination. Sources: CM inputs, website inputs, OPW inputs, OPW addon tests.

OPW #216 is the concrete reason to keep an integration PR. Devkit #210 restored pydantic 2.14 / typing-inspection 0.4.4 while OPW's old lock demanded 0.4.2. The build failed; #216 aligned the tenant lock and all three devkit references, then passed the artifact build and 372 addon tests. Both PRs are now merged, and #216 records the resulting testing deployment. Its pin names #210's reviewed head, which is contained in current devkit main; it does not float to subsequent devkit changes. Current devkit main is eight commits beyond that head. This demonstrates compatibility coordination, not that manual pin maintenance is sufficient forever. Sources: #210 evidence, #216 qualification, testing readback, ancestry/diff.

Options

Concern	A: floating + Launchplane events	B: floating + nightly catch-up	C: pins + grouped PRs
Safety before Client testing	Reviewed platform main is useful, but the new site/platform combination needs consumer qualification. Floating inputs can change between qualification and rebuild.	Same safety gap; a timer does not supply review or qualification.	Exact input diff and site CI precede testing. Pin every effective input so PR and landed builds select the same tuple.
Drift/staleness	Fast when delivery works; lost events, incompatible locks and still-pinned devkit can leave a site behind.	Eventually catches missed source/digest changes, but adds up to a nightly interval plus build time; failures still need visible handling.	Pending/failed update PRs expose lag. A daily scan and stale-update reporting prevent forgotten pins; batching deliberately trades some freshness for stability.
Debugging	Manifest records exact inputs, but one tenant SHA can mean several platform combinations.	Same, often combining several changes overnight.	Tenant commit and grouped diff explain the platform change. Groups still need component SHAs and comparison links.
Credentials/access	Reuse Launchplane's existing App if its effective dispatch rights suffice; keep source/build credentials tenant-side. No platform-to-site token or site catalog.	Tenant-local schedules avoid cross-repo dispatch credentials, but deployment admission still needs Launchplane work.	Reuse existing repository automation and tenant build bindings where verified. PR creation needs contents/PR rights, not production credentials or new merge authority. No new App/grant is assumed.
PR/Client noise	No synthetic tenant PRs, but changed testing behavior still needs intelligible release notes.	Same; nightly changes can disrupt a staff test session.	More PRs/landings. One outstanding grouped PR per site and the existing Client batching limit noise; neither per-commit PRs nor zero Client pings is promised.
Rollback	Redeploy the previous immutable artifact; pause automatic updates so reconciliation does not immediately undo the rollback.	Same.	Same immediate artifact rollback, plus reverting pins gives a durable source-level recovery. Reverting code alone does not undo database migrations.
Machinery	Dependency discovery, durable dispatch/recovery, dispatched-build provenance admission, testing selection and failure visibility; exact consumer qualification also needs wiring.	Simpler trigger, but the same dispatched/scheduled-build admission and qualification problems.	Pin synchronization/grouping and a reconciler. Reuses the normal push/PR build, provenance and testing path.

A can be made safe; it is not inherently wrong because inputs float. However, provenance tells us what ran; it does not prove the exact combination was reviewed and qualified. The delivered #130 slice checks devkit candidates against CM website and OPW through agent-run build-only dispatches. It is not an automatic gate for CM, shared-addons and every base-image change.

There is also a base-image timing problem: an odoo-docker merge triggers an Enterprise build, and tenant inputs consume the resulting Enterprise tags. Rebuilding immediately on the source merge can read the old tag. The later successful image publication can move a digest without a new tenant or platform commit. Any solution must reconcile published image digests, not merely source SHAs. Source: odoo-docker publish/Enterprise dispatch.

Current Launchplane build verification selects push for release/testing and PR for preview, and its webhook ignores other build triggers. A/B therefore need coordinated Launchplane changes. A new artifact-key format is unnecessary: verified run/attempt identities and same-commit ordering already exist.

Recommendation and smallest first step

Use C with a daily reconciliation scan that proposes updates, never directly deploys them. Resolve our platform repos to landed commits and base images to published digests; group dependent lock/action changes into the same site PR. Keep one pending platform-update PR per site, coalesce superseded candidates, and leave a failed update visible while testing keeps its qualified artifact. Client production acceptance remains bound to the exact artifact.

Use the existing devkit synchronizer and upgrade contract, rather than a regex-only updater for coupled locks. That helper currently updates devkit/runtime and addon build-tool requirements; it does not yet cover every action, source or image selector. Existing Dependabot configuration is not a complete platform updater. Renovate custom managers can discover custom declarations, but compatibility synchronization still needs the shared helper. A tenant-local bot is not automatically credential-free: GitHub documents that PR workflows created with GITHUB_TOKEN require approval; an existing App token can allow automatic runs. Verify that path before promising unattended operation.

Smallest implementation pilot, after Q196 is decided: one OPW PR keeps its known-good devkit pin, pins the remaining effective source/base inputs to an evidenced tuple, aligns addon-test inputs, and qualifies that exact tuple with its normal build/tests. No new bot or access is needed to prepare that agent-authored pilot. Then extend the existing synchronizer and verified automation path to maintain one grouped update PR; repeat for the other sites. Do not introduce a shared platform-version file or duplicate Launchplane's product inventory.

This recommendation revisits the September 29 decision, which rejected bump bots for stale pins, credentials and PR churn. Those concerns remain valid. Grouping addresses churn; reconciliation addresses stale pins; retaining existing automation addresses credential sprawl where its rights suffice. The demonstrated lock conflict and today's existing pin/sync contract make C the smaller reliable path now. This review does not overturn that decision or implement C; #131 remains open for Q196.

SOL196-D1 admission: the supplied Owner capacity decision authorizes this review. Current overall Order 3 admits tooling when every milestone's available work already has the sessions it can use and provider capacity would otherwise go unused; the brief's older “all milestones wait on people” wording is not the current rule. #131's prior claim was released; no claim, branch, worktree, code, PR, access or runtime change was made. This is the single requested design-review comment; no additional rollup write. Tests, IDE inspection and a further model-review run are not applicable to this source-backed review.

Love: one reviewed site change can carry the exact compatible platform inputs through the existing delivery path.
Do not love: automatic grouped updates are not yet implemented, and the policy choice remains with the Director.
Safe to exit: yes.

Director decision (Q196): option C as Sol's review describes (#131 (comment)). Chris said in the Supervisor chat at about 9:00 PM ET on Oct 11: "Agree with both".

The design:

pin every effective platform input in each site repository, including base images by published digest, and make the tests use the same pinned combination;
keep one grouped update PR per site at a time, folding newer changes into it;
run a daily reconciliation scan that proposes updates and never deploys;
reuse the existing odoo-devkit synchronizer instead of a new bot.

This issue's floating-input rebuild-route proposal (option A) is not chosen. This revisits the September 29 decision (launchplane#2583) for the reasons in Sol's review. Timing: after the Every live product green milestone (Q192). The first step is the OPW pilot PR. This issue should be rescoped to option C when that work starts.

Structured wait review

Correction to #131 (comment), made in the same review with Chris (cbusillo/direction#150, Oct 29).

The shared-addons pin is not stale by accident. #279 pinned all three Odoo 19 sites to 5f25b46 because odoo-shared-addons main moved to Odoo 20 (manifests at 20.0.x, cbusillo/odoo-shared-addons#83 closed). Moving that pin to main now would break every 19 build. #279 says each site's own Odoo 20 conversion advances the pin.

Chris chose to restore the wait: this issue waits until each site lands its Odoo 20 conversion. After that, the shared Renovate preset moves the shared-addons pin. Base-image digest pinning is dropped for now: the sites are about to change images, and digest pins would need cbusillo/odoo-enterprise-docker#87's index pruning to keep pinned images.

Waiting for Each Odoo site's Odoo 20 conversion (under #277). This ends when A site's workspace.toml builds Odoo 20 on main.

Nothing here is waiting on a person or event.

Current Status

Next actor: agent
Next action: Add shared-addons pin updates to the shared Renovate preset for the eligible Odoo 20 CM consumer. Preserve the Odoo 19 OPW and website pins, following the recorded scope decision.
Last verified: November 6, 2026, issue trial TRIALODOO396-1106. CM main now declares Odoo 20 and its normal main Build succeeded. The recorded first-site event is therefore satisfied. Current devkit main 0a2522c still has only devkit/runtime and devkit-action matchers in renovate/devkit-pin.json; it has no shared-addons matcher. This is unfinished, Director-decided work with a concrete next action, so it stays open. Full discussion and fresh ownership checks found no current holder. The issue body is preserved. Audit anchor: #396.

Claimed by DEVKIT131-SHARED-PIN-1108

Session: 01a1b9b6-821d-7153-a218-5bf91c90f23a
Branch: work/devkit131-shared-pin-1108
Claimed at: 2026-11-08T00:53:19-05:00
Next action: Implement and validate the existing shared Renovate preset for shared-addons exact pins on Odoo 20 main manifests, preserving Odoo 19 pins.

Admission: milestone; https://github.com/cbusillo/direction/issues/5

Wait resolution: Per-site event cleared at #131 (comment) under scope #131 (comment); live main manifests rechecked: CM 20, OPW and website 19. No product or production hold clears.

Work record

DEVKIT131-SHARED-PIN-1108 source check at 8dd0217.

Actual Renovate 44.181.5 with Node 24.22.1: strict repository config validation passed. Actual JSONata/regex extraction and doAutoReplace controls passed against fresh main manifests: CM shared=1, OPW=0, website=0; existing devkit/runtime deps=2 each. Replacement changed only shared_addons.ref. Table reordering works; floating/short pins, commented Odoo20 in an Odoo19 manifest, and absent build metadata produce no shared update. Baseline preset fails the eligible-CM assertion (0 versus 1).

22 existing workspace tests passed. Whole-repo Ruff lint and format passed. No Python runtime or generator code changed; no applicable safety module was modified. Full suite stays in CI. Repository metadata remains accurate. No generated workspace surface changed.

Native inspection run b658571a-a6cb-4cff-860b-ae2ea7282859 returned UNKNOWN/isolated_backend_unavailable: no native worker covers Markdown; JSON in the configured PyCharm lane is unsupported. No assessment was performed and no retry is permitted. Proceeding under the standing temporary Director exception https://github.com/cbusillo/direction/issues/98#issuecomment-6399734189, retained by https://github.com/cbusillo/direction/issues/98#issuecomment-6428617448. Fresh paginated direction98 discussion read and the still-open codex-skills2923 finish line found no later ending decision. No inspection configuration or verdict was changed.

Removed: manual shared-addons repinning for eligible Odoo20 consumers. Net lines: +24 (25 additions, one deletion); one native Renovate manager and its update rule/docs are required to fill the existing preset's missing behavior. No second updater or site registry.

Confirmed default-branch landing: #408 at 1e93fec. This issue is already closed as completed; a reference alone does not prove its finish line. Planning metadata reconciled through the existing close preflight; retained artifact custody remains on the source PR/handoff.

Released claim 6717939953

Session: 01a1b9b6-821d-7153-a218-5bf91c90f23a
Trial: DEVKIT131-SHARED-PIN-1108

Completed source delivery: #408 landed through Launchplane at 1e93fec. Train landing plan merge-train-batch-landing-plan-20261108T061640Z-28f8ba7864a7195c and complete planning reconciliation are recorded at #408 (comment) . Issue131 is closed/completed and reconcile-landing confirmed full coverage, no remaining blockers or dependents.

Evidence: #408 (comment) records the exact-head successful OPW/website consumer builds and five green PR checks. Main CI https://github.com/cbusillo/odoo-devkit/actions/runs/42454105282 and CodeQL https://github.com/cbusillo/odoo-devkit/actions/runs/42454105304 succeeded. Actual Renovate validator/extraction/replacement controls, failing baseline and22workspace tests passed; lint/format passed. Weighed Anthropic claude-opus-5-5 review: one docs clarification acted on, replacement concern refuted with the actual implementation. Native inspection remains UNKNOWN for unsupported JSON/Markdown, explicitly allowed by the current standing Director exception linked on the PR. Code scanning reports zero open alerts; the sanitized secret-scanning signal is unavailable for this public repository, not claimed clean.

CM main20 is eligible; OPW and website main19 shared pins are preserved. No consumer pin move, Renovate force run, product/runtime/config/data action, Client acceptance, production release, identity or grant change. This is no OPW314 migration work or gate.

Local default checkout was safely fast-forwarded to the confirmed landing and is clean. Own task work/devkit131-shared-pin-1108 and its configured task tree are clean/published/merged; qualified retirement follows release readback. Other workers' trees and source are preserved. Review/validator/control/build receipts remain in this task's configured evidence unit under ordinary expiry; disposable private queue snapshots will be removed. No worker launches occurred; own native commands/watchers have completed.

Next actor: agent:01a1a78b-2c93-7c91-af85-11d5396a26d1
Next action: consume this source-only completion and perform the brief's root-owned guarded native closure. No further131engineering or product action is required by this delivery.

Removed: manual shared-addons repinning for eligible Odoo20 consumers. Net lines: +24; one native Renovate TOML manager, its existing-style update rule and docs supply the missing automation without a second updater or registry.
Session outcome: {"landed_without_rescue": true, "review_findings_acted_on": 1}

Session: 01a1b9b6-821d-7153-a218-5bf91c90f23a

Retained PR handoff: #408

DEVKIT131-SHARED-PIN-1108 completed.
Session: 01a1b9b6-821d-7153-a218-5bf91c90f23a

Landed change landed through the normal train at 1e93fec; #131 is closed/completed with full planning reconciliation. Exact-head consumer/CI evidence, weighed review, train landing, main CI, main CodeQL, and own exact claim release/readback are complete. Full native check_claims reports claims_clear:true, coverage.complete:true, no blocked or unresolved invocations.

The preset now extracts the eligible CM main20 shared-addons exact pin; current OPW/website main19 pins remain excluded. Actual Renovate extraction and replacement controls pass and fail on the old preset. No tenant pin/runtime/data/configuration/production/Client/access action was performed. No cbusillo/odoo-tenant-opw#314 work or gate follows. Native inspection remains UNKNOWN for the unsupported JSON/Markdown selection under the explicitly linked standing exception, not a clean verdict. Public-repository secret-scanning signal is unavailable; code scanning has zero open alerts.

Local main is clean at the landing. The own merged/published branch work/devkit131-shared-pin-1108 and its configured task tree are retained: the exact supported retirement dry run returned “associated work has an open claim” even though this session's exact claim release and full coverage are verified. No unlock, alternate removal or claimed retirement. Leave it for the existing guarded creator sweep after associated custody/native closure ends. Other workers' trees are preserved. The task's review/control/build receipts remain under ordinary configured evidence expiry; the disposable private queue snapshot was removed. Own source/build/watch commands are terminal.

Next actor: agent:01a1a78b-2c93-7c91-af85-11d5396a26d1
Next action: consume this completion and perform root-owned guarded native closure. No remaining131source work, Director question or product action.

Removed: manual eligible-site shared-addons repinning. Net lines: +24; the new native Renovate manager/rule/docs fill the existing preset's missing dependency without another updater or site registry.
Love: eligibility uses parsed main-branch manifest data and preserves exact pins.
Do not love: native inspection is honestly UNKNOWN; guarded retirement retains the tree.
Session outcome: {"landed_without_rescue": true, "review_findings_acted_on": 1}

Navigation Menu

Repository navigation

Rebuild Odoo site testing lanes when platform main moves #131

Objective

Why

Finish line

Operator decision needed before building

Current Status

Facts checked from source

Options

Recommendation and smallest first step

3 remaining items

Current Status

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Rebuild Odoo site testing lanes when platform main moves #131

Description

Objective

Why

Finish line

Operator decision needed before building

Current Status

Activity

shiny-code-app commented on Oct 11, 2026

shiny-code-app commented on Oct 11, 2026

shiny-code-app commented on Oct 11, 2026

shiny-code-app commented on Oct 11, 2026

shiny-code-app commented on Oct 11, 2026

shiny-code-app commented on Oct 11, 2026

shiny-code-app commented on Oct 12, 2026

Facts checked from source

Options

Recommendation and smallest first step

shiny-code-app commented on Oct 12, 2026

shiny-code-app commented on Oct 15, 2026

3 remaining items

shiny-code-app commented on Oct 29, 2026

shiny-code-app commented on Oct 29, 2026

shiny-code-app commented on Nov 6, 2026

shiny-code-app commented on Nov 6, 2026

Current Status

shiny-code-app commented on Nov 8, 2026

shiny-code-app commented on Nov 8, 2026

shiny-code-app commented on Nov 8, 2026

shiny-code-app commented on Nov 8, 2026

shiny-code-app commented on Nov 8, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions