padlet-access-check

name	padlet-access-check
description	Verify whether a Padlet board can be read and whether posting appears possible before any live write; when publishing for real, follow the Live posting pitfalls section (minimized composer, guest modal, section targeting, a11y quirks). Use when inspecting a Padlet link, client-side rendering, section add-post controls, or completing a real post when the user asks.

Padlet Access Check

Overview

Check Padlet boards safely before any live action. Confirm read access, find whether content is loaded dynamically, and verify whether a section can open the post composer without publishing.

Workflow

1. Open the Padlet URL.
2. Check whether static HTML contains real content or only shell markup.
3. If the page is mostly a shell, inspect Padlet network/API data or use a real browser snapshot.
4. Confirm whether section-level Add post controls are visible.
5. If the user only asked for feasibility, stop after the composer opens.
6. Publish only when the user explicitly asks for a real post.
7. If you publish for real, read Live posting pitfalls below so you do not treat a successful post as a failure (or the reverse).

Read Access

• Start with the page URL and basic HTML fetch.
• Expect many Padlet pages to render content client-side. A title alone does not mean the board body was extracted.
• Look for signs like a diagnostics placeholder, an empty #app, or preload links to Padlet API endpoints.
• If shell-only HTML appears, inspect network/API requests or use a browser tool to render the page.

Dynamic Content

• Prefer browser automation when the user needs confidence about what a real viewer can see.
• Watch for endpoints such as:
  • padlet_starting_state
  • wishes
• Use them to confirm board metadata, sections, and posts when the page HTML does not contain the body.
• Treat API discovery as read-only unless the user clearly asks for a write action.

Posting Check

• Use a real browser snapshot to find:
  • global Post button
  • section-level Add post to this section button
  • section heading text
• To confirm posting is possible without posting:
  • click the section add-post button
  • verify the composer opens
  • verify subject/body inputs appear
  • verify the selected section matches the requested section
  • stop there
• Do not click Publish unless the user explicitly asks for a real post.

Live posting pitfalls (do not misread the UI)

These behaviors showed up in real browser automation (e.g. Playwright on Korean UI). Treat them as normal so the next run does not stop early or duplicate posts unnecessarily.

Many identical “add post” controls

• Every section has a control like 이 섹션에 포스트 추가 (or locale equivalent). The wrong section is easy to click.
• Prefer the add-post control that sits under the same block as the target section heading (e.g. Q&A), or use stable test ids when available (e.g. Q&ASectionAddPostButton for the Q&A section on some boards).
• After opening the composer, confirm 현재 게시물 섹션은 …입니다 (or equivalent) names the correct section before typing.

Minimized composer / floating draft after “Publish”

• After 게시 / Publish, the new card may not appear immediately inside the section list. Instead, the board can show a minimized control such as 「{title} 게시물 작성기 열기」 (composerModalMinimizedButton).
• That usually means the draft is still in a compact composer state, not that publishing “did nothing.”
• Remediation: click that minimized button to expand the composer, then click 게시물 게시 / publishPostButton again if needed until the card appears in the section’s article list in the snapshot.

Guest name modal (anonymous contributors)

• Anonymous sessions may show 게스트 이름 업데이트 with a suggested name and 완료 (surfaceGuestIdModalDoneButton).
• Until 완료 is clicked, the post may not fully land as other readers expect; do not report “done” if this dialog is still open.
• Mention in the report that attribution was guest/anonymous when relevant.

Title-only vs body and accessibility snapshots

• 게시물 게시 can become enabled after only the 제목 (subject) field is filled; body may still show the placeholder line (e.g. 아름다운 내용을 적어보세요…) in the accessibility tree even though publish is allowed.
• Do not infer “body is filled” from the snapshot alone; if the user asked for specific body text, use the rich editor (surfacePostRichEditor / focused contenteditable) and verify in a follow-up snapshot or by reading the posted card.
• Generic browser_type / role-based typing may target the wrong empty paragraph elsewhere on the page. Prefer clicking the rich editor first, then typing, or use a small page snippet scoped to the composer.

Verifying success

• Do not rely on a single substring search (e.g. "test") across the whole snapshot: it can match buttons, minimized chrome, or unrelated text.
• Confirm success by finding an article / card under the correct section’s content area with the expected title or body and a recent timestamp.
• Re-snapshot after expand second publish and after guest 완료 if that flow appeared.

Retries and duplicates

• Failed or ambiguous attempts often leave multiple cards with the same title. That is a retry artifact, not proof the first click failed.
• If the user wanted a single post, say clearly that duplicates may exist and should be deleted manually on the board unless they ask the agent to remove extras.

Safety Rules

• Do not create, edit, or publish live Padlet content without explicit user instruction.
• If the user asks only whether posting is possible, open the composer and stop.
• If the board is writable but identity or attribution matters, mention whether the current session appears anonymous or signed in.
• If access fails, report whether the blocker is rendering, permissions, login, or another gate such as CAPTCHA.

Output

Report the result in this order:

1. Whether the board is readable.
2. Whether content required dynamic/API rendering.
3. Whether the requested section exists.
4. Whether the add-post composer opens for that section.
5. Whether publishing appears possible, without publishing.

Playwright

• Use the playwright skill when browser interaction is needed.
• Re-snapshot after opening the board and again after opening the composer.
• Refer to sections and buttons by their visible labels to avoid acting on the wrong section.
• Useful test ids observed on Padlet (may vary by layout/locale): Q&ASectionAddPostButton, surfacePostComposerEditorSubjectInput, surfacePostRichEditor, publishPostButton, composerModalMinimizedButton, surfaceGuestIdModalDoneButton.