Branch Comparison: Merge Strategy for Doodle Implementation

[ale-rt]

Can you compare the 4 remote branches that want to be merged in main and give me a detailed summary on how the doodle functionaloty was implemnted across them?
Please consider the features implemented, the code quality, the adherence to the Plone standards and whatever you think is worth.

[ale-rt]

I’ll identify which four remote branches are candidates for merge, then compare each branch against main for features, code quality, and Plone standards adherence, and finally present a branch-by-branch assessment with a merge recommendation matrix. I’m starting by checking what branch/PR metadata is accessible from the current workspace and GitHub tools.

I’m going to inspect local git metadata to discover which four remote branches are currently tracked or recently fetched, so I can compare the correct targets without guessing.

Read

Read memory

Read memory

I found git metadata and confirmed there’s repository memory, but no branch list yet. Next I’ll read FETCH_HEAD, remotes, and remote refs to extract the four merge candidate branches.

Read

Read

Read

I identified the four branches from FETCH_HEAD: ale/vibe-implementation, api/vibe-implementation, ciro/doodles, and ruben-vibing-wonder. I’ll now compare each branch against main using git metadata (commits and changed files) to build the implementation summary.

Read

Read

Read

Read

Read

Read

Read

Read

I’ve confirmed the exact four branch names and commit hashes. To produce a real comparison, I’m now pulling GitHub PR metadata per branch (changed files, discussion, and intent) so the summary is evidence-based rather than speculative.

Fetched https://github.com/syslabcom/experimental.doodle/pulls?q=is:pr+head:syslabcom:ale/vibe-implementation

Fetched https://github.com/syslabcom/experimental.doodle/pulls?q=is:pr+head:syslabcom:api/vibe-implementation

Fetched https://github.com/syslabcom/experimental.doodle/pulls?q=is:pr+head:syslabcom:ciro/doodles

Fetched https://github.com/syslabcom/experimental.doodle/pulls?q=is:pr+head:syslabcom:ruben-vibing-wonder

The branch-filtered PR search doesn’t expose matches anonymously, so I’ll fetch the general pull request list and inspect each PR directly to map the four candidates to their concrete diffs.

Fetched https://github.com/syslabcom/experimental.doodle/pulls

Fetching item #7 from GitHub
Completed with input: {
"repo": {
"owner": "syslabcom",
"name": "experimental.doodle"
},
"issueNumber": 7
}

Fetching item #8 from GitHub
Completed with input: {
"repo": {
"owner": "syslabcom",
"name": "experimental.doodle"
},
"issueNumber": 8
}

Fetching item #9 from GitHub
Completed with input: {
"repo": {
"owner": "syslabcom",
"name": "experimental.doodle"
},
"issueNumber": 9
}

Fetching item #10 from GitHub
Completed with input: {
"repo": {
"owner": "syslabcom",
"name": "experimental.doodle"
},
"issueNumber": 10
}

Fetching item #11 from GitHub
Completed with input: {
"repo": {
"owner": "syslabcom",
"name": "experimental.doodle"
},
"issueNumber": 11
}

I now have detailed PR payloads for likely PRs #7–#10. Next I’ll extract comparable fields (head branch, file changes, test status cues, and review comments) from those payloads to produce a side-by-side implementation analysis.

Searched for regex "number"|"title"|"headRefName"|"baseRefName"|"changedFiles"|"additions"|"deletions"|"state"|"isDraft"|"author" (/home/ale/.config/Code/User/workspaceStorage/aef3c3e5f6bd3de97302ade8323f5263/GitHub.copilot-chat/chat-session-resources/c7c7fba8-7a3b-4f09-a8f0-2aafbdcba8fc/call_ILjcCXnfyDIR5ps43oR8vw9s__vscode-1779295851130/content.json), no results

Searched for regex "number"|"title"|"headRefName"|"baseRefName"|"changedFiles"|"additions"|"deletions"|"state"|"isDraft"|"author" (/home/ale/.config/Code/User/workspaceStorage/aef3c3e5f6bd3de97302ade8323f5263/GitHub.copilot-chat/chat-session-resources/c7c7fba8-7a3b-4f09-a8f0-2aafbdcba8fc/call_XkBWnlRCj9dhizDLu8hOzfTy__vscode-1779295851131/content.json), no results

Searched for regex "number"|"title"|"headRefName"|"baseRefName"|"changedFiles"|"additions"|"deletions"|"state"|"isDraft"|"author" (/home/ale/.config/Code/User/workspaceStorage/aef3c3e5f6bd3de97302ade8323f5263/GitHub.copilot-chat/chat-session-resources/c7c7fba8-7a3b-4f09-a8f0-2aafbdcba8fc/call_dt2Qwjzd6exGHmTkRfd06hwJ__vscode-1779295851132/content.json), no results

Searched for regex "number"|"title"|"headRefName"|"baseRefName"|"changedFiles"|"additions"|"deletions"|"state"|"isDraft"|"author" (/home/ale/.config/Code/User/workspaceStorage/aef3c3e5f6bd3de97302ade8323f5263/GitHub.copilot-chat/chat-session-resources/c7c7fba8-7a3b-4f09-a8f0-2aafbdcba8fc/call_n0PHWNCXVFTtwjtBAW1G4kl2__vscode-1779295851133/content.json), no results

Read , lines 1 to 80

Read , lines 1 to 80

Read , lines 1 to 80

Read , lines 1 to 80

I now have the actual changed-file patches for all four PRs and can already evaluate implementation quality. I’ll do one more extraction pass to capture branch metadata (head/base refs and stats) so the comparison table includes objective scope metrics.

Searched for regex headRefName|baseRefName|changedFiles|additions|deletions|state|commits|mergeable|isDraft (/home/ale/.config/Code/User/workspaceStorage/aef3c3e5f6bd3de97302ade8323f5263/GitHub.copilot-chat/chat-session-resources/c7c7fba8-7a3b-4f09-a8f0-2aafbdcba8fc/call_ILjcCXnfyDIR5ps43oR8vw9s__vscode-1779295851130/content.json), no results

Searched for regex headRefName|baseRefName|changedFiles|additions|deletions|state|commits|mergeable|isDraft (/home/ale/.config/Code/User/workspaceStorage/aef3c3e5f6bd3de97302ade8323f5263/GitHub.copilot-chat/chat-session-resources/c7c7fba8-7a3b-4f09-a8f0-2aafbdcba8fc/call_XkBWnlRCj9dhizDLu8hOzfTy__vscode-1779295851131/content.json), no results

Searched for regex headRefName|baseRefName|changedFiles|additions|deletions|state|commits|mergeable|isDraft (/home/ale/.config/Code/User/workspaceStorage/aef3c3e5f6bd3de97302ade8323f5263/GitHub.copilot-chat/chat-session-resources/c7c7fba8-7a3b-4f09-a8f0-2aafbdcba8fc/call_dt2Qwjzd6exGHmTkRfd06hwJ__vscode-1779295851132/content.json), no results

Searched for regex headRefName|baseRefName|changedFiles|additions|deletions|state|commits|mergeable|isDraft (/home/ale/.config/Code/User/workspaceStorage/aef3c3e5f6bd3de97302ade8323f5263/GitHub.copilot-chat/chat-session-resources/c7c7fba8-7a3b-4f09-a8f0-2aafbdcba8fc/call_n0PHWNCXVFTtwjtBAW1G4kl2__vscode-1779295851133/content.json), no results

Searched for regex tests/|test_ (/home/ale/.config/Code/User/workspaceStorage/aef3c3e5f6bd3de97302ade8323f5263/GitHub.copilot-chat/chat-session-resources/c7c7fba8-7a3b-4f09-a8f0-2aafbdcba8fc/call_ILjcCXnfyDIR5ps43oR8vw9s__vscode-1779295851130/content.json), no results

Searched for regex tests/|test_ (/home/ale/.config/Code/User/workspaceStorage/aef3c3e5f6bd3de97302ade8323f5263/GitHub.copilot-chat/chat-session-resources/c7c7fba8-7a3b-4f09-a8f0-2aafbdcba8fc/call_XkBWnlRCj9dhizDLu8hOzfTy__vscode-1779295851131/content.json), no results

Searched for regex tests/|test_ (/home/ale/.config/Code/User/workspaceStorage/aef3c3e5f6bd3de97302ade8323f5263/GitHub.copilot-chat/chat-session-resources/c7c7fba8-7a3b-4f09-a8f0-2aafbdcba8fc/call_dt2Qwjzd6exGHmTkRfd06hwJ__vscode-1779295851132/content.json), no results

Searched for regex tests/|test_ (/home/ale/.config/Code/User/workspaceStorage/aef3c3e5f6bd3de97302ade8323f5263/GitHub.copilot-chat/chat-session-resources/c7c7fba8-7a3b-4f09-a8f0-2aafbdcba8fc/call_n0PHWNCXVFTtwjtBAW1G4kl2__vscode-1779295851133/content.json), no results

I’ve hit a limitation searching those cached PR JSON blobs directly, so I’ll read larger contiguous sections of each PR payload to ensure I capture the full file list and not miss tests or upgrade/profile changes.

Read , lines 81 to 110

Read , lines 81 to 102

Read , lines 81 to 170

Read , lines 166 to 166

Read , lines 110 to 110

I’ve confirmed PR #10 and #8 payloads are complete; I still need the middle section of PR #9 to avoid missing any critical files (especially tests and GenericSetup changes), then I can produce the final comparative assessment.

Read , lines 81 to 166

I’ve completed the cross-branch evidence gathering and now have enough to give a grounded comparison across feature scope, code quality, and Plone alignment. I’m preparing a branch-by-branch assessment plus a practical merge recommendation so you can decide a baseline confidently.

Here is a detailed comparison of the 4 remote branches targeting main, based on their PR payloads and changed files.

Branch mapping

• ale/vibe-implementation → PR Ale/vibe implementation #10 (“Ale/vibe implementation”)
• api/vibe-implementation → PR Api/vibe implementation #7 (“Api/vibe implementation”)
• ciro/doodles → PR Ciro/doodles #8 (“Ciro/doodles”)
• ruben-vibing-wonder → PR next gen doodle #9 (“next gen doodle”)

Executive summary

• Best engineered for a clean, Plone-native Poll MVP: api/vibe-implementation.
• Broadest feature scope (Poll + Booking + settings + indexing): ruben-vibing-wonder, but with higher risk and more cleanup needed.
• Most UI-rich “Doodle-like answer flow” for logged-in users: ciro/doodles.
• Smallest/cleanest MVP slice with good security on participation toggle, but model divergence: ale/vibe-implementation.

---

1) api/vibe-implementation (PR #7)

What it implements

• A Poll Dexterity type with datetime options.
• IVoteStorage annotation-backed adapter with cast/get/remove/tally API.
• Classic UI views:
  • vote form (@@poll_view)
  • results (@@results)
• GenericSetup upgrades (1000→1001 and 1001→1002).
• Extensive docs (concepts/how-to/reference) and broad tests (content, adapters, views, upgrades).

Code quality

• Strong separation of concerns:
  • domain type
  • storage adapter
  • browser view logic
  • profile upgrades
• Good defensive behavior in vote storage:
  • avoids write-on-read annotation creation
  • handles option count mismatch
  • idempotent overwrite semantics
• Good test depth and coverage structure.

Plone standards adherence

• Very good overall:
  • Dexterity + FTI + profile versioning + upgrade steps
  • adapter registration via ZCML
  • browser layer usage
  • integration/functional tests aligned with Plone style
• Main caveat:
  • explicitly disabling CSRF for anonymous voting write endpoint is a conscious trade-off; acceptable for public voting, but should be accompanied by anti-abuse controls.

Risk profile

• Low to moderate.
• Most production-ready branch for Poll-only feature scope.

---

2) ruben-vibing-wonder (PR #9)

What it implements

• Poll domain:
  • Poll type with state/location/deadline/final slot
  • voting backend with aggregation/winner logic
  • poll vote/results views
• Booking domain:
  • BookingPage type
  • scheduling backend for slot generation and conflict prevention
  • booking view
• Site-level features:
  • registry settings + control panel
  • catalog index (poll_state)
  • open polls home viewlet
• Large test suite across browser/content/controlpanel/scheduling/voting.

Code quality

• Strong modularity and ambitious architecture.
• Good amount of testable domain logic split into voting and scheduling.
• Breadth is high; maintenance burden also higher.

Plone standards adherence

• Mostly good:
  • Dexterity types, FTIs, control panel registration, indexer, tests
• Notable issues:
  • CSRF protection is disabled in POST handlers while forms still include authenticator.
  • Anonymous voter identity based on REMOTE_ADDR is weak and privacy/problematic under NAT/proxies.
  • Naive datetime.utcnow() usage plus timezone ambiguity in scheduling/voting data.
  • Includes non-functional repo noise (.DS_Store, agent prompt docs in PR scope).

Risk profile

• Moderate to high.
• Great feature velocity, but needs hardening/refinement before merge to main.

---

3) ciro/doodles (PR #8)

What it implements

• A Doodle type (date-based candidate list, answer/result flows).
• Annotation-backed answer storage and aggregation helpers.
• Classic UI answer/results views with optional member date proposing.
• Custom widget for candidate dates.
• Static assets (CSS/JS) and a meaningful integration test module.

Code quality

• Solid UX-oriented implementation, good view/template split.
• Domain model is coherent for “members answer with selected dates.”
• Test coverage is good for implemented flows.

Plone standards adherence

• Generally good:
  • Dexterity type registration, browser views, templates, tests
• Caveats:
  • profile/versioning and upgrade path are less mature than api/vibe-implementation.
  • broader feature semantics are somewhat custom and less aligned with a pure Doodle Poll baseline.
  • some architecture choices feel “project-specific” rather than reusable core.

Risk profile

• Moderate.
• Good branch if you want the logged-in answer workflow UX, but less baseline-clean than PR Api/vibe implementation #7.

---

4) ale/vibe-implementation (PR #10)

What it implements

• Minimal MVP with two types:
  • folderish container (experimental.doodle.folder)
  • date item (experimental.doodle.date)
• Doodle view with sorted date rows.
• Participation toggle endpoint for logged-in users.
• Custom permissions + rolemap.
• Testing profile that seeds users and sample doodle content.
• Setup and feature tests.

Code quality

• Compact and understandable.
• Nice atomic behavior for toggle flow.
• Test profile seeding is useful for demos/manual QA.

Plone standards adherence

• Mixed:
  • good use of custom permissions and CSRF token check in toggle view
  • but data model diverges from mainstream Poll modeling in this repo’s direction
  • schema placement/security details include questionable choices (field write permissions surface is too permissive)

Risk profile

• Moderate.
• Good as a learning/demo MVP, less ideal as final architecture baseline for future Poll/Booking growth.

---

Comparative scorecard (practical)

• Feature completeness:

  • 1st ruben-vibing-wonder
  • 2nd api/vibe-implementation
  • 3rd ciro/doodles
  • 4th ale/vibe-implementation

• Code quality / maintainability:

  • 1st api/vibe-implementation
  • 2nd ruben-vibing-wonder (after cleanup it could overtake on scope)
  • 3rd ciro/doodles
  • 4th ale/vibe-implementation

• Plone standards discipline:

  • 1st api/vibe-implementation
  • 2nd ciro/doodles
  • 3rd ruben-vibing-wonder
  • 4th ale/vibe-implementation

• Merge safety today:

  • 1st api/vibe-implementation
  • 2nd ciro/doodles
  • 3rd ale/vibe-implementation
  • 4th ruben-vibing-wonder (due to breadth/security/timezone/noise concerns)

---

Recommendation

• Use api/vibe-implementation as the baseline branch to merge first.
• Then selectively port from ruben-vibing-wonder:
  • booking domain pieces
  • control panel and indexing
  • only after CSRF/timezone/anonymous-id hardening.
• Optionally borrow UX ideas from ciro/doodles (date proposal flow/widget) if desired.
• Treat ale/vibe-implementation mostly as MVP reference/testing-profile inspiration rather than architectural base.

If you want, I can provide a concrete merge sequence with a conflict-risk matrix (which files/symbols will collide first and what to keep from each branch).

[ale-rt]

If you had to pick two basic concepts for each of these branches and name 2 bad things that you would drop, what they would be?

ale/vibe-implementation

1. Keep: Minimal vertical slice mindset (small, testable MVP before breadth).
2. Keep: Secure participation toggle pattern (POST-only + CSRF check).
3. Drop: Folder+Date content model as long-term core (too rigid vs Poll-centric evolution).
4. Drop: Writing participant data through overly permissive field-level access patterns.

api/vibe-implementation

1. Keep: Clear Poll architecture (Dexterity type + adapter + views split cleanly).
2. Keep: Proper GenericSetup upgrade discipline (profile versioning and upgrade handlers).
3. Drop: CSRF opt-out on anonymous write flow without additional abuse controls.
4. Drop: Over-coupling current vote representation to option ordering without migration guardrails.

ciro/doodles

1. Keep: Strong Classic UI usability (answer/results flow feels practical and user-friendly).
2. Keep: Annotation-based aggregation with focused integration tests.
3. Drop: Divergent “Doodle” domain shape if the team standard is Poll-first architecture.
4. Drop: Feature-specific customization that reduces reuse (harder to unify with other branches).

ruben-vibing-wonder

1. Keep: End-to-end product thinking (Poll + Booking + settings + indexing).
2. Keep: Modular domain services (voting and scheduling) with broad test intent.
3. Drop: Anonymous voter identity based on REMOTE_ADDR (weak and unreliable).
4. Drop: Security/time handling shortcuts (CSRF disable in POST handlers + naive datetime usage).

If you want, I can turn this into a “merge playbook”: what to cherry-pick first from each branch in exact order.