Portfolio Wave 2

One-Minute Explanation

Portfolio Wave 2 tested a practical question: can Duende Builder move more small, useful slices at once without weakening the controls needed for a manufacturing product?

The answer is that one controller can coordinate three workstreams safely. Nine execution nodes were planned across product authority, performance and recovery, and delivery control. They were activated in stages, not as nine simultaneous worktrees. Each slice had a narrow outcome, owned paths, focused tests, two independent exact-SHA reviews, CI, an ordered merge, and normal cleanup.

The product stream clarified what Daily Plan, Mix Schedule, and Customer Summary data means today. The evidence stream built fictional workloads and measured real v9.346 scheduling and recovery paths. The delivery stream added the dependency controller, fail-closed review queue, and deterministic metrics contract.

All nine nodes merged. The workflow prevented stale reviews from being treated as current, caught a Linux Chrome cleanup race before merge, and left no Wave 2 feature branch or worktree behind.

The next concurrency decision is deliberately conservative: hold Wave 3 at three active implementation lanes. The run did not record every lifecycle event required for an honest review-wait and active-time calculation. The next delivery slice will add that instrumentation; a later measured wave can then support or reject expansion to five.

Engineering Delivery Problem And Value

This section describes a software-delivery and product-enablement problem. It does not describe a new manufacturing feature or claim that nine product features were delivered.

Business Workflow

How to read this view: Blue steps are the delivered portfolio workflow. Amber marks a decision or evidence boundary. The workflow ends with a capacity decision; it never crosses into manufacturing plan release.

The root controller begins with an approved outcome and one portfolio manifest. It activates only slices whose dependencies, write ownership, semantic locks, base SHA, and capacity are safe. A worker develops one result in an isolated worktree. Two reviewers and CI then inspect the same exact head SHA. The root merges one PR at a time, integrates current main into any remaining branch, invalidates stale approvals, and removes only verified merged topology.

Kalen owns the portfolio intent, policy boundaries, merge authority, and the next capacity decision. Workers own bounded implementation. Reviewers own independent findings, not edits. Mike and Justin remain the business owners for release/current-plan and related operating decisions; their availability does not block source characterization or fictional calibration work.

People, Inputs, Actions, And Outputs

How The Nine Nodes Fit Together

How to read this view: Arrows mean “must finish before this node becomes eligible.” A, B, and C are workstreams, not simultaneous lane counts. The cap grew from one to three and then at most five; nine active implementation lanes were never permitted.

What The Product Authority Work Means

The A stream did not change the scheduler. It turned mixed behavior into a source-backed map that future features must preserve or deliberately revise.

What The Performance And Recovery Work Means

B1 created deterministic small, medium, and stress fixtures. Every fixture is fictional engineering calibration data. The labels describe relative test sizes inside this repository; they do not represent accepted RH workload, capacity, concurrency, or service-level targets.

B2 measured actual v9.346 functions in a bounded Chrome session: runTankAndPourPlan, generateDayPlan, renderWeeklyPlan, and renderOptimizerToday. It pinned a planning date and one in-memory order, verified exact fixture and runtime namespace identities, and required repeated output parity. The stress browser path exceeded local storage quota, so the receipt records a structured failure and no success timing.

B3 exercised the real save, reload, backup, and restore chain for all three fixtures. It verified exact namespace reconciliation and preserved candidate history as nonreleased. A dropped-write injection showed an important limit: v9.346 can report restore success after a partial write. The benchmark detects and rejects that mismatch, but the product restore itself is not transactional and has no rollback.

These baselines are engineering evidence. They help define later storage and modularization slices; they do not certify production readiness.

Safety And Review Behavior

How to read this view: Every amber branch stops or repeats work. A PR cannot move forward merely because an earlier SHA passed. If code, evidence, or the base changes, both review and CI must run again.

The controller fails before mutation when it sees an unknown dependency, cycle, unsafe ref, overlapping owned path, overlapping semantic lock, dirty or mismatched topology, or WIP overflow. The review queue blocks stale final review, head/CI mismatch, unresolved actionable threads, unmet dependencies, and review-ready overflow.

Wave 2 exercised these controls in real work. B1 and A2 integrated current main before final review. B2 changed after its first CI run, then integrated newly merged B3. Each changed head received two fresh reviews and a new successful CI run. No force-push or force-delete was used.

The B2 failure is a useful example. Its browser assertions passed on Linux, but Chrome had not fully released its temporary profile directory when Node removed it. The PR failed rather than hiding the cleanup race. The harness added a finite five-retry, 100-millisecond-delay removal policy, regenerated the source-bound receipt, passed the integrated performance suite, and was re-reviewed at the new final SHA.

System And Authority Boundaries

The portfolio contains two systems of work:

• The product runtime is still the single-file v9.346 browser scheduler. A1-A3 describe it; they do not modify it.
• The delivery system is the repository controller, worktrees, tests, local reviewers, GitHub PRs, CI, metrics contract, and cleanup routine.

The delivery controller can decide whether a code slice is safe to activate or merge. It cannot decide that a manufacturing plan is released. A benchmark can show that a function behaved consistently under one fixture. It cannot approve an operational target. A source contract can identify a shipment field. It cannot decide who may communicate a commitment to a customer.

The following remain outside Wave 2:

• plan release, approval, current-plan selection, or floor acknowledgement;
• authentication, authorization, shared persistence, or production migration;
• use of private RH production data;
• production performance targets or workload representativeness;
• broad refactoring or splitting of the v9.346 prototype;
• more than five active Wave 2 lanes or any nine-lane model.

Technical Implementation Map

The canonical execution contract is docs/plans/2026-07-12-portfolio-wave-2-execplan.md. The source-backed outcome and final decision are in docs/agentic-engineering-framework/07-evidence/portfolio-wave-2-closeout.md.

Data, Security, And Operations

The committed fixtures contain no customer or staff identities. Receipts use counts, hashes, bounded error text, tool versions, and portable source paths. They do not include credentials, tokens, private URLs, absolute machine paths, or RH production records.

Browser state remains local to the prototype. Candidate history remains candidate-only and nonreleased across recovery checks. The benchmarks never promote restored data to current or released authority.

Operationally, the root controller is the only actor allowed to create PRs, merge, update shared closeout files, and remove worktrees. Cleanup begins with a preview or exact topology check and refuses ambiguous state. The original user-owned dirty checkout was kept separate and untouched throughout Wave 2.

Actual Results And The Wave 3 Decision

GitHub records show nine Wave 2 PRs merged during a 159.45-minute PR-visible window. Median PR-to-merge time was 2.333 minutes and mean time was 3.556 minutes. Eight PRs passed their first recorded CI attempt; B2 failed once, received a bounded correction, and then passed at its final reconciled SHA. There were zero open Wave 2 PRs and zero force operations after integration.

Those facts describe integration after most implementation and local review work had already happened. They do not measure full cycle time or reviewer wait. The C3 contract also requires exact readiness, branch creation, activation, local review, remediation, head-change, capacity, and cleanup events. Wave 2 did not persist all of them. A JSON receipt could be made to validate only by treating CI as human review and configured WIP as observed WIP. That would be false evidence, so no proxy is approved.

How to read this view: Blue boxes are evidence sources. Green boxes are deterministic validation and calculation. Amber boxes are capacity decisions. The local lifecycle source is incomplete, so the honest path leads to “hold at three,” not an inferred expansion.

The Wave 3 decision is therefore to keep three active implementation lanes and two review-ready items as the operating limits. The immediate next tooling slice will record lifecycle events automatically and update the chronology to represent pre-PR local review. After one measured three-lane wave, Kalen can reconsider allowing up to five. A separate six-lane experiment would need its own approved plan. Nine lanes remain forbidden.

Decisions, Risks, And Open Questions

Verification Evidence

• Every node has a focused contract test and final evidence or runbook.
• Two independent reviewers approved every implementation PR at its final SHA.
• CI passed the exact final SHA for PRs #15 through #23.
• The integrated scheduler, performance, artifact, command-center, and orchestration test selections are rerun in the closeout PR.
• PlantUML and standalone HTML sources are regenerated and checked in the same closeout PR.
• Privacy, local-path, Markdown, whitespace, branch, PR, and worktree checks are part of final closeout.

Glossary

• Active lane: one implementation slice currently allowed to change its declared paths. A worktree alone is not an active lane.
• Candidate: an optimizer result under review, not an approved or released production plan.
• C3 contract: the strict JSON input and deterministic calculation rules for portfolio flow and safety metrics.
• Exact-SHA review: review tied to one immutable Git commit. Any later head change invalidates the approval.
• Fictional engineering calibration: deterministic test data used to compare runs; it is not customer data or a production workload claim.
• Semantic lock: a named business or architecture concept that only one active slice may own, even when file paths differ.
• Workstream: a group of related outcomes. Wave 2 used product authority, performance and recovery, and delivery scale.
• Worktree: an isolated Git checkout for one bounded slice.

Source Trail

• docs/plans/2026-07-12-portfolio-wave-2-execplan.md
• docs/plans/2026-07-12-portfolio-wave-2-critical-review.md
• docs/agentic-engineering-framework/07-evidence/portfolio-wave-2-closeout.md
• docs/agentic-engineering-framework/07-evidence/portfolio-metrics-contract.md
• docs/architecture/daily-plan-rule-placement-v9346.md
• docs/architecture/mix-batch-authority-v9346.md
• docs/architecture/customer-summary-authority-v9346.md
• docs/architecture/research/2026-07-12-synthetic-workload-profile.md
• docs/agentic-engineering-framework/07-evidence/scheduler-performance-baseline-v9346.md
• docs/agentic-engineering-framework/07-evidence/storage-recovery-baseline-v9346.md
• docs/runbooks/portfolio-wave-delivery.md
• docs/runbooks/portfolio-review-queue.md
• GitHub PRs #15 through #23

Maintenance Note

Markdown and PlantUML are canonical. The standalone HTML and SVG files are generated mirrors. Update this guide when lifecycle instrumentation changes the metrics evidence, when the Wave 3 capacity decision changes, or when a later feature changes any authority or recovery boundary described here.