git_admin/obsidian-vault
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

[2026-06-25] eagle: family/how-to/htpc-emulators-setup.md family/how-to/htpc-gaming-plans.md family/how-to/kraken-access.md family/how-to/openmediavault-rpi5.md family/how-to/time-machine.md family/how-to/wireguard-vpn.md personal/documents/todo-list.md personal/plans/extract-stable-prompt-blocks.md personal/plans/hermes-whale-system-prompt.md personal/plans/thread-scoped-memory.md

Browse Source
This commit is contained in:
Alexey Martemyanov
2026-06-25 11:19:35 +06:00
parent 213ed1a1fa
commit ab51b151ed
30 changed files with 3141 additions and 510 deletions
Download Patch File Download Diff File Expand all files Collapse all files
work/ashby-reviews/EP2-Candidate-848-review.md
+70
View File
@@ -0,0 +1,70 @@
# EP2 TD Review - Candidate 848
## Scores
1. **Does the solution proposed effectively solve the goal of the project?**
**3**
Yes. The proposal covers the actual MVP: fetch and store TDS with ETag validation, generate third-party WebKit content rules through TrackerRadarKit, support a current-site protection toggle, reload after protection changes, and provide an allowlist screen. It also starts from `BareBonesMobileBrowser`, which matters. This is not written as if the candidate can simply drop into the full DuckDuckGo browser architecture unchanged.
2. **Can they break down the project and extract what's important and de-risk the project?**
**3**
This is one of the stronger parts of the submission. The candidate identifies the places where this feature can fail in ways users would actually notice: first navigation before rules are installed, offline first launch, failed TDS download, failed rule compilation, allowlist state drifting away from compiled state, cache misses, and WebKit's rule-count ceiling. The embedded TDS baseline is the right call. It means first launch with no network still has a protected path, which was the big calibrated gap in Candidate 7a2.
The phased plan is also sensible: prove blocking behavior first, then build the data lifecycle, then the toggle and allowlist UI.
3. **Are different approaches being considered with pros/cons and are the choices justified?**
**3**
The tradeoff analysis is specific and useful. They explain why `WKContentRuleList` fits better than Safari extensions, `WKNavigationDelegate` interception, `NSURLProtocol`, or DNS/VPN filtering. They also compare ETag refresh against always downloading, compiled-list lookup against recompiling, exact-host allowlisting against eTLD+1, embedded TDS against download-only startup, and fail-closed behavior against best-effort behavior.
The choices are tied to real failure modes, not just generic pros/cons. That is exactly what I want from this kind of technical design.
4. **Are they able to technically apply good practices to solve the problem and demonstrate they understand the language/platform?**
**2**
The platform understanding is clearly strong. Good signals include `WKContentRuleListStore` lookup before compile, deterministic identifiers that include the inputs affecting rule output, off-main TDS decoding / JSON encoding / rule compilation, commit-after-compile allowlist mutations, atomic TDS+ETag persistence, and a behavioral test strategy based on observing whether a controlled tracker endpoint receives a request.
The concurrency point is worth being precise about: the candidate does **not** propose compiling rules on the main thread. The submission explicitly says JSON encoding and compilation run off the main thread, with only `userContentController` application and UI work on the main actor. Given the TDS size and compile cost, that is the right direction.
I am still scoring this as a `2` rather than a `3` because the implementation handoff is not quite concrete enough for the starter app. The original prompt asks for enough detail that another engineer with zero context could implement tracker blocking. The design says the first navigation is gated behind `.ready`, but it does not spell out how `BareBonesMobileBrowser` actually enforces that: where a pending URL is stored, how address-bar submissions are blocked or queued, what happens to back/forward/reload while `.loading`, and whether this sits in a view model, coordinator, or navigation delegate. For a browser, that wiring is not a small detail. It is the part that prevents the user from accidentally loading before rules are applied.
Two other details should be treated as decisions needing approval rather than implementation defaults: raising the scaffold's deployment target, and offering a catastrophic "Continue without protection" path.
5. **Is the document well-structured and easy to understand/read?**
**3**
The document is dense, but it is dense in a useful way. It moves cleanly from problem statement to risks, decisions, scope, architecture, flows, storage, concurrency, UI states, and testing. The tables and scenario matrix make the failure behavior easy to audit.
## Total
**14 / 15**
## Overall Recommendation
**3 - Yes**
## Feedback to Share With Candidate
Strong submission overall. The embedded TDS baseline, deterministic `WKContentRuleListStore` identifiers, lookup-before-compile path, off-main JSON/rule-list work, and commit-after-compile allowlist transaction are all solid choices for this feature. They show you understood that this is not just about generating rules. It is about keeping the applied rule list, stored inputs, and UI state consistent even when downloads or compiles fail.
The test plan is also a good sign. Verifying tracker blocking by checking whether a controlled endpoint receives a request is the right kind of proof here, since WebKit does not give us a neat callback for blocked subresources.
The main thing I would tighten before implementation is the BareBones integration detail. The design says navigation is gated behind `.ready`, but I would like to see the exact mechanics: where the pending navigation lives, how address-bar submits/back-forward/reload are handled while rules are compiling, and which object owns that state. That is the bit that makes the privacy guarantee real in the starter browser.
A couple of policy-ish items also need clearer framing. Moving off the scaffold's iOS 13 target may be reasonable, but it should not be assumed as part of the technical path. Same for the catastrophic "Continue without protection" option: that needs product/security agreement, not just an implementation decision.
## Calibration Notes
Compared with Candidate 7a2, this submission closes the main calibrated gaps:
- It handles first launch with no network by bundling an embedded TDS baseline.
- It discusses `WKContentRuleListStore` reuse explicitly and designs identifiers around the inputs that affect compiled output.
- It treats allowlist changes as a state consistency problem, not just a UI toggle.
- It includes recovery paths for bad downloads, bad compiles, stale cache, and catastrophic store failure.
- It considers exact-host allowlisting and validates that choice against DuckDuckGo behavior.
The score comes down on technical practices because the design stops one step short of showing how the loading gate is enforced in the actual starter browser UI. The idea is right. The integration detail is the missing piece.
Against the original prompt, the submission covers the requirements well: TDS download/storage, third-party-only blocking, allowlist toggle and reload, allowlist screen, scope, tradeoffs, error handling, performance, architecture, and testing. The main prompt gap is the final instruction: the document should be detailed enough for an engineer with zero context to implement tracker blocking. The core design is there, but the exact starter-app integration path is still too implicit.
work/ashby-reviews/EP2-prompt.md
+25
View File
@@ -0,0 +1,25 @@
# EP2 Prompt
## Background & Requirements
We are building a privacy focused browser. We already have the basic elements of a browser (a web view, address bar, back and forward buttons) and now need to extend that to add a tracker blocker MVP.
This should:
- Handle download and storage of the Tracker Radar data.
- Implement basic tracker blocking (third party only) using `WKContentRuleList` & `TrackerRadarKit`. Outline any challenges that come with this approach, and how you would solve them.
- From Main browser view, user should be able to toggle protection for a given website with a button (which adds/removes that website to/from the allowlist). After that, website should automatically reload with, or without protection.
- Allow the user to see which websites have tracker blocking disabled, by navigating to a screen that has a simple list of domains coming from the allowlist.
There is more information about tracker blocking in the attached Tracker Blocking Background Information document. Please use the Tracker Radar data: [https://github.com/duckduckgo/tracker-radar](https://github.com/duckduckgo/tracker-radar) which is available via [https://staticcdn.duckduckgo.com/trackerblocking/v2.1/tds.json](http://staticcdn.duckduckgo.com/trackerblocking/v2.1/tds.json) (versioning is done with ETags), on iOS you can use the existing TrackerRadarKit: [https://github.com/duckduckgo/TrackerRadarKit](https://github.com/duckduckgo/TrackerRadarKit)
Think of this as a MVP to de-risk the project. Ideally what you create is something that can be expanded and collaborated on, so it's worth putting some thought into the architecture of the application, how to handle errors and possible performance impact.
The template below is a guide to what we are looking to understand with a Technical Design document. At DuckDuckGo we work asynchronously, so the goal of our Technical Design is to:
- Create and de-risk a plan of attack
- Build buy-in into the plan, backed by reasoning and research
Following the template below, we would like to understand how you plan to break the problem down (including clarifying what is in and out of scope), what the pros, cons and tradeoffs of each approach are, what you'd ultimately recommend and how you plan to test it.
Please note that the Technical Design document should be at a level of detail that allows another engineer with zero context to implement tracker blocking.