DoorDash Senior Embedded Developer Interview Preparation Guide

Explanation (why x & -x works)

In two's-complement, -x is the bitwise complement of x plus 1. That causes all bits below the least-significant set bit (LSB) to become zero in the AND, and the LSB itself to remain 1. Concretely: for x = ...1 0 0...0 1 0... where the rightmost 1 is the LSB, -x flips trailing bits and adds 1 producing ...0 1 1...1 1 0... so x & -x leaves only the rightmost 1.

• Result is zero when x == 0 (no set bits).
• Use unsigned types in C to avoid UB/implementation-defined behavior with signed overflow.

C example: iterate flags in mask

#include <stdint.h>
#include <stdio.h>

void handle_flag(uint32_t bit) {
    printf("flag bit 0x%08x\n", bit);
}

void process_mask(uint32_t mask) {
    while (mask) {
        uint32_t lsb = mask & -mask;   // isolates least-significant 1
        handle_flag(lsb);
        mask ^= lsb;                   // clear that bit
    }
}

int main(void) {
    uint32_t flags = 0x5042; // example mask
    process_mask(flags);
    return 0;
}

Notes (embedded concerns)

• Use unsigned integer types (uint32_t, unsigned long) to ensure defined behavior.
• This is branch- and loop-friendly and efficient on constrained hardware.
• When mask==0 the loop skips; lsb would be 0 if computed but should not be processed.

Summary approach
Systematically reproduce, isolate, and eliminate causes by controlled experiments that change only one variable at a time while observing bus-level signals and peripheral internal state.

Step 1 — Reproduce reliably

• Add instrumentation in firmware to log exact write sequences, addresses, data, and timestamp.
• Build a stress harness that repeats the failing write pattern with known seed values until failure.

Step 2 — Observe physical bus signals

• Use a logic analyzer/LA + oscilloscope to capture: CLK, ADDR, DATA, CS/SEL, R/W#, VALID/HREADY (AXI/AHB), ACK/REPLY, TRDY/IRDY (PCI-style), WAIT#/STALL, RESET, and peripheral interrupt lines.
• Look for missing ACK/TRDY transitions, bus held asserted (e.g., TRDY low), floating data lines, or long WAIT cycles.

Step 3 — Isolate suspects with targeted experiments

• Write pattern vs misaligned access:
  • Test aligned vs intentionally misaligned accesses; repeat with single-byte, half-word, word sizes.
  • Insert NOPs/delays between writes; check if timing/hold violations trigger.
• Disabled clock / clock-gating:
  • Force peripheral clock ON during write; toggle clock gating in firmware/hw; use scope to confirm clock present.
  • Perform write while toggling clock domain resets to see if bus recovers.
• Peripheral state machine:
  • After write, read status/control registers repeatedly; assert RESET to peripheral between attempts to see if state machine locks.
  • Apply soft/hard reset and check if ACK/TRDY returns.

Step 4 — Low-level experiments

• Read-after-write: perform an immediate read of a known RW register; if read hangs, bus likely locked by peripheral.
• Single-step / halting CPU: with debugger, single-step the write and capture bus trace to see exact timing.
• Replace peripheral with a known-good device or use a bus exerciser/master to replay accesses.
• Bus isolation: tri-state peripheral select lines or gate chip select to see whether master recovers.

Step 5 — Instrumentation and metrics

• Add watchdog that detects bus stall and triggers controlled reset; measure time-to-hang, patterns preceding hang.
• Correlate failures with power/temperature/voltage rails.

Expected signatures & root-cause mapping

• Missing ACK/TRDY or perpetual WAIT# → peripheral not responding / stuck FSM or clock gated.
• Data/addr glitches or misaligned BER spikes → alignment/timing violation.
• HREADY stuck low on AHB/AXI → slave not finishing transfer (likely FSM).
• Recovery by peripheral reset → FSM issue; recovery only by power cycle → likely clock/voltage domain or latch-up.

Remediation

• Add alignment checks, bus timeouts and retries, peripheral watchdog/reset paths, ensure clock domains stable during accesses, add handshake/ACK timeout and safe-driver release on error.

This plan isolates each cause via minimal-variable experiments while using bus signal captures (ACK, TRDY, WAIT#, HREADY, CLK, CS, DATA) to map observed failure signatures to root cause.

Direct answer

A pointer-based linked list stores an address in each node's next field, so if the structure (or the image containing it) is relocated, copied to run at a different base address, which is routine when data lives in flash and gets mapped or reflashed at a different address across builds, every stored pointer goes stale unless something walks the whole structure and fixes each one up. An index-based list instead stores each node's next as a small integer, here a 16-bit index, into a single static array of nodes, so the value stays correct no matter where that array itself ends up in memory. The cost is one extra arithmetic step per traversal, turning an index into an address, instead of a bare pointer dereference; the benefit, besides relocation safety, is smaller per-node metadata whenever the array holds no more than 65536 elements, since a 16-bit index is a fraction of a full pointer's width.

Structured elaboration

Approach

• Pointer-based node: struct { int32_t value; struct node *next; }. Traversal is a direct dereference, cur = cur->next.
• Index-based node: nodes live in a fixed-size static array, node_pool[CAPACITY]; next is a uint16_t holding an index into that array, with a reserved sentinel (0xFFFF here) standing in for "no next," since a real array index cannot be negative the way a null pointer can be zero.
• A free list threaded through the same next field (indices, not pointers) gives constant-time allocation and release without ever calling a heap allocator, which matters on targets with no heap at all, or a heap whose fragmentation behavior you don't trust for time-critical code.

#include <stdint.h>

#define NIL 0xFFFFu
#define CAPACITY 8

typedef struct pnode {
    int32_t value;
    struct pnode *next;
} pnode_t;

typedef struct {
    int32_t value;
    uint16_t next;
} inode_t;

static inode_t node_pool[CAPACITY];
static uint16_t free_head = 0;

static void pool_init(void) {
    for (uint16_t i = 0; i < CAPACITY; i++) {
        node_pool[i].next = (i + 1 < CAPACITY) ? (uint16_t)(i + 1) : NIL;
    }
    free_head = 0;
}

static uint16_t pool_alloc(int32_t value) {
    if (free_head == NIL) return NIL;
    uint16_t idx = free_head;
    free_head = node_pool[idx].next;
    node_pool[idx].value = value;
    node_pool[idx].next = NIL;
    return idx;
}

static uint16_t index_list_push_front(uint16_t head, int32_t value) {
    uint16_t idx = pool_alloc(value);
    if (idx == NIL) return head;
    node_pool[idx].next = head;
    return idx;
}

#include <stdio.h>
static void index_list_print(uint16_t head) {
    uint16_t cur = head;
    int steps = 0;
    while (cur != NIL) {
        printf("%d", node_pool[cur].value);
        cur = node_pool[cur].next;
        steps++;
        if (cur != NIL) printf(" -> ");
    }
    printf(" (%d nodes)\n", steps);
}

int main(void) {
    pool_init();
    uint16_t head = NIL;
    int values[] = {30, 20, 10};
    for (size_t i = 0; i < sizeof(values) / sizeof(values[0]); i++) {
        head = index_list_push_front(head, values[i]);
    }
    printf("index-based list: ");
    index_list_print(head);
    printf("sizeof(pnode_t) on this platform = %zu bytes (value=%zu, pointer=%zu)\n",
           sizeof(pnode_t), sizeof(int32_t), sizeof(void *));
    printf("sizeof(inode_t)                  = %zu bytes (value=%zu, index=%zu)\n",
           sizeof(inode_t), sizeof(int32_t), sizeof(uint16_t));
    return 0;
}

Key points

• Relocation safety: an index is only ever meaningful relative to the array's own base, wherever that base happens to be. Copy the whole array and its head index to new RAM, or leave it in place in flash, and every next value stays correct with zero fix-up. A pointer-based structure baked into a flash image needs a loader to walk every pointer and add a relocation offset, or a full relocation table, costing code, time, and RAM the index-based version never spends.
• Metadata size: a 16-bit index caps the structure at 65536 nodes; in exchange it is a fraction of the width of a full pointer on almost any target.
• Extra arithmetic: turning node_pool[idx] into an address is base_address + index \times sizeof(node), which for a statically declared array the compiler folds into a single scaled-index load, effectively one instruction, not a separate multiply and add; a pointer dereference has no arithmetic at all, but also no opportunity to bounds-check before use the way an index can be compared against CAPACITY.

Worked example

Initializing the pool and pushing the values 30, 20, 10 onto an index-based list, then printing it, gives:

index-based list: 10 -> 20 -> 30 (3 nodes)
sizeof(pnode_t) on this platform = 16 bytes (value=4, pointer=8)
sizeof(inode_t)                  = 8 bytes (value=4, index=2)

On this 64-bit build, the pointer-based node is twice the size of the index-based node, almost entirely because of the 8-byte pointer (plus the alignment padding it forces) versus the 2-byte index. On a 32-bit target the pointer would measure 4 bytes instead of 8, narrowing the gap, but the index-based node stays smaller in the same direction regardless of target word size.

Trade-offs & pitfalls

Complexity

Both versions give $O(1)$ insert-at-head and $O(1)$ allocate and free through the free list, and $O(k)$ traversal to the k-th node either way: the algorithmic complexity is identical between the two. This is entirely a constant-factor and safety trade-off, not a difference in Big-O.

Edge cases / pitfalls

• Sentinel collision: using 0 as "no next" for the index version, mirroring a pointer-based NULL, is a classic bug, since 0 is also a perfectly valid array index. An out-of-range sentinel like 0xFFFF, paired with a CAPACITY that never reaches it, avoids the collision.
• Index-width overflow: a 16-bit index silently wraps once the pool exceeds 65535 nodes; if growth past that is possible, the index type has to widen too, which gives back some of the metadata savings rather than just raising CAPACITY.
• Dangling references after relocation are a pointer-only failure mode; the index version cannot have this specific bug by construction, since an index carries no address information to go stale.
• Use-after-free-style bugs still exist for indices, just differently: returning a node to the free list without clearing any external reference to its old index can let a stale next value point at a slot since reused for different data. The fix is the same discipline as with pointers, don't keep an index alive past freeing it; the relocation-safety win here is specific to addresses going stale, not to every class of dangling-reference bug.

The same reasoning outside embedded systems

The index-versus-pointer choice generalizes past flash relocation. General-purpose graph code makes an equivalent trade for different reasons: representing a graph as parallel arrays with integer node indices, a compressed-sparse-row style layout, instead of an object graph of pointer-linked nodes gives better cache locality (sequential array scans instead of pointer chasing) and lets the structure be serialized or memory-mapped straight to a file with no pointer fix-up pass at all, the same "no relocation fix-up needed" property this embedded design relies on, just motivated by cache performance and serialization rather than flash relocation. Game engines and entity-component-system (ECS) frameworks reach for the same "handle instead of pointer" idea for a third reason again: a stable integer handle survives the underlying array being resized or compacted, which a raw pointer into that array would not.

Direct answer

Once you know a partner function is measured on something different from you (speed versus quality or risk, for example), you scope your asks to be small and cheap under their metric, and you change what "status" means when you talk to them: short, action-oriented signals instead of the detailed risk narrative you'd give your own stakeholders. You're not changing what you need, you're changing how you package it so it doesn't read as a tax on the thing they're rewarded for.

Structured elaboration

1. Diagnose the incentive, don't assume it. Confirm what the partner function is actually measured on (deploy velocity, ticket close time, uptime, cost) rather than inferring it from how they push back. Different sub-teams within the "same" function can be measured differently.
2. Scope the ask to the smallest unit that gets you what you need. If they're speed-measured, don't ask for a broad, standing review of everything; ask for a narrow, well-bounded check on the specific surface that carries the risk you actually care about, and let everything else pass without friction.
3. Translate the ask into their currency. Instead of framing a request around your risk language, frame it around what it costs (or saves) them in their terms: incident response hours avoided, rework avoided, a compliance gate they'd otherwise hit later and more expensively.
4. Change the shape of status, not just the ask. For a speed-measured partner, give a compact signal (blocked/not blocked, a count, a single risk flag) they can act on in seconds. Save the fuller narrative for your own stakeholders who need the detail. Sharing the same long-form update with both audiences under-serves the partner who needs to move fast.
5. Keep a floor. Adapting your ask to their incentive has a limit: there's a minimum you can't compromise below without failing your own mandate. Know that floor before the conversation so "scoping down" doesn't quietly become "giving up the requirement."
6. Revisit as trust builds. Early asks are necessarily narrow and low-trust. As the partner sees your asks are well-scoped and your status updates are reliable, you can often widen the ask (a slightly broader review surface, more lead time) because they've learned you're not going to slow them down for nothing.

Worked example

A platform team is measured on release velocity; a security-minded partner function is measured on defect and incident rates. Rather than asking the platform team to route every change through manual security review (a direct tax on their velocity metric), the ask is scoped to only changes that touch a named risk surface, such as authentication or payment code. Everything else ships without added friction. Status to the platform team is a single weekly line: "2 changes in the review queue, 0 blocking, both cleared by Thursday." The fuller write-up, with rationale and residual risk, goes to the security function's own leadership, not to the platform team, because that's not the audience that needs it to act.

Trade-offs & pitfalls

• Pitfall: scoping the ask down so far it stops actually managing the risk it exists to manage. Know your floor before you negotiate.
• Pitfall: assuming the incentive instead of confirming it. Guessing wrong (e.g., treating a team as purely speed-driven when they're also on the hook for a compliance metric) leads to asks that miss what would actually land.
• Pitfall: sending the same status update to every audience. It either over-informs the speed-measured partner (who tunes it out) or under-informs your own stakeholders (who need the detail to make decisions).
• Senior differentiator: treating the ask size and the status format as things you design deliberately around the incentive gap, and revisiting that design as trust changes, rather than a fixed communication style you use with everyone.

Brief difference
Memory-Mapped I/O (MMIO): device registers appear as normal memory addresses; software accesses them with ordinary load/store instructions.
Port-Mapped (Isolated) I/O: device registers live in a separate I/O space; accesses use special CPU I/O instructions (e.g., IN/OUT).

How exposed to software

• MMIO: peripheral registers are mapped into the processor’s physical address space; C reads/writes via volatile pointers.
• Port-mapped: registers are addressed with port numbers and accessed with special assembly or compiler intrinsics that emit IN/OUT.

CPU instruction/semantic differences

• MMIO: standard load/store semantics, affected by memory ordering, caching, and barriers.
• Port-mapped: separate IN/OUT semantics; typically uncached and atomic with different addressing width rules; different compiler support.

Architectures that favor each

• MMIO: ARM Cortex-M, RISC-V, AVR, modern microcontrollers favor MMIO.
• Port-mapped: x86 historically uses port I/O; some older 8/16-bit CPUs (e.g., 8086 family) and niche designs.

Practical advantages / disadvantages

• Address space:
  • MMIO uses regular address space (flexible but consumes address range).
  • Port I/O conserves memory address space but consumes I/O-space.
• Ease of programming:
  • MMIO: simpler in C (volatile pointers), better toolchain support.
  • Port I/O: requires special intrinsics/assembly; less portable.
• Performance:
  • MMIO can benefit from normal instruction pipeline; needs careful barriers to avoid reordering.
  • Port I/O often guarantees uncached, immediate effect; instruction latency varies.
• Tooling:
  • MMIO integrates with debuggers, memory maps, and linker scripts easily.
  • Port I/O is harder to inspect with generic memory viewers; debuggers may need special support.

When I’d choose MMIO
For a new microcontroller peripheral I’d choose MMIO: it’s simpler for firmware, portable across compilers/ISAs, debuggable, and aligns with modern bus architectures (APB/AHB/AXI). I’d only pick port-mapped I/O for legacy ISA constraints or to save scarce address decoding hardware in constrained platforms.

Direct answer
Three boundaries matter most: confidentiality (what's said in a mentoring conversation doesn't automatically become input to a performance review), favoritism (visible time and opportunity should be fair and roughly trackable, not just felt fair), and the evaluator conflict (mentoring someone you also formally evaluate creates a structural incentive problem, since they cannot be fully candid with someone who scores them). The practical fix is not avoiding all overlap, since it is often unavoidable, it is naming the boundary explicitly up front and having a plan for when it blurs.

Structured elaboration

Worked example
Situation: I was mentoring someone I would later be asked to give calibration input on for a promotion cycle.
Task: keep the mentoring relationship honest without compromising the integrity of the eventual evaluation.
Action: I told them directly, early, that promotion calibration might eventually involve my input, so mentoring conversations and evaluation conversations were separate. When something they shared in a mentoring context, a specific technical mistake, later became relevant to an honest performance discussion, I went back to them first rather than using it silently, and asked how they wanted it handled.
Result: the relationship stayed trustworthy because the boundary was named rather than assumed, even though the overlap between mentor and evaluator could not be fully removed.

Trade-offs & pitfalls
Pretending you can be a purely neutral mentor when you structurally have some evaluator influence is dishonest and erodes trust once it surfaces. Over-formalizing boundaries, a written contract for every casual pairing, feels bureaucratic when the stakes don't call for it, so match the formality to the actual overlap: an evaluator relationship needs an explicit conversation, a casual peer pairing usually doesn't. The senior distinction is naming the boundary before it's tested, not scrambling to explain it after a mentee feels burned.

What MISRA C and similar standards are
MISRA C is a set of coding rules aimed at safety, portability and maintainability for C in embedded/safety-critical systems. Similar standards (CERT C, ISO C++ Core Guidelines, AUTOSAR C++14) constrain language features, prescribing required/required-with-justification/prohibitions and recommended practices to avoid undefined/implementation-defined behaviors.

How static analysis, automated checks and reviews reduce risk

• Static analysis: finds undefined behavior, null-deref, uninitialized reads, integer overflows, rule violations early and consistently across toolchains.
• Automated checks (compiler warnings + linters + unit-test/CI hooks): enforce style, enforce MISRA rules automatically on each pull request; prevent regressions.
• Code reviews: capture architecture-level issues, misuse of abstractions, and rationale for deviations that tools can’t judge.

Common MISRA violations I’ve seen

• Implicit conversions between signed/unsigned integers
• Use of dynamic memory in safety-critical code (malloc/free)
• Missing return statements or unreachable code
• Use of complex expressions that depend on sequence points
• Violations around pointer arithmetic and aliasing

Practical incremental adoption

• Start by enabling a subset: enforce high-risk rules first (no undefined behavior, proper initialization).
• Integrate tools into CI and fail-build on new violations only; allow a baseline of existing warnings to be documented.
• Create a deviation/justification process and track exceptions in code (traceable comments and ADRs).
• Triage historical violations: fix high-severity ones, schedule lower ones into sprints.
• Educate team with short workshops and add rule checks to PR templates.

This approach reduces immediate risk while keeping the codebase deliverable.

What a watchdog timer (WDT) is
A WDT is hardware (or sometimes software) timer that forces a system reset if not periodically "kicked" within a configured window. It protects against hangs, live-locks, and certain classes of software faults.

How it improves resilience

• Forces recovery from unresponsive states when normal control flow is lost.
• Acts as last-resort fail-safe when other error handling fails.
• Combined with safe boot and diagnostics, it enables autonomous recovery in field devices.

Safe usage patterns

• Kick from a single, well-defined place (e.g., system supervisor or main control loop) — not scattered across code.
• Use a windowed watchdog when available to detect both stalls and runaway tasks.
• Feed only after completing health checks: scheduler alive, watchdog task heartbeat, memory/stack checks.
• On reset, perform minimal early initialization, check a persistent boot counter or CRCed state, and avoid automatic destructive actions until diagnostics run.
• Use non-volatile logs (with CRC) to record cause of reset and avoid blind loops; limit boot-loop retries with exponential backoff.

Example (C-style supervisor):

// called from main loop or supervisor task
void supervisor_tick(void) {
  if (health_checks_pass()) {
    watchdog_kick();
  } else {
    // log error, attempt controlled recovery
    attempt_recovery();
    // if unrecoverable, let WDT reset
  }
}

How to avoid masking real faults

• Never kick the WDT from ISRs or from many unrelated modules — this hides faults in main code.
• Ensure health_checks verify core subsystems (scheduler, comms, sensors).
• Prefer letting the WDT reset for unrecoverable faults instead of masking by naive kicks.

Common pitfalls

• Resetting without flushing persistent state: losing telemetry/config. Mitigate by atomic writes, journaling, or writing a shutdown marker before critical ops.
• Clearing watchdog prematurely in error paths: e.g., error handler that loops and keeps kicking. Instead, fail fast or escalate.
• Assuming WDT fixes logic bugs: it only recovers from stuck states; bugs causing repeated bad behavior after boot must be addressed (use counters, safe-mode).
• Boot loops: track reset count in RTC/NV and change behavior after N resets (enter safe mode or remote update).

Use WDT as a disciplined fail-safe integrated with health checks, persistent diagnostics, and boot protections to improve system resilience without hiding root causes.

Definition & key idea
A fixed-size memory (object) pool preallocates N blocks of identical size S up front and manages a free list of those blocks. Allocation pops a block; deallocation pushes it back. Common in constrained embedded firmware where malloc/free are undesirable.

Allocation / deallocation complexity

• Both are O(1) — simple pointer update on the free list (no scans or coalescing).
• Deterministic latency (bounded, predictable), ideal for real-time tasks.

Typical metadata overhead

• Often zero extra header per block if the block itself stores the next-pointer when free (single pointer sized, 4 bytes on 32-bit).
• If separate bookkeeping used, overhead ≈ one pointer + small state flags per block.
• Memory wasted = (alignment padding + internal fragmentation) since blocks are fixed-size.

Why good for real-time / embedded

• Predictable timing, no heap fragmentation, low CPU overhead, safe in ISRs if lock-free or with simple spinlock/disable-interrupts.
• Enables constant-time resource acquisition for critical paths.

Common use cases

• Network packet buffers (fixed MTU-sized buffers)
• Object caches (sensor samples, control messages)
• Driver DMA descriptors, thread-safe work item pools

Trade-offs

• Wasted memory if object sizes vary; must size S and N carefully; simpler and more reliable than general allocators for embedded systems.

Approach summary
Two-week experimental validation cycle: rapid learning sprint + iterative test-driven validation (unit → integration → hardware-in-the-loop → interoperability/stress), with clear acceptance criteria for “production-ready.”

Week plan (high-level)

• Day 0–2: Read vendor docs, sample apps, API surface; build a minimal app that advertises and responds.
• Day 3–10: Iterative tests (below), fix issues, expand coverage.
• Day 11–14: HIL regressions, partner interoperability, power & timing acceptance, documentation.

Tests to run

• Unit tests
  • Host-side stubs for BLE API; validate state machines, advertising/connect/disconnect logic.
  • CI-run C unit tests (Ceedling/CMock) for protocol handlers and serialization.
• Integration tests
  • On-target firmware tests exercising stack APIs: GAP/GATT flows, security/bonding, reconnection logic.
  • Automated test harness to run scripted connect/subscribe/notify sequences.
• Hardware-in-the-loop (HIL)
  • Real RF tests with DUT on dev kit: multiple masters/clients, long-duration stability (24–72 h), OTA tests.
  • Power profiling under advertising/connected idle/active notification scenarios.
• Interoperability & compliance
  • BLE sniffer traces to validate timing, MTU, ATT/Handle behavior vs spec.
  • Pairing with phones (iOS/Android) and popular central devices.
• Robustness/stress
  • Fuzz invalid writes, rapid connect/disconnect, malformed packets via controlled sniffer injection.
  • Memory/leak checks, stack overflow under load.
• Regression automation
  • Build-test pipeline that runs a subset of fast hardware tests on every commit.

Hardware & tools

• Vendor dev kit (DUT) + evaluation board with debug access (SWD/JTAG).
• BLE sniffer: nRF Sniffer or Ellisys for packet capture and timing.
• Multiple central devices: Android phone, iPhone, Linux BlueZ host.
• Logic analyzer and debugger (Segger J-Link), oscilloscope for timing checks.
• Power profiler (Monsoon or Otii Arc) for current traces.
• RF chamber or shielding for repeatable RF tests (if available).
• Test automation rig: Raspberry Pi or PC + USB-controlled power switch, scripts to run tests.
• Optional: vendor stack simulator/emulator if provided.

Acceptance criteria (production-ready)

• Functional: All core profile flows pass 100% of test cases (advertise/connect/discover/read/write/notify/indicate, pairing/secure connections).
• Interop: Successful pairing and expected behavior with iOS, Android, and BlueZ; no manual intervention required.
• Stability: No crashes or memory leaks across 72-hour continuous run and >1,000 connect/disconnect cycles.
• Timing/latency: Meet specified connection interval, supervision timeout, and notification latency requirements within 10% margin.
• Power: Measured average and peak currents meet product power budget for defined scenarios.
• Compliance &Traceability: Sniffer traces for representative scenarios match expected ATT/GATT exchanges; documented deviations logged with mitigations.
• Automation & CI: Key unit and smoke hardware tests runnable in CI; regression coverage documented.
• Documentation: Integration notes, known issues, API usage examples, and test reports complete.

Why this works
This cycle balances rapid learning with measurable validation: unit tests validate logic early, integration and HIL expose real stack behavior, sniffer and power tools quantify compliance, and clear acceptance criteria reduce ambiguity before release.