Obsidian Community Check

Stable Release Recognition

Read Release Process for the canonical publication and asset checks. Use this mode only after the target's release workflow and non-draft, non-prerelease GitHub Release have been verified, including the canonical assets and downloaded manifest version. Reuse their successful evidence; resolve the published tag's commit, not its annotated tag-object SHA or the source parent before packaging.

1. Open the authenticated Personal Assistant account page:

   https://community.obsidian.md/account/plugins/personal-assistant

2. Inspect Current release and Reviews. Reuse a release row matching Version: <target-version> and the published tag commit. Do not reuse a Preview or another version. If a matching row is Pending, poll it instead of submitting again; if Completed, review its findings and completion conditions below before deciding whether any refresh is needed. Stop and diagnose a matching Failed review or Error; do not repeatedly submit the same release to bypass findings.

3. If no matching release check exists, verify the visible control Check for new releases and click it. This submission is included in an authorized stable publication or an explicit request to check/refresh release recognition. A read-only status request does not authorize it. Follow any visible intermediate confirmation only within that same scope.

4. Re-read the account page and inspect the matching release review. Require Version: <target-version>, a commit link resolving to the published tag commit (or a visible SHA prefix matching it), and status Pending, Completed, or Failed. Stop on version/commit mismatch.

5. Apply the polling and findings rules below to this release row. Complete only when it is Completed with no Error, Current release shows the target version, and No release matches your manifest version is absent. If master's manifest has advanced to a different version, report the mismatch; do not trigger or claim the other version as the requested one.

Use only the authenticated browser and observed page controls. The same login/security/CAPTCHA BLOCKED rules apply; do not invent an API or CLI or extract browser sessions for CI. Clicking the button, clearing the banner, or source preview completion alone is insufficient. Report GitHub publication separately when recognition is pending or blocked, retain the handoff page, and resume this check without republishing or changing the tag. Hosted recognition does not prove client installation or update delivery.

For a confirmed code defect after publication, follow the runbook's Recovery: fix on master and use a new higher patch release within authorized scope. Preserve the existing release and tag. A pending check or unavailable login/network access only needs resumption of this existing release's recognition.

Short-Batch Polling

• Reload and inspect in batches of at most six iterations or about 30 seconds.
• After each batch, re-read the current tab state and yield a progress update. Do not run one blocking 90-second loop.
• Stop immediately when the exact matching row changes to Completed or Failed.
• Stop after about 90 seconds total unless the user requested a longer wait. If still Pending, keep the tab open and report incomplete status.
• If browser security blocks later polling, preserve the already-verified submitted row and report the final state as unknown; do not reopen a long loop from scratch.
• Report partial categories visible during Pending as incomplete.
• In an authorized stable publication, continue observing a healthy pending release check beyond the default 90-second standalone-check limit. Poll at reasonable intervals and report meaningful changes; do not end the flow as complete while the target release is pending.

Result Rules

• Treat visible Error findings as release blockers per AGENTS.md.
• Report warnings concretely without calling the scan failed unless the page says Failed or shows an Error.
• Do not claim PASS until the exact commit-matched row is Completed and all visible findings were reviewed.
• Do not use hosted completion as evidence that the local source scan ran.

Output

Community check:
- Mode: preview / release
- Target version: `<stable version or n/a>`
- Ref: `<branch/tag/sha>`
- Intended local SHA: `<full sha>`
- Remote-scannable SHA: `<full sha>`
- Page commit: `<visible sha>`
- SHA match: yes / no
- Status: Pending / Completed / Failed / BLOCKED
- Findings:
  - PASS: `<category>` - Pass
  - FAIL: `<category>` - Error (release blocker)
  - WARNING: `<category>` - Warning
- Complete: yes / no
- GitHub publication: verified / unverified / n/a
- Official recognition: verified / Pending / Failed / BLOCKED / n/a
- Current release: `<visible version or unavailable>`
- Local source scan: `<separate result or not run>`
- Browser tab: kept open / closed

Related Skills

• Use obsidian-test-vault-smoke for local validation and app smoke.
• Use obsidian-ios-real-device-smoke for mobile validation.
• Use personal-assistant-review for code-level review gates.
• Use stable-release for the full authorized stable publication flow.