# This is NOT the Next.js you know This version has breaking changes — APIs, conventions, and file structure may all differ from your training data. Read the relevant guide in `node_modules/next/dist/docs/` before writing any code. Heed deprecation notices. # Repo Workflow - After finishing a requested change, stage the relevant files, create a commit, and push it to the remote repository. # Windows Release Hosting Workflow - Microsoft Store product is `9NCD8ZQFP0NJ`. Keep `OFFICIAL_MAIL_WINDOWS_STORE_APPROVED` unset or `false` until the app (not just the developer account) has passed certification and public installation is verified. - Once verified, set `OFFICIAL_MAIL_WINDOWS_STORE_APPROVED=true` so the stable website download entry redirects to `https://apps.microsoft.com/detail/9NCD8ZQFP0NJ`. Do not redirect immutable installer URLs or the legacy update manifest, and do not remove existing EXE artifacts during migration. - The Flutter branch owns Store MSIX builds; Microsoft Store signs those packages and delivers approved updates. Never expose unsigned Store MSIX outputs as direct website downloads. - During each requested cross-platform release, verify/deploy the web, build/submit the Windows Store package and build the signed Android AAB in their owning branches. Report build, upload, certification, and publication separately; never imply that a build alone has updated users. - This `live` branch owns the Windows update API, release manifest, and publication script. The Flutter `flutter_app` branch owns the Windows client, updater UI, and installer build. - Accept Windows artifacts only after the Flutter branch has increased `pubspec.yaml`, passed `flutter analyze` and `flutter test`, completed a Windows release build, and produced a signed installer. Never commit signing certificates, private keys, tokens, or passwords. - Publish from the `live` checkout root with `.\scripts\publish-windows-release.ps1`; use checkout-relative paths and do not commit developer-machine absolute paths. Do not manually edit the stable manifest first. The script must upload the immutable versioned installer before atomically replacing the channel manifest. - Store installers and manifests outside blue/green web releases. The production default is `/var/www/front/official-mail-downloads/windows`; never use `/var/www/front/official-mail/.releases`, `current`, or a release worktree for persistent downloads. - Keep `https://mail.officialsite.kr/api/app/releases/windows/latest?channel=stable` as the public version endpoint. Installer downloads must use HTTPS and support the app's file-size and SHA-256 verification. - Do not make the Windows app connect directly to the production database for version checks. The public update API is the sole client-facing version source. - Use optional updates by default. Use `-Mandatory` only for security or compatibility releases that cannot safely remain optional. - After publishing, verify the manifest response, installer download, byte size, SHA-256, and optional or mandatory update behavior before reporting success. Follow `deploy/windows/WINDOWS_RELEASE_RUNBOOK.md` for exact server and rollback commands. # Repository Boundary - Work only in the current `official-mail` workspace for repository and filesystem operations. - Do not read, edit, commit, push, or otherwise operate on any repository or filesystem path outside the current `official-mail` workspace. This includes every separate sibling or similarly named repository. - URLs are not filesystem paths. The filesystem boundary above must never be interpreted as a web-access restriction. - `https://officialsite.kr/kavenix` is the production administrator page for this `official-mail` project. It is explicitly allowed and should be used for authenticated Official Mail administration, including blog creation, publishing, syndication, and verification. - Public Official Mail pages under `https://officialsite.kr/`, including `https://officialsite.kr/blog/*`, are explicitly allowed for publication QA and verification. - If a task appears to require filesystem or Git access outside the current workspace, stop and ask for explicit confirmation instead of touching it. # Local Dev Runbook - Do not assume plain `npm run dev` is enough for local verification. - For local browser testing, load environment variables from `.env.production` first, then override only these public URLs: - `NEXT_PUBLIC_APP_URL=http://127.0.0.1:3000` - `NEXT_PUBLIC_MAIL_APP_URL=http://127.0.0.1:3000` - Start the app with `npm run dev -- --hostname 127.0.0.1 --port 3000`. - Prefer `127.0.0.1` over `localhost` so local host/origin handling stays consistent with the app's auth and mail URL logic. - This local run mode is a local Next.js server connected to the external services configured in `.env.production`; it is not a fully isolated mock environment. - When the task is to verify login, mailbox access, or other real mail flows in the in-app browser, use the run mode above first instead of trying alternate ad hoc launch methods. # Kavenix Administrator Authentication - The administrator login account for `https://officialsite.kr/kavenix` is `admin@officialsite.kr`. - Keep `자동 로그인` enabled when signing in through the in-app browser so the administrator session is retained for scheduled publishing runs. - When a login screen appears, first let the page and the browser's normal autofill finish, check that the displayed account is the authorized account without reading or exposing a password, and use the normal `로그인` button when credentials are already supplied by autofill. Recheck the destination and exact signed-in identity after submission before deciding that authentication is blocked. Do not ask the user to log in merely because the initial page snapshot showed a login form. Request only a genuinely missing credential, OTP, CAPTCHA, or explicit provider approval after this normal flow has been checked; never extract saved credentials or retry a rejected login repeatedly. - Never store the administrator password, access tokens, refresh tokens, or session cookies in this repository, `AGENTS.md`, automation memory, documentation, logs, or commits. - When the user supplies the password in an authorized conversation, use it only for the live login form. If the retained session expires, request a fresh authorized login instead of guessing or recovering secrets from files. # Editorial Direction ## Routine Login Handling Across Publishing Platforms - On every authorized publishing or activity platform, use the retained in-app browser session first. If a login form appears, wait for normal browser autofill, verify the displayed account, and click the native login button when credentials are already supplied. Complete the already-authorized Google sign-in path where required. This rule also applies to Naver, X, RocketPunch, WordPress, and the Instagram scheduling administrator, not just the Official website administrator. - Do not ask the user to log in again solely because a login form is visible. Verify the resulting destination and exact account after the ordinary login attempt. Ask only for a genuinely missing credential, OTP, CAPTCHA, or explicit provider approval. Never extract saved passwords, inspect authentication storage, expose secrets, or repeatedly submit credentials after a rejection. This clarification takes precedence over older platform wording that asks for a fresh login immediately on session expiry. - The Official Mail blog network is not limited to email, DNS, or product documentation. Its primary audience is solo businesses, solo founders, vibe coders, and small teams building an early-stage business. - Prioritize these five editorial pillars, in this order when no topic is explicitly requested: - `1인기업`: practical operating systems, decision making, customer support, productivity, and sustainable solo-business workflows. - `1인창업`: idea validation, MVP launch, pricing, first customers, and lessons from running a new business. - `바이브코딩`: building and improving real products with AI-assisted development, including tools, workflows, failures, and security considerations. - `브랜딩`: positioning, naming, visual consistency, trust signals, brand voice, and the practical choices a small business can execute. - `마케팅`: content, search, distribution, customer acquisition, conversion, retention, and low-budget experiments with measurable outcomes. - Treat company email, DNS, SPF/DKIM, AI mail, and Official Mail product workflows as supporting operational topics. Do not present them as the entire identity of the blog network. - Prefer firsthand workflows, concrete scenarios, decision criteria, before-and-after reasoning, and honest lessons. Reject generic AI prose, fabricated metrics, fake testimonials, keyword stuffing, and prompt-like wording. - Each article must be useful without purchasing Official Mail. Mention or link the product only where it naturally supports the reader's task. - Keep the public profile identity consistent across Blogger, WordPress.com, Tistory, Naver Blog, DEV.to, Medium, Disquiet, X, RocketPunch, Reddit, Instagram, and Threads: `오피셜메일` publishes practical writing about solo business, solo entrepreneurship, vibe coding, branding, and marketing. # Publication Language Standard - **Korean is the required default language for every Official Mail publication and public interaction except Reddit.** This applies to the Official Mail website, Blogger, WordPress.com, Tistory, Naver Blog, DEV.to, Medium, Disquiet, X, RocketPunch, Instagram, Threads, and any additional distribution channel configured later. **Reddit is the explicit exception and must use natural English for all profile posts, subreddit posts, titles, body copy, comments, and replies.** - Never use the middle-dot character `·` in any Official Mail-authored public content on any platform. This prohibition covers titles, descriptions, excerpts, headings, body copy, captions, image copy, alt text, CTAs, short-form posts, comments, replies, and repost commentary in every language. When an inline separator is needed, replace the middle dot with a standard comma followed by a space (`, `), and rewrite the sentence if a comma would read unnaturally. Before every submission, scan the complete authored text and remove every middle dot; do not substitute a look-alike middle-dot character to bypass this rule. Platform-generated interface text and source material quoted verbatim are not authored content, but never copy their middle dots into the new publication or interaction. - Write titles, descriptions, excerpts, opening answers, headings, body copy, captions, image alt text, visible FAQs, CTAs, short social posts, quote-repost commentary, public comments, and replies in natural Korean unless the user explicitly requests another language for that specific deliverable or the Reddit English-only rule applies. - This common language standard takes precedence over platform audience assumptions and platform-specific runbooks. Never switch to English merely because a service has an international audience, its interface or suggestions are in English, or popular posts and tags on that service are written in English. - Standard product names, organization names, code identifiers, API names, commands, source-language interface labels, and established platform tag identifiers may remain in English where translation would reduce accuracy. These exceptions do not permit English introductions, paragraphs, section headings, summaries, or CTAs. - Treat an English edition as a separate deliverable requiring an explicit user request. Do not replace the Korean edition, publish an English translation by default, or combine full Korean and English copies into one article unless the user specifically asks for a bilingual version. - If an English draft already exists for a routine or full-distribution publication, stop and rewrite it into a complete, natural Korean version before publishing. Do not rely on machine-like sentence-by-sentence translation or leave unintended English sections in the public result. # Threads Same-Day Scheduling Runbook - Apply this runbook whenever the user asks for `블로그 글 작성해줘`, invokes the daily full-distribution automation, asks for `스레드 작업` or `스레드 예약`, or gives an equivalent Threads scheduling request. From 2026-09-11 onward, every daily full-distribution run must include this same-day Threads reservation batch without waiting for a separate Threads request. This rule permanently replaces every earlier instruction that excluded or paused Threads. Do not treat the single campaign article copied to Threads as completion: the Threads publication requirement for a daily full-distribution run is the complete randomized queue described below. - Run the Threads reservation batch after the canonical and requested external blog publications have passed QA, and finish it before declaring the daily distribution complete. It is a separate current IT and developer-culture queue, so its individual topics do not need to repeat the day's long-form article. The normal Threads activity rules still apply after publication QA, but scheduled items never count as likes, reposts, follows, or other feed activity. - Use the retained in-app browser session at `https://kavenix.officialsite.kr/` and verify the authorized Kavenix administrator identity before editing the queue. Follow the shared login rule above: wait for normal autofill and click the native login button when the authorized credentials are already present. Never write the administrator password to this file, memory, drafts, logs, or commits. - Before adding anything, inspect all Threads items already scheduled for the current date. Do not duplicate a topic, opening, punch line, or substantially similar observation, and do not create two items at the same time. Preserve unrelated existing Instagram and Threads reservations. - For a same-day batch, calculate times from the actual current `Asia/Seoul` time through 23:59. Schedule the first item 50 to 90 minutes after the run begins, then keep every adjacent Threads reservation 50 to 90 minutes apart. Randomize the intervals instead of using a fixed cadence, keep every time on the same local calendar day, and stop when another valid interval would pass 23:59. Recalculate from the real clock on every run; never reuse yesterday's timetable. - Threads reservations in this mode are text-only. Leave images and attachments empty, include no URL or link preview, use no hashtags, and leave the scheduler topic field empty unless the user explicitly asks otherwise. Select Threads only; do not also select Instagram merely because both accounts appear in the scheduler. - Write every item in natural Korean and remove the middle-dot character before submission. Use a distinct, conversational opening and short mobile-friendly paragraphs. Vary length and rhythm naturally across the batch; do not repeat a template, numbered series, slogan, CTA, or closing line. - The reference style is a relatable developer observation that escalates through concrete friction and ends with a restrained punch line. Analyze the supplied `goodtek.xyz` example only at this abstract level: it opens with a familiar misconception, moves through concrete production friction, contrasts an easy first demo with the hard final stretch, uses short mobile-readable lines, and closes with understated developer humor. Recreate only those principles with fresh wording and a distinct structure. Never copy its sentences, sequence, signature `딸깍` payoff, numbered continuation marker, or personal-experience claim, and never imitate that account closely enough to obscure authorship. - Prefer vibe-coding and developer-life observations that people can recognize from real work: requirements changing after a demo, authentication and mobile edge cases, deployment and review failures, agent context boundaries, model churn, cost visibility, security controls, and the difference between generated code and an operated product. Do not invent outages, benchmarks, customer incidents, usage statistics, or firsthand experience. - Freshness is mandatory. Immediately before every batch, review dated primary sources such as vendor release notes, official changelogs, documentation, and original research published or updated recently, preferably within the last 30 days. Record each source title, publisher, publication or update date, URL, and the exact supported fact in the private run ledger. At least one current primary source must support each scheduled item's factual premise. Use those facts as background for original observations, but keep public Threads copy link-free as requested. Skip rumors, unattributed screenshots, recycled launch posts, undated search snippets, and any claim that cannot be verified from a current primary source. - A current product announcement is not permission to advertise it. Translate the supported fact into a useful or funny human observation, keep brand mentions only when needed for accuracy, and do not imply endorsement, access, results, or testing that did not occur. A post must still make sense to a reader who has not seen the announcement. - Prepare the entire same-day queue before the first save. Check every draft for factual support, originality against the existing queue and recent 30-day history, natural Korean, no middle dots, no hashtags, no URLs, no attachment, and an empty topic. Then create the reservations one by one through the scheduler's normal flow. - Count a reservation only after reopening or refreshing the queue and verifying the exact text, Threads destination, scheduled local date and time, text-only state, and scheduled status. If a save fails or the item is missing, correct that one item without duplicating successful reservations. Report the verified schedule and count; never claim completion from a filled editor, toast, or disabled button alone. # Official Website Blog Localization Data Standard - The Korean fields entered through `https://officialsite.kr/kavenix?view=blog` are the canonical editorial source, but every new or materially updated Official website blog article must also include complete localization data for every locale in `SUPPORTED_LOCALES` from `src/lib/i18n-config.ts`. These internal Official website locale variants are mandatory companion data, not separate external-platform publications, so they are the exception to the external-edition rule above. - Follow the current repository structure instead of inventing a second translation store. The canonical Korean record is saved in `marketing_blog_posts` through `src/lib/marketing-blog.ts`; localized article data belongs in `src/lib/localized-blog-content.ts` or `src/lib/localized-blog-content-additional.ts`, and the canonical slug must also appear exactly once in `src/lib/localized-blog-slugs.ts`. - Keep every `TranslationRow` in the exact locale order defined by the current `indexByLocale` mapping, which is presently `[ko, en, zh, ja, vi, ru]`. Treat `SUPPORTED_LOCALES` as the authoritative supported-locale set; whenever that set or mapping changes, update the translation row type, locale index, every affected row, validation, sitemap behavior, and this workflow together instead of relying on a stale hard-coded language list. - For each supported locale, provide a natural, non-empty translation of every localized field represented by the article: `category`, `title`, `description`, and every `sections[].title` and `sections[].body`. Preserve verified product names, code, commands, identifiers, URLs, and factual claims. Translate visible link labels and image or block descriptions when represented, but keep the intended destinations and article meaning unchanged. - Preserve one canonical article identity across languages. Keep the same canonical slug and source-post relationship; do not create independent duplicate posts or invent translated slugs under the current routing model. Add the slug to `LOCALIZED_BLOG_SLUGS` only after the corresponding localization source exists and its row order matches the manifest. - Do not publish a translation that is an empty string, placeholder, raw Korean copy in a non-Korean slot, mixed-language draft, or shortened substitute that drops a source section, FAQ, link, image meaning, warning, limitation, or CTA. If the current `LocalizedBlogSource` shape cannot faithfully represent the canonical article, extend the localization schema and renderer first rather than silently omitting content. - Treat translation writes as idempotent updates. Re-running the workflow for the same canonical slug must update its existing localization source and manifest entry, never append a second source object or duplicate slug. Do not backfill or alter historical missing translations unless the user explicitly includes that work in the request. - Before reporting an Official website article complete, verify from repository data that the article has exactly one localization source, its slug is present exactly once in `LOCALIZED_BLOG_SLUGS`, every translation row covers the full current locale set in the correct order, and no required value is blank. Then verify the public article and blog index in every supported locale, including locale-specific title, description, headings, body, canonical and alternate URLs, sitemap inclusion, and absence of Korean fallback caused by missing translation data. If any locale fails storage or rendering validation, report the article as incomplete and name the missing or invalid locales. # Official Website Blog Publishing Runbook - Apply this runbook whenever the user asks to write or publish a blog article without limiting the request to one external platform. - Treat `오늘 블로그 콘텐츠 1세트 전체 채널에 발행해줘` as the standard full-distribution command. It means: publish one canonical Official Mail article first, then publish materially rewritten versions to every configured and authenticated channel covered by this file, including X. Unless the user explicitly requests a draft, every version must be public and its public URL must be verified and reported. - Treat short requests such as `블로그 작성해줘` as the same full-distribution command unless the user narrows the scope. After publication and public-page QA are complete, run the `Post-Publication Platform Activity Runbook` on each configured and authenticated external platform before reporting final completion. - The canonical source must be a published article at `https://officialsite.kr/blog/`. Create or improve that Official Mail article first, then produce materially rewritten platform-specific versions for Blogger, WordPress.com, Tistory, Naver Blog, DEV.to, Medium, Disquiet, or Reddit. - Never copy and paste one external draft across platforms. For every channel, generate a new title, opening, section order, sentence and paragraph length, examples or emphasis, and CTA that fit that platform's audience, editor, and reading behavior. Shared facts and the canonical destination may stay consistent, but the wording and structure must be materially distinct. - Generate each platform's visuals specifically for that version and placement plan. Do not reuse an image file, crop, or composition from the canonical article or another external platform merely to save time. - If the user explicitly requests only one named external platform, follow that platform's runbook without silently publishing elsewhere. - Do not treat SEO, GEO, or AEO as a one-time completion state and never promise a ranking. Use current Search Console data, live search results, customer questions, and the existing article inventory to choose the next action. ## Native Link Standard - In every long-form editor that supports hyperlinks or link cards, including the Official website, Blogger, WordPress.com, Tistory, Naver Blog, DEV.to, and Medium, never leave a destination URL as a standalone plain-text paragraph. Select a concise natural-Korean description such as `주문 기록으로 LTV를 계산하는 자세한 가이드 보기` and attach the URL with the editor's native hyperlink control, or insert one verified native link preview when that presentation serves the reader better. - Do not use the raw URL itself as the visible anchor label merely because it becomes clickable after pasting. Prefer text that tells the reader what will open. A visible raw URL is allowed only on short-form platforms that do not support custom anchor labels, such as X, and only when the platform has converted it into a working automatic link or native preview. - Pasting a URL into an editor is not evidence that a link exists. Before reporting completion, open the public page and confirm that the intended destination is represented by an actual clickable anchor or native link-card target. Also confirm that no paragraph consists only of an `http://` or `https://` string, no duplicate preview was created, and the destination opens the canonical URL. - Platform-added clipboard attribution such as Naver's `[출처] ... | 작성자 ...` text is not part of the article body and does not satisfy the link requirement. Judge the published body itself, and insert its canonical destination with the platform's native link UI. ## Search Intent Standard - Assign one primary search task to each article. Prefer titles and H1s that state the reader's real question or decision, such as `무료 기업메일 만드는 방법`, instead of a broad product slogan. - Answer the primary question directly in the opening paragraph before mentioning Official Mail. The article must remain useful to a reader who does not sign up. - Complete the search task in one article with the sections that are genuinely needed: decision criteria, option comparison, costs or limitations, setup steps, failure cases, examples, and visible FAQ answers. Do not add sections merely to increase length. - State tradeoffs and product limitations honestly. Do not fabricate usage numbers, rankings, testimonials, prices, experiments, or third-party claims. - Use concise answer-first paragraphs, descriptive headings, lists, tables, and visible FAQs so both people and answer engines can extract the result without relying on hidden metadata. - Keep the entity relationship explicit: `오피셜메일` is the service and `카베닉스(KAVENIX)` is the operator. Use consistent product, organization, URL, and feature names across body copy and structured data. - Place the product CTA only after the informational task has been answered. Link contextually to the most relevant feature page, guide or diagnostic tool, and 2-4 related internal articles; do not force every link to the home page. ## Topic And Cannibalization Check - Before creating a new article, review Search Console queries and the published Official Mail inventory. If an existing URL already targets the same intent, improve that URL instead of creating a competing article. - Create a new article when the intent is materially different, even if keywords overlap. Product landing pages and informational comparison articles may coexist when they serve different tasks. - Build topic clusters rather than isolated posts. For the `무료 기업메일·회사 이메일 만들기` cluster, maintain a clear informational pillar and supporting articles for service comparison, real free-tier limits, registrar-specific DNS setup, SPF/DKIM delivery failures, solo businesses, shopping malls, and migration from another mail provider. - Record the primary query, supporting queries, intended reader, funnel stage, and internal-link target before drafting. Avoid spelling-variant articles that answer the same question. ## Official Article Procedure 1. Inspect the current Google and Naver query data, the live result page, competing articles, and existing Official Mail posts. Identify the missing information or decision support rather than copying a competitor's wording or outline. 2. Create or update the Official Mail source article in `/kavenix?view=blog` with a unique slug, accurate title, concise SEO description, useful excerpt, primary and supporting keywords, native blocks, visible FAQs, and a status of `published`. 3. Generate a unique internal-article image set according to `Blog Image Standard`. Use native image widgets, descriptive alt text, and real captions; do not expose Markdown or editor metadata. 4. Verify the public `https://officialsite.kr/blog/` page on desktop and mobile. Confirm one visible H1, coherent heading order, canonical URL, representative OG image, BlogPosting and Breadcrumb structured data, FAQ structured data only when the FAQ is visible, working internal links, and no raw editor syntax. 5. Confirm the article is included in the sitemap and linked from the blog index or a relevant indexed page. Submit no duplicate external version as canonical. 6. Create materially rewritten external versions only after the canonical article is public. Each version must follow its platform runbook, use its own image set, and link naturally to the canonical source. 7. After Search Console has enough data, improve the existing title, opening answer, sections, and internal links from actual queries and page-level performance instead of publishing a near-duplicate replacement. # Blog Image Standard - Every public blog article must include purpose-built visuals whenever they improve understanding. Do not default to one image per article; determine the count from the article structure and create a hero visual plus section diagrams, screenshots, or explanatory images where they are genuinely useful. - Generate a new platform-specific image set for every Blogger, WordPress.com, Tistory, Naver Blog, DEV.to, Medium, Disquiet, and RocketPunch publication when the native editor supports media. Never reuse the same generated image file across platforms, even when the articles cover the same source topic. If an editor such as Disquiet does not expose a native media block, do not paste raw image syntax or reuse another platform's file merely to force a visual into the article. - Plan each image against a named paragraph or section before generating it. Avoid unrelated decoration, generic stock-like filler, fake interface screenshots, fabricated statistics, and text-heavy images that duplicate the article body. - Use the `imagegen` skill for original article visuals unless a real product screenshot or authoritative reference image is more appropriate. Keep the visual language consistent within one article while making each platform's set materially distinct in composition and art direction. - Insert images with the platform's native media blocks at the paragraph they support. Add concise native captions and descriptive alt text where the platform supports them; never expose raw Markdown image syntax, editor directives, local paths, or generation metadata in the public article. - After publishing, open the public URL and verify every image loads at its intended position, captions and alt text are rendered correctly, mobile wrapping is clean, and no platform-specific placeholder or editor-only syntax remains. - Keep temporary upload assets under `tmp/imagegen/-/` for upload and QA. Do not commit ignored temporary assets unless the application itself needs to serve them. # Blogger Publishing Runbook - Apply this runbook whenever the user asks to publish a blog post, including short requests such as "오늘 블로그 글 발행해줘". - The only Blogger target for this project is `오피셜메일 블로그` at `https://officialmail-blog.blogspot.com`, blog ID `1328335945575071022`. - Never edit or publish to another Blogger blog visible in the connected Google account. - Blogger publishing does not use a separate API key. It uses the existing Google OAuth client with the Blogger scope. Never print or store OAuth secrets, access tokens, or refresh tokens in documentation or source code. - The admin-only publishing endpoint is `/api/admin/blogger`. It must remain protected by the Kavenix administrator session check. The publishing UI is available at `/kavenix?view=blog`. - Unless the user explicitly requests a draft, a publishing request means an actual public post, not a saved draft. ## Content Standard - Publish one useful, search-intent-focused informational article at a time. Do not publish thin summaries, keyword stuffing, fabricated statistics, fake testimonials, or prompt-like wording. - Start with the five editorial pillars in `Editorial Direction`. Use Search Console data, customer questions, actual product-building work, marketing experiments, and operating lessons to select a specific search intent. - Use mail, DNS, and Official Mail product topics only when they answer a real operational question or support one of the primary editorial pillars. - Use a clear title, a direct introductory answer, descriptive headings, practical steps, and examples. Add tables, images, callouts, or FAQ blocks only when they improve understanding. - Use the internal blog editor's native blocks and media widgets. Do not leave raw Markdown markers, block directives, image metadata, or editor-only syntax visible in the public post. - Blogger copies should be materially rewritten and shortened rather than duplicated verbatim. The current syndication flow targets roughly 40-60% of the internal source article and adds one link to the original `https://officialsite.kr/blog/...` article. - Do not add an author or team byline such as `오피셜메일 콘텐츠팀` unless the user explicitly asks for one. ## Publishing Procedure 1. Create or select a relevant internal Official Mail blog article and ensure its internal status is `published`. 2. Open `/kavenix?view=blog` in the in-app browser with the administrator session and select the source article. 3. Confirm that Blogger shows `발행 연결됨`. If the permission expired, reconnect the existing Google OAuth account and grant the Blogger scope; do not create a new API key. 4. Generate a Blogger-only image set according to `Blog Image Standard`, insert each visual near the section it explains, and then create or synchronize the Blogger version. Do not reuse images from the internal article or another external platform. 5. Publish it publicly through `/api/admin/blogger` using the authenticated administrator session. 6. Open the returned public Blogger URL and verify the title, headings, paragraphs, tables, images, captions, links, mobile wrapping, and absence of raw editor syntax. 7. Confirm that `marketing_blog_syndications` contains one `blogger` record for the source post and that its status is `published`. Do not create duplicate external posts for the same source post. 8. Report the public Blogger URL to the user. Do not claim completion when only a draft or local preview exists. # WordPress.com Publishing Runbook - Apply this runbook when the user asks to continue external blog distribution after Blogger or explicitly requests WordPress.com publishing. - The only WordPress.com target is `오피셜메일 블로그` at `https://officialmailkr.wordpress.com`. Never publish to another WordPress site visible in the connected account. - WordPress.com publishing uses the server-only credentials in `.env.production`. Never print, commit, log, or place the client secret or access token in a client component. - The authorized interactive WordPress.com sign-in path is `Google로 계속` (`Continue with Google`). When the retained WordPress.com session is missing, use the visible Google sign-in flow, then verify that the active account can manage `officialmailkr.wordpress.com` before creating, editing, publishing, commenting, liking, or reblogging. Following and subscribing to third-party WordPress channels are prohibited under the rule below. - Never store the Google account password, OAuth codes, access tokens, refresh tokens, session cookies, or account-recovery data in this repository, `AGENTS.md`, automation memory, documentation, logs, or commits. Keep the authenticated browser session when WordPress.com offers a normal session-retention option. - The administrator-only publishing endpoint is `/api/admin/wordpress`; it must remain protected by the Kavenix administrator session check. - Do not treat `서버 설정 필요` in `/kavenix?view=blog` as the final WordPress.com blocker. After confirming that state, attempt the authorized interactive Google login and manual WordPress.com editor flow. Stop only if Google authentication itself needs user input, the signed-in account cannot manage the target site, or the public post cannot be safely verified. - Unless the user explicitly requests a draft, a publishing request means an actual public post and requires opening the returned public URL for verification. - Keep the active `Essentialist` theme and the custom Korean information-blog home layout unless the user requests a redesign. ## WordPress.com No-Subscription Rule - Never subscribe to or follow another person's WordPress site, channel, blog, author, or newsletter during publishing or platform activity. Do not click `구독`, `Subscribe`, or `Follow` in Reader, public posts, recommended-site dialogs, or follow prompts. Do not enable new email or comment-conversation subscriptions as an alternative. - This prohibition overrides every general relationship-action allowance or quota. Record WordPress relationship actions as `not permitted`, with a target of zero; do not treat the absence of a subscription as an incomplete activity pass. Likes, substantive comments, and eligible native reblogs remain governed by their existing rules. - Preserve existing subscriptions unless the user explicitly asks to remove them. Do not unsubscribe, resubscribe, or change existing subscription settings as part of routine work. ## WordPress.com Categories - Every public WordPress.com post must have at least one accurate category selected before publication. Never leave a published post assigned only to `Uncategorized`, and remove `Uncategorized` after selecting the intended category. - Prefer the shared editorial categories `1인기업·창업`, `바이브코딩`, `브랜딩`, `마케팅`, and `운영 인사이트`. Use the existing `메일 반송 해결` category for Gmail rejection, delivery failure, SPF/DKIM, and closely related mail-security troubleshooting articles. - If no existing category accurately fits the article, create a concise reusable category from `https://officialmailkr.wordpress.com/wp-admin/edit-tags.php?taxonomy=category` with a useful one-sentence description. Reload the category screen and verify the new category before returning to the post editor. Do not create spelling variants, one-post keyword categories, or duplicates merely to avoid reusing an accurate broader category. - Normally select one primary category. Add a second category only when the article fully serves both reader tasks; do not assign every post to several broad categories for exposure. - After saving or publishing, verify the category count in WordPress administration, open the public category archive, and confirm the post title appears there. A filled editor, an unchecked save state, or a post still counted under `Uncategorized` is incomplete. ## WordPress.com Procedure 1. Select a published internal Official Mail article. External content must be useful on its own and must not be a verbatim duplicate of the internal article or the Blogger version. 2. From `/kavenix?view=blog`, create or synchronize the WordPress.com draft, then publish it through `/api/admin/wordpress` using the authenticated administrator session. If that surface reports `서버 설정 필요`, sign in to WordPress.com with `Google로 계속` and publish the materially rewritten version through the target site's native editor instead of abandoning the channel. 3. In the WordPress.com post editor, select the category that matches the article according to `WordPress.com Categories`. Create and verify a reusable category first when needed, then remove `Uncategorized` before saving or publishing. 4. Include one contextual link to the matching Official Mail guide or diagnostic tool and one clear link to the canonical internal article at `https://officialsite.kr/blog/...`. 5. Generate a WordPress.com-only image set according to `Blog Image Standard`; do not reuse images from the internal article, Blogger, or any other platform. 6. Use rendered HTML and native media output. Do not expose raw Markdown markers, editor block directives, image metadata, or internal author labels. 7. Open the public WordPress.com URL and verify the title, headings, selected category, category archive membership, image alt text, captions, tables, links, mobile wrapping, and the absence of theme sample content. 8. Confirm that `marketing_blog_syndications` has one `wordpress` row for the source post with `platform_status = 'published'`. Synchronize the existing external post instead of creating duplicates. 9. Report the public WordPress.com URL and category to the user. # Tistory Publishing Runbook - Apply this runbook to every full-distribution request, including `블로그 글 작성해줘`, and whenever the user explicitly requests Tistory publishing. Tistory is a required external long-form channel from 2026-09-11 onward and must not be silently omitted. - The only authorized Tistory destination is the custom-domain blog `http://blog.officialsite.kr`, backed by `https://head-country.tistory.com`. Verify both identities before opening the editor or publishing, and never post to another Tistory blog visible in the signed-in account. - Use the retained in-app browser session and the normal Tistory or Kakao sign-in flow. Never store a Kakao password, OAuth code, access token, session cookie, recovery detail, or other credential in this repository, `AGENTS.md`, automation memory, drafts, logs, or commits. - The custom domain currently declares `http://blog.officialsite.kr` as its canonical public origin. Verify that exact public URL and the returned Tistory permalink after publication. Do not claim an HTTPS custom-domain URL is verified while it has a certificate-name or certificate-chain failure; record that infrastructure issue separately without abandoning a valid public HTTP post. - Before creating a post, inspect the Tistory management list, public index, RSS feed, and the recent 30-day publication memory for the canonical Official Mail source slug and substantially similar titles. Update an existing Tistory version when it already represents the same source; never create a duplicate merely because the custom domain and native Tistory URL look different. - Write a materially original Korean article for Tistory. Change the title, opening, section sequence, examples, paragraph rhythm, and conclusion from the Official website, Blogger, WordPress.com, Naver Blog, DEV.to, and Medium versions while preserving verified facts and the canonical destination. The article must answer the search task on its own and must not read like a teaser or a copied summary. - Use Tistory's native heading, paragraph, list, quote, table, link, and media controls. Do not expose raw Markdown, copied editor metadata, local paths, HTML fragments, clipboard attribution, or prompt-like instructions in the public body. Keep native numbered lists continuous and verify their visible numbering after publication. - Insert one descriptive native hyperlink to the matching canonical Official Mail article at `https://officialsite.kr/blog/`. Never show the raw URL as the anchor text or as a standalone paragraph, and verify the actual public anchor destination after publication. - Generate a Tistory-only image set according to `Blog Image Standard` when an image materially improves the article. Do not reuse another platform's file or composition. Add a concise caption and descriptive Korean alt text where the editor supports them, then verify the rendered asset instead of assuming a completed upload is public. - Select one accurate reusable Tistory category and add only a small set of relevant tags. Do not leave the post in an unrelated default category, create spelling-variant categories, or stuff tags with near-duplicate keywords. - Every new or materially updated Tistory post must contain a native Tistory advertisement block so that the article is eligible to display an ad. In the editor, place the caret at a natural section break after the opening explanation and before the main body, open `더보기`, choose `광고`, and insert exactly one native ad block. Do not type an ad placeholder, paste ad HTML, add a script, or simulate the block with text. For reference-style HTML articles, keep the authored body in HTML mode as required below, then use the editor's supported native ad insertion flow without flattening or duplicating the saved body; if the editor requires a mode change, make the minimum supported transition and re-run the duplicate-tail and public-style gates before saving. - Before publishing or updating a Tistory post, reopen the editor and verify that the native ad block is present exactly once, remains between valid content blocks, and does not split a heading from its first paragraph, a list, a table, a figure, or a callout. After the public save, verify that the article layout is intact around the insertion point and record the ad-block state as `native ad block verified` in automation memory. A generic skin ad, sidebar ad, automatic platform ad, blank spacer, editor toast, or the mere presence of an ad menu does not satisfy this article-level requirement. - Unless the user explicitly asks for a draft, publish publicly. An explicit Tistory publishing, distribution, correction, or formatting request authorizes completing the normal public save or update flow without inserting a separate workflow-level final-review question. Stop only for genuinely missing authentication, CAPTCHA, an unrecoverable platform error, or another user action the platform itself requires. Open the final custom-domain permalink and, when available, its native Tistory permalink. Verify the title, author identity, publication date, heading order, paragraphs, lists, image, caption, alt text, category, tags, descriptive canonical link, mobile wrapping, RSS presence, and absence of raw editor syntax before reporting completion. - Record the source slug, Tistory public URL, native permalink when different, category, publication state, link destination, image state, and stable post identifier in automation memory. Do not report Tistory complete from a filled editor, saved draft, toast, or management-list row alone. ## Tistory Information Architecture and Article Presentation - Use `https://goddaehee.tistory.com/641` only as a structural reference for navigation and long-form readability. Never copy its sentences, images, tables, category names, claims, examples, distinctive expressions, or visual assets. Reuse only general publishing patterns that fit Official Mail. - Keep the Official Mail Tistory category tree compact and purpose-led. The intended hierarchy is `1인기업과 창업 > 시작과 운영, 매출과 성장`, `기업메일 가이드 > 제휴와 신뢰, 도메인 메일, 보안과 전달률`, `운영 인사이트 > 업무 흐름, 자동화와 연동, 고객 응대`, `바이브코딩 > AI 활용, 개발 밈과 현실`, and `브랜딩과 마케팅 > 콘텐츠 전략, 고객 신뢰`. Do not create spelling variants, duplicate categories, or unrelated legacy game categories. - Treat the current `#2` Tistory skin's category panel as the primary menu because that skin reports that it does not support the separate Tistory menu feature. Do not silently replace the skin merely to expose a top navigation bar. In this skin, preserve the visible home link, profile identity, search control, hierarchical category panel, RSS access, and a concise Official Mail link instead of claiming that an unsupported custom menu is live. - Keep the sidebar focused on discovery rather than decoration. Retain `최근에 올라온 글`, `링크`, `태그 클라우드`, and `글 보관함`; remove empty notices, recent comments, calendar, and visitor-count modules. Show 5 recent posts with up to 40 title characters, 6 months of archives, link labels up to 24 characters, and up to 20 tags. The `링크` module must point to `https://officialsite.kr` with the label `오피셜메일 홈페이지`; never leave unrelated legacy links. - Begin each substantial Tistory article with a short human opening that states the reader's practical problem and what the article will help decide. Follow it with a compact `이 글의 핵심` summary of three to five bullets when the article exceeds roughly 1,500 Korean characters. - For articles with four or more substantive sections, add a visible `목차` using the editor's native heading and anchor behavior when available. Number only top-level sections with a single continuous sequence such as `1.`, `2.`, `3.`. Use unnumbered subheadings for supporting explanations, and verify that no repeated `1.` numbering appears on the public page. - Use an information shape that matches the subject instead of forcing every block type: short paragraphs for reasoning, bullet or numbered lists for procedures, a table only when it makes a genuine comparison clearer, quote styling only for a real short quotation, and code blocks only for executable code. Never add a table, screenshot, or code sample as filler. - Define unfamiliar terms in plain Korean at first use. Separate verified facts, examples, assumptions, limitations, and the author's judgment so the article never presents an illustrative scenario as measured evidence. For time-sensitive claims, verify the source date and add a concise `참고 자료` section with descriptive links. - Use one purpose-built Tistory hero image near the opening when it materially improves comprehension, then add section visuals only when they explain something the prose cannot. Supply meaningful Korean alt text and avoid repeating the same decorative image between sections. - End with a concrete conclusion or next action rather than a generic greeting. Add a small, non-duplicative tag set and rely on the category tree, search, recent-post module, tag cloud, archive, and related-post rendering to help readers continue exploring. ### Tistory Editorial Depth and Resource Plan - Before drafting a substantial Tistory article, make a topic-specific resource plan rather than expanding an AI summary. List the reader's real situation, the decision or task they must complete, the concrete example or test that makes it visible, the reusable sample they can copy, the visual or table that removes ambiguity, the reason the method works, one useful variation, and a limitation or exception. Do not open the editor until this plan contains enough material to fill the article naturally. - Use the reference article's editorial rhythm, not its subject matter or wording: `specific situation or test -> immediately usable sample or template -> result visual or comparison -> why it works -> variation the reader can try -> limitation and source when applicable`. Repeat that sequence where it helps the reader, and connect blocks with natural explanatory paragraphs instead of stacking isolated cards, lists, and headings. - When the topic permits hands-on work, include at least three distinct reader actions across the article, such as a ten-minute audit, a copyable reply, a completed example row, a checklist, or a small before-and-after comparison. The actions must produce a concrete result; vague prompts such as `생각해 보세요` do not count. If the subject genuinely supports fewer actions, record the editorial reason in the run log instead of padding the post. - A substantial article should normally include a unique opening visual plus at least two supporting resources selected for the subject: a second explanatory image, annotated screenshot, process illustration, table, template, example output, or decision checklist. Every resource must be introduced in the prose and followed by a sentence explaining what the reader should notice. Never add stock-like decoration merely to increase image count. If fewer than three visual resources are appropriate, record why in the run log. - Build each supporting visual from the current article's actual message and adjacent section, not from a previous post or a generic brand prompt. Its composition, objects, labels, caption, and alt text must represent the specific example being discussed. Do not reuse another platform's image or make a new image whose text merely repeats the hero. - Label invented walkthroughs and sample records as `가상의 예시`, and never imply that they are customer results, measured data, or a real company's internal record. Use citations for external or time-sensitive factual claims; do not cite `https://goddaehee.tistory.com/641` as evidence for Official Mail claims because it is only a structural writing reference. - Vary paragraph length and sentence openings so the article reads like an experienced operator explaining one connected problem. Prefer concrete verbs, dates, roles, field names, and decisions over generic phrases such as `중요합니다`, `효율적입니다`, or `도움이 됩니다`. A longer article is acceptable only when each paragraph advances the example, reasoning, procedure, limitation, or next action. - Before publication, audit the body for editorial completeness as well as visual style: confirm that every promised exercise is actually usable, every sample can be copied without missing context, every table has a clear reading purpose, every image matches its adjacent section, and every factual claim is either self-evident, explicitly illustrative, or supported by a verified source. ### Tistory Reference-Style Article Template - For every substantial Tistory article, use `docs/content/templates/tistory-reference-style.html` as the reusable body template. It captures the article-level presentation patterns observed at `https://goddaehee.tistory.com/641` without copying that site's text, images, brand, category labels, or skin. Do not represent the current `#2` skin's fixed sidebar, title cover, navigation, or advertisement placement as editor-controlled article formatting; a skin migration is separate work and requires an explicit request. - Wrap the authored body in a centered reading column with `max-width: 900px`, `margin: 0 auto`, `font-size: 18px`, `line-height: 1.88`, `color: #333`, `word-break: keep-all`, and `overflow-wrap: anywhere`. Prefer `Pretendard`, the system UI stack, and `Noto Sans KR`. Use CSS margins for rhythm instead of repeated empty paragraphs. Do not let Tistory's visual editor silently flatten body copy back to its 16-pixel default. - Open with two or three short paragraphs that name the reader's situation, the practical risk, and the decision the article will help make. When a hero image is useful, place the new Tistory-only image immediately after that opening and render it at `width: 100%`, `height: auto`, with no decorative border or corner radius, matching the reference's full-width rectangular resource treatment. Add a concise Korean caption and alt text. Never reuse the reference site's title image or another platform's asset. - Treat the template as a presentation shell, not a substitute for research or article development. Fill it from the completed resource plan, and expand or remove optional blocks according to the subject. For a substantial article, do not stop at one hero image and a short summary when the reader needs examples, intermediate results, comparisons, or supporting visuals to understand the method. - For articles longer than roughly 1,500 Korean characters, place a pale-green `이 글의 핵심` box after the opening or hero. Use `background-color: #e8f5f0`, `border-left: 4px solid #10a37f`, `padding: 15px 20px`, `margin: 20px 0`, and right-side corner radius `0 8px 8px 0`. Include three to five specific bullets and never repeat the introduction word for word. - For four or more substantive top-level sections, place a visible linked `목차` after the summary. Use a pale-green panel with `background-color: #f4fbf8`, `border: 2px solid #a3d9c8`, `border-radius: 12px`, and `padding: 20px 25px`. Use a continuous numbered list whose descriptive links target unique section IDs such as `#section1`, `#section2`, and `#section3`; verify every jump on the public page. - Render each top-level section as a numbered `h2` with `font-size: 24px`, `line-height: 1.38`, `color: #1a3a52`, `margin: 35px 0 20px`, `padding: 24px 0 10px`, and `border-bottom: 3px solid #cce5ff`. Use one continuous visible sequence only. Render supporting `h3` headings without numbers at `20px`, `line-height: 1.4`, `#1a3a52`, `font-weight: 600`, `margin: 40px 0 15px`, and `padding-top: 20px`. Separate major sections with one full-width `div` divider using `height: 1px`, `background-color: #e0e0e0`, and `margin: 32px 0` when the page needs an additional visual pause. Do not use `hr` for this purpose: the current `#2` skin decorates `hr` as a short line with dots and overrides the intended reference-style separator. Verify the rendered divider is a plain one-pixel line on desktop and mobile. - Copyable prompts, reply templates, commands, or other literal samples must use a visibly distinct code or sample block rather than a pale generic card. Use `background-color: #1e1e1e`, `color: #d4d4d4`, `font-family: 'Fira Code', Consolas, monospace`, `font-size: 16px`, `line-height: 1.8`, `padding: 15px`, `margin: 15px 0`, `border-radius: 8px`, and `white-space: pre-wrap`. Use a light bordered example card only when the content is narrative rather than copyable verbatim. - Every table must contain a real `thead` and labeled `th` cells. Use `#e8f4f8` header fill, `#b3d9ff` one-pixel borders, `12px 15px` header padding, `10px 15px` body-cell padding, 16-pixel bold headers, and 14-pixel body copy. Reject a preview where column labels collapse into an unstyled text run above the table. - Before publication, compare the Tistory PC preview against the reference at three equivalent checkpoints: an `h2` plus body paragraph, an `h3` plus copyable sample, and a table or image with its explanation. Inspect the rendered computed values when possible. A post is not reference-style merely because it uses navy headings and pale boxes; it must also preserve the 18-pixel reading scale, strong heading spacing, distinct sample surface, semantic table header, full-width resources, and dense explanation rhythm. Perform the same check again on the public URL because Tistory may sanitize styles during save. - Save the exact final HTML body for every substantial Tistory article under `docs/content/tistory/-.html` before opening the editor. This artifact must be the same complete fragment pasted into Tistory HTML mode, with no placeholders, and must retain the Tistory-hosted image URLs after their first successful upload. Do not reconstruct a shortened approximation directly in the editor. If the public article must be corrected, update this artifact first and replace the whole editor document from it so the repository remains the reproducible source for the published layout. - Treat a missing presentation wrapper or a simplified block as a failed save, even when all words remain visible. The stored public body must contain one outer reading wrapper and must preserve all of these authored structures when the article uses them: a styled summary panel, a linked table of contents, unique section IDs, semantic `thead` and `th` cells, a distinct `pre` sample, image captions, warning or limitation treatment, and one conclusion action card. Do not accept flattened replacements such as an unpadded background-only `div`, a plain text table header row inside `tbody`, a non-linked table of contents, or headings that keep only `color` while losing spacing and borders. - Prefer sanitizer-safe inline styles on the exact rendered elements. Put paragraph sizing and rhythm on every authored `p`, heading values on every `h2` and `h3`, list spacing on `ul`, `ol`, and `li`, and table borders and padding on every `th` and `td`; do not rely only on inheritance from the outer wrapper. Use only body-fragment HTML and inline styles: no `style`, `script`, external stylesheet, custom web component, JavaScript event attribute, or editor-generated clipboard markup. This duplication is intentional because the active skin and Tistory sanitizer can override or discard inherited presentation. - After saving, fetch or inspect the public article body itself, not only the screenshot. Confirm the outer wrapper exists exactly once, each expected section ID exists exactly once, the table has a real `thead`, all intended figures have `figcaption`, and the public markup still contains the critical inline declarations for body text, headings, summary, table cells, sample block, and action card. Then visually compare the same three checkpoints on desktop and at 360 to 390 pixels. If the markup or any checkpoint is flattened, reopen the same post in HTML mode and correct it before reporting completion. - Keep paragraphs short and use bold only for the sentence fragment that carries the decision, constraint, or result. Use lists for genuine procedures and checklists. Do not add decorative headings, excessive colored text, repeated blank lines, fake quotations, or a new component merely to imitate the reference. - Use a responsive table only when rows and columns make a real comparison easier to scan. Wrap it in a horizontally scrollable region, set the table to `width: 100%`, `min-width: 720px`, `border-collapse: collapse`, and `font-size: 14px`. Use `#e8f4f8` headers, `#b3d9ff` borders, `10px 15px` or `12px 15px` cell padding, and optional `#f8fbff` alternating rows. Supply a useful Korean `aria-label`; never force prose into a table. - Use the yellow warning box only for a real limitation, prerequisite, or common failure. Its required presentation is `background-color: #fff3cd`, `border-left: 4px solid #ffc107`, `padding: 15px 20px`, `margin: 20px 0`, and corner radius `0 8px 8px 0`. Do not use it as a promotional highlight. - Near the conclusion, use at most one pale-blue action card when a canonical Official Mail article or tool is genuinely the reader's next step. Use `background: #f8fbff`, `border: 1px solid #cce5ff`, `border-radius: 10px`, and `padding: 16px 18px`. The link must be a concise descriptive Korean label styled as a native anchor, not a raw URL, and its destination must match the current article's canonical source. - Choose the required Tistory editor mode before changing the body and switch modes at most once per editing session. For a reference-style article, enter HTML mode once, accept Tistory's mode-change warning immediately when it appears, install the complete clean template, and remain in HTML mode through preview and save. Do not return to the visual editor merely for a read-through because every mode change can trigger another confirmation dialog, flatten inline styles, duplicate content, or stall browser control. Perform structural review in Tistory's PC and Mobile preview instead. If a correction is needed, close preview, edit the same HTML document in place, and reopen preview without switching modes. Before inserting the artifact, click the active CodeMirror textarea, send `Ctrl+A`, send `Backspace`, and verify the editor is blank; only then insert the complete artifact. Never rely on a `fill` or paste call by itself to replace a CodeMirror document because it can insert the new wrapper before the old body and create a styled copy followed by a flattened duplicate. After insertion, verify the wrapper and a unique opening sentence each occur exactly once in the entire CodeMirror document. Remove placeholder tokens, unsupported attributes, copied source markup, scripts, style sheets, editor metadata, and every middle-dot character. Reopen the public custom-domain post on desktop and a narrow viewport and verify the opening, summary box, linked table of contents, continuous section numbering, heading hierarchy, table scrolling, warning and action cards, image crop, caption, alt text, descriptive link, category, tags, and absence of raw HTML. If the active skin overrides a color or spacing value, preserve readability and record the rendered result instead of claiming pixel identity. - Never paste the reference-style HTML into Tistory's visual editor, even when formatted clipboard paste appears correct in the editor canvas. The visual editor sanitizer removes wrapper typography, panel padding, heading spacing and borders during save. A reference-style article must be installed only into the CodeMirror document after entering HTML mode, and the public-style gate must fail the run if the saved body shows that visual-editor flattening signature. ### Tistory Public Style Gate - Treat the saved public custom-domain body as the only authoritative formatting result. An editor canvas, preview, saved toast, management-list row, correct text, or visible image is never sufficient proof that formatting survived. After every new publication or edit, run `npm run qa:tistory-public -- --artifact ` and keep the run incomplete when the command exits nonzero. - The public article must contain exactly one `#officialmail-tistory-article` wrapper and one copy of every expected section ID. The wrapper must retain the 900-pixel reading-column declaration, 18-pixel body scale, 1.88 line height, Korean word breaking, and overflow wrapping. Every authored paragraph must carry its own margin, 18-pixel font size, and 1.88 line height instead of inheriting them only from the wrapper. - Verify the public markup, not only its text: the summary and table-of-contents panels must retain their borders and padding; every numbered `h2` must retain 24-pixel sizing, top and bottom spacing, padding, and a three-pixel bottom border; every `h3` must retain its 20-pixel scale and spacing; every comparison table must keep a real `thead`, labeled `th` cells, responsive overflow wrapper, borders, and cell padding; every figure must keep one non-empty Korean `alt`, one `figcaption`, full-width image styling, and nonzero image dimensions after loading. - Perform a browser computed-style audit at desktop width and again between 360 and 390 pixels. At minimum, read back one opening paragraph, one `h2`, the summary panel, the linked table of contents, one `th`, one `td`, one image and caption, and the conclusion card. Reject the result when body copy is below 17.5 pixels, line height is below 1.75, a numbered `h2` is below 23 pixels or lacks the three-pixel divider and at least 20 pixels of top padding, a styled panel has zero padding, a table header collapses into plain text, a figure overflows the viewport, or horizontal page scrolling appears. - Keep one desktop screenshot and one narrow-viewport screenshot that each show a meaningful checkpoint, not just the title. The desktop capture must include a numbered heading plus its following explanation and either a table or figure. The narrow capture must show the same content without clipping, overlapping, or page-level horizontal scroll. - Fail closed. If any structural, computed-style, image, link, desktop, or mobile check fails, reopen the same post, switch to HTML mode once, replace the entire CodeMirror document from the committed artifact, save the edit, and repeat every gate. Never patch the flattened visual-editor DOM block by block, never switch back to the visual editor, and never report completion while even one gate is failing. - The validator must derive the expected section IDs, heading sequence, table count, figure count, canonical link destinations, opening paragraph, and numbered heading sentinels from the current article artifact. Never hard-code a previous article's section count, link slug, or resource count into the reusable Tistory QA script. Treat an artifact that lacks `#officialmail-tistory-article`, `#officialmail-summary`, `#officialmail-toc`, per-paragraph typography, semantic table headers, image alt text, captions, or at least one descriptive canonical link as invalid before opening the editor. On the public page, count the opening paragraph and every numbered heading across the whole `.article-view`, not only inside the wrapper, and fail if any occurs other than exactly once; this is the mandatory duplicate-tail detector for a styled wrapper followed by a flattened old body. - Record the validator command, public URL, artifact path, wrapper count, section-ID count, heading and table checks, image dimensions, descriptive-link destinations, desktop result, and mobile result in automation memory. A statement such as `looks fine`, `image loaded`, or `public URL opens` is not a valid verification record. # Naver Blog Publishing Runbook - Apply this runbook when the user asks to publish or continue external distribution on Naver Blog. - The only Naver Blog target is `오피셜메일 블로그` at `https://blog.naver.com/kavenix`. Never edit or publish to another Naver Blog visible in the signed-in account. - The authorized Naver login ID for this target is `rhnr1919`. Verify both the signed-in account and the destination blog ID `kavenix` before opening the editor, publishing, commenting, reacting, following, or changing categories. - Never store the Naver password, access tokens, session cookies, or login recovery data in this repository, `AGENTS.md`, automation memory, documentation, logs, or commits. When the user supplies the password in an authorized conversation, use it only in the live Naver login form. - If another Naver account or blog is active, stop before any representational action, sign out through Naver's visible account controls, and sign in with the authorized ID. If the authorized session expires and no fresh password was supplied, request a new authorized login instead of guessing or recovering secrets from files. - Use the signed-in in-app browser session. Unless the user explicitly requests a draft, a publishing request means an actual public post and requires opening the public post after publishing. - The blog profile must remain `오피셜메일 블로그`, nickname `오피셜메일`, and topic `IT·컴퓨터`. Do not replace the profile image or mobile cover unless the user explicitly requests it. ## Naver Categories - Prefer these categories for new articles. If they do not exist yet, create them under `오피셜메일 가이드` before publishing: - `1인기업·창업`: solo-business operations, idea validation, MVP launches, pricing, first customers, and founder lessons. - `바이브코딩`: AI-assisted product development, tools, workflows, launches, failures, and security. - `브랜딩`: positioning, naming, trust, visual consistency, brand voice, and customer perception. - `마케팅`: content, search, distribution, customer acquisition, conversion, retention, and measurable experiments. - `운영 인사이트`: productivity, automation, customer support, small-team systems, and practical business operations. - Keep these existing categories for supporting mail and DNS content: - `기업메일 시작하기`: company email creation, free business email, mailbox setup, and beginner onboarding. - `도메인·DNS 설정`: domains, registrars, MX, SPF, DKIM, DMARC, and DNS verification. - `메일 반송·보안`: Gmail 550 errors, delivery failures, sender authentication, spam, and security. - `AI 메일 활용`: AI summaries, reply relays, mail automation, and productivity workflows. - `운영·성공 사례`: operating guides, customer scenarios, comparisons, and adoption cases. - Manage categories only from `https://admin.blog.naver.com/AdminMain.naver?blogId=kavenix&Redirect=Categoryinfo`. After adding or rearranging categories, click the page's `확인` button, wait for `성공적으로 반영되었습니다.`, reload the same URL, and verify every expected category is still present before writing the post. - If none of these categories accurately fits the article, create a concise category from that category-management page, save and reload it, and then publish to the new category. Do not force an unrelated category merely to avoid adding one. - Do not delete or rename historical categories with existing posts unless the user explicitly asks for cleanup or migration. ## Naver Tags - Naver does not provide a reusable preset-tag registry; tags are created and counted from published posts. Add tags during each post's publishing flow rather than trying to pre-create them in the tag management page. - Use `https://admin.blog.naver.com/kavenix/config/tag` only to verify or remove tags that already exist on posts. After publishing, reload this page and confirm the newly used tags are listed. - Always include `오피셜메일`, then add the exact primary search intent and 3-7 closely related tags. Avoid duplicate spelling variants, unrelated trending tags, and keyword stuffing. - Use these tag pools as starting points, selecting only tags that the article actually answers: - Solo business: `1인기업`, `1인창업`, `솔로프리너`, `창업기록`, `사업운영`, `작은팀`. - Vibe coding: `바이브코딩`, `AI개발`, `MVP개발`, `제품개발`, `업무자동화`, `노코드`. - Branding: `브랜딩`, `브랜드전략`, `브랜드네이밍`, `퍼스널브랜딩`, `브랜드포지셔닝`. - Marketing: `마케팅`, `콘텐츠마케팅`, `검색마케팅`, `고객획득`, `초기마케팅`, `전환율`. - Company email: `기업메일`, `회사메일`, `도메인메일`, `무료기업메일`, `회사이메일만들기`, `사업자이메일`. - DNS: `DNS설정`, `도메인연결`, `MX레코드`, `SPF`, `DKIM`, `DMARC`, `가비아도메인`. - Delivery and security: `Gmail550`, `메일반송`, `발신자인증`, `스팸메일방지`, `메일보안`. - AI: `AI메일요약`, `AI메일릴레이`, `메일자동화`, `업무자동화`. - Operations: `기업메일운영`, `쇼핑몰메일`, `1인기업`, `스타트업메일`, `고객응대`. ## Naver Publishing Procedure 1. Select a search-intent-focused topic from the five primary editorial pillars, supported by Search Console data, customer questions, or a real business-building experience. Use mail/DNS topics as supporting content rather than the default identity. 2. Write a materially original Korean article in Naver SmartEditor. Do not paste the internal, Blogger, WordPress.com, or DEV.to version verbatim. Give the article a natural answer-first opening, a coherent progression of ideas, descriptive SmartEditor `소제목` blocks, concrete examples, and a concise conclusion; do not publish a mechanically translated, formula-stacked, or fragmentary draft merely because all required facts are present. 3. Generate a Naver-only image set according to `Blog Image Standard`, using as many visuals as the article sections need. Use native SmartEditor paragraph styles, lists, links, image blocks, and captions. Do not reuse another platform's image, and do not expose raw Markdown markers, HTML, block directives, or editor-only syntax. Use the `소제목` paragraph style for section headings. Never create each section heading as a separate one-item ordered-list block, because every block restarts at `1.`. When the content genuinely needs ordered steps, keep all steps inside one contiguous native ordered-list block and verify that the public sequence renders once as `1, 2, 3...`. ### Naver SmartEditor Visual Standard - Treat `https://blog.naver.com/kavenix/224408020487` as the approved Official Mail Naver house-style baseline for all future posts. Use `https://blog.naver.com/wisedonkey/224379739320` only as a secondary visual-structure reference. These pages are layout references, not sources to copy: keep every sentence, example, and image original to the new Official Mail article. When the two references differ, follow the approved Official Mail post. - Reproduce the approved post's reading rhythm with native SmartEditor blocks: title and byline, a large full-content-width hero, a centered native quotation containing one short takeaway, two or three short opening paragraphs, then clearly separated large `소제목` sections. A normal article should have five substantial sections unless the search task genuinely needs fewer or more. - Build each section around a complete mini-arc: one descriptive heading, one or two short explanatory paragraphs, one concrete operating rule, example, checklist, or sequence, and one sentence explaining the practical consequence. Do not publish a thin AI-style outline made of headings plus one sentence each, and do not inflate the article with repetitive filler. - Place one Naver-only 3:2 landscape hero image immediately below the title and render it at SmartEditor's large or full-content width. The first screen should then contain one short hook or takeaway, not a dense wall of text. - Build the body as 4-6 native `소제목` sections. Do not number descriptive section headings. Keep most paragraphs to 1-3 sentences and insert line breaks only at semantic pauses so the mobile view reads as deliberate short blocks rather than arbitrary one-line fragments. Leave consistent breathing room before headings, images, quotations, and lists, matching the approved post without creating oversized empty gaps. - Use two wide Naver-only visuals as the normal baseline: the 3:2 hero and at least one section-specific explanatory image around a major argument change. Add up to two more only when another section genuinely benefits from a diagram, screenshot, or visual example. Keep the set visually coherent and place every image immediately beside the section it explains. Do not stack unexplained images, reuse another platform's asset, or rely on a single image for a multi-section article. Add a short Korean caption or accessible description when the editor exposes one. - Alternate block types so long pages do not become flat text: `wide image -> centered takeaway quotation -> opening`, then repeat a natural variation of `large heading -> short explanation -> bullet or numbered list -> example quotation or conclusion`. Do not force every section into the same pattern, but include at least one native quotation and at least one native list in a normal instructional article. - Use a native quotation for the strongest takeaway and a second quotation only when showing an actual or clearly labeled hypothetical email, script, or customer example. Use one contiguous ordered list only for genuine sequences, and native bullets for checklists or parallel criteria. Use a native divider between major arcs when it improves scanning. Never simulate these components with Markdown, repeated punctuation, manually typed list numbers, or plain paragraphs styled to look like headings. - Keep body text at one consistent readable SmartEditor size and neutral color. Use native heading styles for the clear large scale visible in the approved post instead of manually enlarging arbitrary paragraphs. Limit bold or colored emphasis to one short phrase per section; do not decorate every sentence or use multiple competing colors. - Preserve the approved post's conversational but useful tone. Open from a recognizable operating problem, ask at most one natural question when it helps, move quickly into a concrete rule, and use realistic examples that a solo founder or small team could apply immediately. Avoid generic motivational copy, fake case studies, unsupported figures, repeated conclusions, and sentences that read like an AI summary. - Finish with one concise conclusion and exactly one descriptive native text link or link card to the canonical Official Mail article. Raw URLs, clipboard attribution, duplicate cards, and pasted Markdown links are forbidden. - Before publication or update, inspect both the editor and public mobile-width rendering. Compare the first screen and at least two mid-article points against the approved house-style baseline. Verify a full-width hero near the title, a centered takeaway quotation, large consistent section headings, two or more well-placed visuals when the article structure warrants them, balanced image/heading/paragraph/list rhythm, continuous ordered-list numbering, readable crops, no broken placeholders, no raw markup, and no repeated `1.` headings. If the result is visually flat, text-only where a visual explanation is needed, too short to complete its search task, or materially unlike this standard, revise it before reporting completion. 4. Choose the matching Naver category using the mapping above. If the category is missing, create, save, reload, and verify it through the exact category-management URL before returning to the editor. 5. Set the post topic to `IT·컴퓨터` unless another Naver topic is materially more accurate. Keep `검색허용` and public visibility enabled unless the user explicitly requests otherwise. 6. Add `오피셜메일`, the primary query, and 3-7 relevant supporting tags in the publish panel. Do not reuse the entire tag pool on every article. 7. Add one contextual link or native link preview to the matching Official Mail guide, diagnostic tool, or canonical article at `https://officialsite.kr/`. For a text link, select a descriptive Korean label and use SmartEditor's `링크 입력 열기`; for a card, use `링크 추가`, wait for the title and description preview to load, and confirm it. Never paste the canonical URL as its own paragraph. Keep the article useful without requiring the reader to click the link, and remove duplicate link previews before publishing. 8. Publish publicly, open the returned Naver post URL, and verify the title, category, topic, tags, native heading hierarchy, links, images, captions, and mobile wrapping. Confirm that section headings are not rendered as repeated `1.` items, any real ordered list advances continuously, no paragraph is only a raw URL, and the canonical anchor or link card resolves to the intended destination. 9. Reopen `https://admin.blog.naver.com/kavenix/config/tag` and verify that the post's tags were persisted. Report the clean public URL in the form `https://blog.naver.com/kavenix/`; do not claim completion when only the editor or a draft is open. # DEV.to Publishing Runbook - Apply this runbook whenever a full-distribution content set includes DEV.to or the user explicitly requests DEV.to publishing. - Use only the configured and signed-in Official Mail DEV.to profile. Verify the profile identity immediately before creating, editing, publishing, commenting, reacting, or following; never act from another DEV.to account visible in the browser. - **Korean is the required default publication language for DEV.to.** Unless the user explicitly requests an English version, write the title, description, opening answer, headings, body, captions, image alt text, FAQ, and CTA in natural Korean. - Never switch a DEV.to article to English merely because DEV.to has an international audience, its interface or suggestions are in English, or many posts under a selected tag are in English. Standard product names, code identifiers, API names, and technical terms may remain in English where Korean wording would be less accurate. - If an English DEV.to draft exists for a Korean full-distribution article, do not publish it as-is. Rewrite it into a complete Korean article first. Treat an English translation as a separate deliverable that requires an explicit user request; do not replace the Korean version or publish both languages by default. - Write a materially original Korean version for DEV.to rather than translating sentence by sentence or copying the Official Mail, Blogger, WordPress.com, Naver Blog, or Medium version. Change the title, opening, section order, examples, paragraph rhythm, and CTA for DEV.to readers while keeping facts and the canonical destination consistent. - Keep the article useful on its own. Add one natural link to the matching canonical Official Mail article at `https://officialsite.kr/blog/...` and only the additional contextual links genuinely needed by the reader. - Select only relevant DEV.to tags within the platform's current limit. English tag names are allowed when they are the platform's established tag identifiers; tag spelling does not change the requirement that the article itself be written in Korean. - Generate a DEV.to-only image set according to `Blog Image Standard`. Do not reuse another platform's image, and do not expose local paths, generation metadata, unrendered directives, or broken Markdown image syntax. - Unless the user explicitly requests a draft, publish publicly. Open the public DEV.to URL and verify the Official Mail identity, Korean title and body, rendered headings and code blocks, images and alt text, tags, canonical link, mobile wrapping, and absence of unintended English sections or editor-only syntax before reporting completion. # X Publishing Runbook - Apply this runbook whenever a full-distribution content set includes X or the user explicitly requests an X post. - The only authorized X account is `@official__mail` (login identifier `official__mail`). Verify that exact handle from the compose or profile screen before publishing, replying, liking, reposting, following, or changing account settings. Never act from another X account visible in the browser. - Never store the X password, access tokens, session cookies, login recovery data, or authentication codes in this repository, `AGENTS.md`, automation memory, documentation, logs, or commits. When the user supplies the password in an authorized conversation, use it only in the live X login form for that run and retain the normal signed-in browser session when X allows it. - If the X session has expired, attempt the visible login flow with `official__mail` and the fresh password supplied for the current authorized run. If no fresh password is available or X requires an OTP, CAPTCHA, or external approval, stop before any representational action and request only the missing authentication step. - X is a short distribution channel, not the canonical article. Link to the matching canonical Official Mail article, guide, diagnostic tool, or landing page and keep that destination consistent with the post's actual topic. - Unless the user explicitly requests a thread, publish one standalone post that fits the character allowance shown by the current X composer. Do not assume a premium allowance and do not split the post into a thread merely to preserve a long draft. - Treat `@official__mail` as an X Free account with a 280-character limit unless the active composer explicitly shows a different allowance. Count the complete standalone post before entering it, including spaces, line breaks, hashtags, and the destination URL as X evaluates them; target no more than 260 raw characters when a URL is included so URL normalization and later edits do not cross the limit. - Before adding media and again immediately before publishing, verify that the composer shows no negative character count or limit warning and that the `게시하기` button is enabled. If an earlier over-limit draft remains in a background composer, clear or discard it before reporting status so it cannot be confused with the published post. - Write for the Korean audience with one clear hook, 2-4 useful points or one concise takeaway, and one destination link. Avoid vague promotional copy, keyword stuffing, engagement bait, excessive emoji, and more than two hashtags. - Generate exactly one new X-only landscape image for each post. Do not reuse the internal article hero or another platform's asset. Prefer an explanatory or editorial visual over a text-heavy poster, add meaningful alt text when X exposes the control, and verify the crop in the composer before publishing. - For the ordinary, clearly illustrative X image used by this runbook, do not manually enable the optional `AI로 제작됨` (also shown as `AI로 생성됨`) composer switch. Check its actual state immediately before publishing. If X automatically enables and locks this switch for the uploaded image, do not bypass the lock, strip provenance, or claim it is off; publish with X's automatic label and report that distinction accurately. Do not apply the optional-off rule to misrepresent photorealistic people, real events, or other potentially misleading synthetic media: if X or applicable law requires a disclosure for the actual asset, make the disclosure or omit that asset. - Unless the user explicitly requests a draft, an X publishing request means a public post. Do not infer success from a toast, a disabled background composer, or the home timeline alone. Open the resulting `https://x.com/official__mail/status/` URL and verify the text, link preview or destination, image, crop, alt text when available, timestamp, and the identity of the publishing account. # RocketPunch Publishing Runbook - Apply this runbook whenever a full-distribution content set includes RocketPunch or the user explicitly requests RocketPunch publishing. - The only RocketPunch target is the Official Mail profile at `https://www.rocketpunch.com/@officialmail/post`. Never publish from another personal or company profile visible in the signed-in account. - The authorized RocketPunch authentication path is `Google로 로그인` (`Continue with Google`). A logged-out RocketPunch homepage is not a final blocker until this visible Google sign-in flow has been attempted. - After Google authentication, verify that the signed-in profile resolves to `https://www.rocketpunch.com/@officialmail`, displays `오피셜메일`, and shows the existing Official Mail profile and posts before posting, commenting, Boosting, reposting, following, or changing profile settings. The account owner confirmed on 2026-09-29 that they changed this profile's display name from `이상현` to `오피셜메일`; the old personal-name check is obsolete and must not block activity on this verified account. If the handle, displayed profile, or existing post identity does not match, stop before the representational action and switch to the authorized Google account through visible account controls. Do not infer identity from a name alone or act from another profile. - Never store Google credentials, OAuth codes, access tokens, refresh tokens, session cookies, or recovery data in this repository, `AGENTS.md`, automation memory, documentation, logs, or commits. Keep the normal authenticated browser session when RocketPunch and Google offer session retention. - Treat RocketPunch as a concise business-update channel, not the canonical article. Write a materially original Korean post with one clear operating insight, 2-4 practical takeaways, and one contextual link to the matching canonical Official Mail article. - Generate a RocketPunch-only image when the composer supports image attachment and the visual improves comprehension. Never reuse an image from the internal article or another external platform, and do not expose local paths, generation metadata, raw Markdown, or editor directives. - Unless the user explicitly requests a draft, publish publicly. Open the resulting post URL and verify the `officialmail` identity, body text, canonical link, image or link preview, mobile wrapping, and public visibility before reporting completion. # Disquiet Publishing Runbook - Apply this runbook whenever a full-distribution content set includes Disquiet or the user explicitly requests Disquiet publishing. Short commands such as `블로그 작성해줘` include Disquiet in the daily full-distribution run. - The only Disquiet target is the `오피셜메일` profile at `https://disquiet.io/profiles/RKt6N4n`. Immediately before writing, recommending, commenting, or following, verify the visible profile name `오피셜메일`, profile ID `RKt6N4n`, and the attached product `오피셜메일`. Stop before any representational action if another profile is active. - Use the retained authenticated browser session. Never store a Disquiet password, access token, session cookie, login code, or recovery data in this repository, `AGENTS.md`, automation memory, documentation, logs, or commits. If the retained session expires, use the site's visible sign-in flow and request user input only when authentication itself requires it. - Treat Disquiet as a Korean founder and product-building publication channel. Write a materially original article for builders, solo founders, and small teams with one clear business problem, a firsthand operating observation, 3-5 practical decisions or checks, and a useful conclusion. Lead with the reader's business decision; avoid making protocol names, infrastructure terms, or product promotion the article's organizing idea unless the user explicitly requests technical documentation. - Use the native rich-text editor for headings, paragraphs, lists, emphasis, and links. Attach the canonical Official Mail URL to a concise descriptive Korean label with the native link control; never leave a standalone raw URL paragraph. When the editor has no native image or media block, publish clean text without exposed Markdown, HTML, local paths, or editor metadata rather than forcing an image into the body. - Unless the user explicitly requests a draft, `게시` means public publication. Open the resulting `https://disquiet.io/articles/` URL and verify the `오피셜메일` author identity, Korean title and body, heading and list flow, working canonical link, public visibility, and absence of raw editor syntax before reporting completion. Synchronize or edit the existing article instead of creating a duplicate when the same canonical source has already been distributed. # Reddit Publishing Runbook - Apply this runbook whenever a full-distribution content set includes Reddit or the user explicitly requests Reddit publishing. The only authorized Reddit identity is `u/official__mail` at `https://www.reddit.com/user/official__mail/`; verify that exact username immediately before posting, commenting, voting, following, joining, or changing profile settings. - Interpret a standalone request equivalent to `레딧 활동해줘` as activity-only. Do not create a profile post, subreddit post, cross-post, poll, or affiliated link from that request. Reddit publication requires a separate explicit request that identifies publishing intent; activity wording alone never implies permission to publish. - Keep the Reddit profile clearly identified as `오피셜메일` and use no more than the five profile links Reddit permits. Prefer the Official Mail website, Naver Blog, Instagram, X, and Medium; keep the public avatar and banner consistent with the Official Mail brand. The Reddit profile introduction is user-authored content: preserve the existing introduction verbatim and never generate, translate, rewrite, or replace it during routine publishing or profile maintenance unless the user explicitly supplies and approves the replacement text. Do not claim that any profile setting can guarantee protection from suspension. - Use the retained authenticated browser session. Never store Reddit passwords, recovery codes, OAuth tokens, session cookies, or CAPTCHA data in this repository, `AGENTS.md`, automation memory, documentation, logs, or commits. If Reddit shows a CAPTCHA, account warning, age or karma gate, or moderator approval requirement, stop before the blocked action and follow the visible official flow instead of bypassing it. - Treat Reddit as a discussion community, not a bulk syndication endpoint. Before posting to any subreddit, read its visible rules, pinned guidance, flair requirements, self-promotion policy, account-age or karma requirements, and allowed language. Post only when the exact article format and destination are permitted. If no suitable subreddit is clearly eligible, publish a materially original English post only to the authorized profile and do not force a community submission. - **Use natural English for every Reddit action without exception during routine work:** profile posts, subreddit posts, titles, body copy, comments, and replies. Do not publish Korean or bilingual Reddit copy, and do not switch languages based on the source article. Write one useful, self-contained English post that answers a real solo-business, startup, vibe-coding, branding, marketing, or customer-operations question before mentioning Official Mail. Use a new title, opening, examples, and structure rather than translating another platform's draft sentence by sentence. Include at most one contextual canonical link when links are permitted; otherwise publish useful text without the link. - Never submit the same title or body to multiple subreddits, rapidly cross-post, repeatedly drop the same domain, use promotional comments to seed links, solicit votes, coordinate engagement, or disguise Official Mail's relationship to the linked site. Do not send unsolicited chats or direct messages. A quota never overrides a subreddit rule or account restriction. - Unless the user explicitly requests a draft, a Reddit publishing request means one verified public post. Open the resulting `https://www.reddit.com/user/official__mail/comments//...` or approved subreddit permalink and verify the `u/official__mail` identity, English title and body, flair when required, link destination when present, public visibility, and absence of raw Markdown or duplicated source text before reporting completion. ## Reddit Community Membership and Warm-Up Rules - The approved community set is limited to the thirty subreddits below. Before every vote, comment, or post, reopen that subreddit's live rules page and current pinned guidance; a newer live rule always overrides this stored summary. Do not expand the set, cross-post, or join another subreddit merely to satisfy a quota without a fresh user request and rule review. - Reddit is primarily a non-promotional reputation and contribution channel, not an Official Mail distribution channel. Default to zero Official Mail mentions, links, profile directions, product references, or affiliated posts even after the warm-up gate is met. Only consider an affiliated contribution when the user explicitly requests that exact Reddit post, the live community rules clearly allow it, and the contribution remains useful without the affiliation. Optimize for the chance of earning legitimate comment karma by answering early, specific, unanswered or weakly answered questions where the account has real relevant knowledge; never promise karma, chase engagement bait, manufacture controversy, or treat raw activity volume as success. - Treat the Reddit account as being in warm-up until all of these conditions are true: the account is at least 30 days old, combined karma is at least 100, at least 10 verified non-promotional contributions have remained public across at least five separate days, and there is no removal, warning, restriction, or moderator complaint. Until then, do not create subreddit posts, mention Official Mail, link to an Official Mail property, direct readers to the profile, request DMs, or reuse another platform's article. Profile-only publication also remains disabled during warm-up unless the user explicitly requests it. - Warm-up activity is for genuine participation, not artificial karma farming. Casting an upvote does not itself earn karma; never report otherwise. Upvote only genuinely useful posts, never downvote competitors, and write a natural English comment only after reading the complete post and identifying a specific detail to address. Skip the comment rather than inserting generic praise or mechanically translated copy. Limit each community to at most two comments per day, separate actions naturally, and never ask for or coordinate votes. - Within one active Reddit activity request, place a freshly chosen delay of 3 to 7 full minutes between actions that change account or public state, including joining, following, voting, commenting, and replying. Do not maintain a separate next-eligible timestamp, background action queue, or permission window after that requested activity pass ends. Read-only navigation, scrolling, opening a post, reading its comments, and leaving without acting are normal parts of the pass and are not state-changing actions. Record verified actions and the elapsed inter-action delay in automation memory, but do not schedule later Reddit actions unless the user makes another activity request. This pacing is not permission to bypass warnings or platform controls: stop immediately on a CAPTCHA, rate limit, warning, restriction, or uncertain account state. - Match each Reddit comment's length to the contribution it genuinely needs. A concise one- or two-sentence English response is valid when it directly answers a specific point, while a more detailed answer is appropriate only when the question needs it. Vary comment length naturally across the activity history rather than forcing every response into one template or target count. Never pad a comment, shorten it until meaning is lost, generate cosmetic variants, or post generic praise merely to create the appearance of variety. The complete-post review, specificity, originality, English-only, non-promotional, and duplicate-prevention requirements remain mandatory at every length. - Match the voice to the individual subreddit's established conversation style after reading several current human-written threads and comments. Use natural international Reddit English, including ordinary contractions, direct phrasing, light informality, and brief humor only where that community already uses them. Avoid stiff business copy, essay-like framing, repeated openings, over-structured lists, excessive caveats, generic summaries, marketing language, and polished template cadence that would feel out of place in the thread. Do not force slang, imitate a nationality or dialect, invent personal experience, pretend to be another kind of user, or sacrifice accuracy merely to sound casual. Reread every draft beside the source thread and skip it if it still sounds interchangeable, performative, or machine-generated. - Make each standalone activity pass exploratory rather than quota-driven. Review the account's notifications and replies to existing comments first, then browse approved communities naturally. It is valid to read and scroll through a post, inspect several comments, and leave without any reaction. Upvote only when the content is genuinely useful, accurate, or entertaining; never select a vote merely to randomize the ledger. Comment only when a specific, useful English response is warranted. When another user has replied to an existing `u/official__mail` comment, read the full thread and add one concise English follow-up only when it answers the new point without promotion or repetition. Vary the mix of read-only visits, upvotes, comments, and follow-up replies according to what the inspected content actually supports, not a mechanical action pattern. - For each standalone Reddit activity request, inspect at least 30 distinct current items across the approved communities when that many safe, accessible items are available. One item means one unique post or one unique reply thread opened and substantively reviewed; repeated visits, feed impressions, duplicate URLs, opening and closing the same item, or multiple scrolls inside one item never create extra units. Public upvotes, comments, and replies may count within the 30 only once per unique target, but there is no minimum public-action quota and no permission to manufacture engagement. Record the 30 distinct permalinks or stable identifiers and whether each was read-only, upvoted, commented on, or replied to. If fewer than 30 eligible items are available after reasonable review, stop with the verified count and reason instead of lowering the standard or acting on unsuitable content. - Do not treat 30 read-only reviews by themselves as a completed `레딧 활동해줘` pass. The 30-item requirement is a minimum substantive review set, not a substitute for the exploratory activity mix above. After reviewing suitable candidates, deliberately evaluate whether the inspected content supports genuine upvotes, specific English comments, or warranted follow-up replies, and include those public actions when they are justified and permitted. Never force an action merely to avoid an all-read-only result. If no public action can safely be completed because no candidate warrants it, an account or community restriction applies, required confirmation is unavailable, or a platform control blocks the action, label the result explicitly as a read-only or incomplete activity pass and report the exact reason instead of claiming Reddit activity complete. - After the warm-up gate is met, posting is still opt-in per community and per article. Recheck the live rules, account eligibility, language fit, recent contribution history, flair, link and self-promotion limits, then post only if every requirement is satisfied. If the fit is uncertain, keep that community activity-only and do not contact moderators merely to force distribution. - `r/smallbusiness`: this is a question-and-answer community. Subreddit posts must be genuine small-business questions. No links, product recommendations, unsolicited advice, blog/SEO content, or business promotion outside the designated weekly threads. Routine comments must answer the exact question without an Official Mail mention. - `r/startups`: startup discussion only; no direct sales, advertising, or promotion. A normal submission must be specific, purposeful, and at least 250 characters without tying the discussion to a project name or URL. Comment links must be unaffiliated and explained. Own-blog sharing requires prior moderator approval and the full article body; no PM/DM solicitation. - `r/solopreneur`: no disguised self-promotion or affiliate links. Any future allowed self-reference must be direct and transparent, never clickbait, and never request a DM. During warm-up, use no self-promotion at all. - `r/indiehackers`: self-promotion is limited to one use of the Self Promotion flair and must seek feedback or critique rather than advertise. Revenue/MRR claims require proof, and “what did you build” posts must never be used for karma farming. Keep activity non-promotional until the warm-up gate is met. - `r/EntrepreneurRideAlong`: remain respectful, follow Reddit-wide rules, and participate only with a good-faith intent to help others succeed. Do not turn progress or case-study discussion into a product pitch. - `r/microsaas`: content must be directly about Micro SaaS. No low-effort promotion, repetitive links, generic build-in-public updates, unethical growth tactics, scraped-email spam, astroturfing, vague get-rich posts, paid-course drops, or DM requests. A future product post must include meaningful backstory, implementation context, or a concrete lesson. - `r/B2BSaaS`: no spam or astroturfing; disclose every affiliation. Contributions must provide value and remain professional. Self-promotion is capped at one post per project or domain every 10 days, but Official Mail promotion remains prohibited during warm-up and may be stricter under the global ratio below. - `r/SaaSSolopreneurs`: keep every contribution on SaaS or solopreneurship, use descriptive titles, and provide experiences, resources, challenges, or insights rather than a pitch. Self-promotion must remain below 20% of activity and include useful context; Official Mail promotion remains zero during warm-up. - `r/saasbuild`: product promotion is allowed only when accompanied by real learning; journey posts need examples, and feedback requests must be specific. Do not use the community for bare links, unnecessary updates, or repeated launches. - `r/GetStartups`: disclose what a shared project is and what problem it solves; no misleading title, exaggerated claim, or hidden intent. Product links require context and value, and all content must relate to startups, SaaS, apps, indie projects, or founder experience. Stay respectful and constructive. - `r/SaaS`: keep every contribution directly relevant to SaaS. No vendor spam in posts or comments, selling, solicitation, fundraising, promotional or advertising SaaS, low-effort content, or generic audit and feedback offers. Use this as a non-promotional answer channel only. - `r/SideProject`: the live information page currently exposes no detailed community-rule list. Treat it as activity-only and high-caution: recheck the current sidebar, pinned guidance, and post-specific context before every action, never add an Official Mail mention or link, and skip any target that is primarily a promotional drop or cross-post. - `r/growmybusiness`: advice posts belong in the current monthly thread. No selling, upselling, blog posts, external surveys, or feedback requests. Routine participation must be a civil, self-contained answer to the exact business-growth question without a product reference. - `r/Emailmarketing`: stay strictly on email marketing rather than cold-email outreach. No cold email, data brokering, financially motivated advice, low-quality contribution, or excessive self-promotion. Prefer concrete answers about permission-based campaigns, lifecycle messaging, deliverability, testing, segmentation, and measurement without naming Official Mail. - `r/ProductManagement`: no self-promotion, spam, research requests, AI-generated posts, off-topic or low-quality posts, beginner career posts, or standalone rants outside the designated threads. Keep this community comment-only for routine work and respond only to a specific product-management decision or practice visible in the full post. - `r/webdev`: no self-promotion, commercial solicitation, vague software-support questions, low-effort posts or comments, or feedback requests outside the current Saturday flow. Routine activity is limited to technically accurate, non-commercial comments on fully read development discussions; do not mention Official Mail. - `r/analytics`: no blog spam, advertising, or promotion. Keep comments specific to the visible analytics question, distinguish measurement evidence from assumptions, and use designated career guidance surfaces when the current rules require them. - `r/content_marketing`: no spam, low-quality or off-topic content, self-promotion, offers, or prohibited SEO cross-posts. Contribute only original, post-specific observations about audience, distribution, measurement, editorial workflow, or content operations without linking to an affiliated property. - `r/Entrepreneurship`: remain respectful, avoid self-promotion, low-effort contributions, and surveys or market research without prior approval. Use the community for direct, useful answers to concrete entrepreneurship questions, never for product seeding. - `r/Startup_Ideas`: the current sidebar allows discussion of startup ideas but states that the community is not a place to promote a company or product. Treat it as activity-only by default, give candid idea or validation feedback without mentioning Official Mail, and avoid promotional threads, affiliate drops, and requests to move the conversation to DM. - `r/technicallythetruth`: submissions must be image or video posts whose premise is technically true but contrary to the expected answer. No text-only or low-effort truth statements, recent reposts, off-topic content, outside links, spam, politics, insults, or threats. During warm-up use this as a lightweight activity channel only and engage only after the full image or video premise is understood. - `r/AdviceAnimals`: posts must use the Advice Animal format and be original content created that day. No bigotry, personal attacks, death encouragement, vote bait, cake-day posts, vertical memes, Unpopular Opinion Puffins, real-life acquaintances, reposts, or indirect website links. Keep routine participation non-promotional and do not create a submission during warm-up. - `r/memes`: all submissions must be genuine captioned memes, non-political, nonviolent, original, uploaded directly to Reddit, and free of identifying information, watermarks, interaction bait, spam, chainposting, prohibited templates, and AI-generated media. Because this is an AI-assisted workflow, treat `r/memes` as upvote-only unless the user personally supplies the exact comment or a future live rule explicitly permits AI-assisted comments; never generate or submit a meme here. - `r/ExplainTheJoke`: participate only to explain the specific visible joke without judging the person who asked. No low-effort questions, already-understood jokes, simple search-answerable text, current-events or political debate, promotion, fundraising, self-advertising, self-harm material, or unrelated replies. Comment only when the complete image and context are visible, the explanation is accurate, and the same explanation is not already present. - `r/mildlyinteresting`: posts must be concise, exact descriptions of original unedited photographs. No memes, related-response posts, cross-posts, reposts, screenshots, screen photographs, computer-generated images, albums, jokes, backstory, or title fluff. Treat this as activity-only during warm-up and never submit generated media. - `r/oddlysatisfying`: no number posts, memes, violence, compilations, products, YouTube links, NSFW material, recent or highly upvoted reposts, false OC claims, spam, unkind conduct, ordinary cute-animal posts, or AI-generated submissions. Use it for carefully reviewed lightweight activity only; do not generate posts or generic reactions. - `r/notinteresting`: content must genuinely be uninteresting without becoming blank, contextless, or extremely low effort. No spam, reposts, gore, violence, sexual content, comment bait, contextless selfies, Reddit meta, memes, or politics. During warm-up use only lightweight activity on harmless posts whose full image and title have been checked. - `r/Unexpected`: submissions must contain a real unexpected twist in a directly uploaded video or GIF without revealing it in the title. No incivility, death, abuse, glorified violence or tragedy, politics, pictures of text, stolen content, recent reposts, Reddit links, or low-quality media. Keep participation activity-only during warm-up and inspect the full twist before any reaction or comment. - `r/IRLEasterEggs`: submissions must show a genuine, intentionally hidden real-world detail. No NSFW content, recent or highly popular reposts, barcode posts, bigotry, trolling, or meta posts and comments. Use as a non-promotional observation channel and react only after the purported easter egg is visible and credible. - `r/Perfectfit`: content must show an unexpected and satisfying physical fit. No pornography, alignment or desktop screenshots, artisan-made fits, pet fits, tapered objects or ordinary containers, recent or top reposts, low-effort fits, or car doors. Keep comments civil and specific, and do not create submissions during warm-up. - Do not join or interact through this AI-assisted workflow in communities whose current rules explicitly require human-written participation or prohibit bots, LLMs, machine-generated content, or bot-like activity. The reviewed exclusions currently include `r/ProgrammerHumor`, `r/wholesomememes`, `r/funny`, `r/me_irl`, `r/workmemes`, `r/officememes`, `r/PeterExplainsTheJoke`, `r/NoStupidQuestions`, `r/AskReddit`, `r/CasualConversation`, and `r/AnimalsBeingDerps`; recheck the live rule before revisiting any exclusion. - Across all thirty communities, keep routine Official Mail-affiliated activity at zero under the non-promotional default above. If the user explicitly authorizes a specific eligible affiliated contribution after the warm-up gate, keep it below the strictest applicable community limit and never exceed one affiliated post per 20 genuinely non-promotional contributions. A community's tighter rule overrides this ratio. Record community, permalink, action, rule check, language fit, and verification result in automation memory; a removed or hidden contribution does not count and pauses future posting in that community until reviewed. - A one-time user-requested membership expansion may join multiple newly approved communities only after each live rule set and current activity level has been reviewed and the account identity has been reverified. This setup exception changes membership only; it does not relax the routine limit of at most one new relationship action per activity pass and does not authorize a burst of votes or comments across all newly joined communities. # Post-Publication Platform Activity Runbook - Apply this runbook only after the canonical article and every requested external version are public and their public URLs have passed QA. Publication quality and verification always take priority over feed activity. - For full-distribution requests, including `블로그 작성해줘`, continue with a short, organic activity pass on every configured and authenticated external platform: Blogger, WordPress.com, Tistory, Naver Blog, DEV.to, Medium, Disquiet, X, RocketPunch, Reddit, Instagram, and Threads. - Verify the active account or profile immediately before interacting. Never like, react, comment, follow, connect, or message from another account that happens to be visible in the browser. - A full-distribution activity pass is complete only after every configured platform has completed its full platform-native activity set across distinct relevant external creators or posts. Where the native functions exist, the target per platform and per publishing run is at least 5 lightweight reactions, about 3 substantive public comments, responses, or replies, and 2 selective reposts, reshares, or reblogs. The set also allows at most one new relationship action only where the platform-specific rules permit it; WordPress subscriptions and follows are prohibited. Publication alone, opening a feed, doing only one reaction, or recording an unsupported action as completed does not satisfy this requirement. - Instagram and Threads are explicit exceptions to the general comment quota: never leave public comments, replies, quote-post commentary, Story replies, or direct-message reactions during platform activity. For these two platforms, record comments and replies as `not permitted` and complete only the allowed native set of likes, public reposts when available, and relevant follows. - Maintain a per-platform completion ledger throughout the activity pass with separate counters for reactions, public comments or replies, reshares, and relationship actions. Count an action only after reading back its authoritative public state: the reaction control is active, the exact non-empty comment appears publicly under `오피셜메일`, the repost or reblog has a public state or URL, and the follow or request state is visible. Treat alerts, filled-but-unsubmitted editors, drafts, and opened dialogs as incomplete. Before reporting completion, reconcile every ledger total against the platform quota and record the verified totals and stable public identifiers in automation memory. - Find recent posts that materially overlap the five editorial pillars or the current article's primary search task. Inspect enough plausible items to select at least 5 distinct, genuinely relevant, useful, and safe posts for the Official Mail identity. Spread the 3 comments across distinct posts or conversations. Choose the 2 reshares non-mechanically from the strongest eligible posts instead of simply resharing the first two items. - Per platform and per publishing run, follow, subscribe, or request a relationship with at most one new relevant account only where the platform-specific rules permit it. WordPress must have zero new subscriptions or follows. Use at least 5 lightweight reactions on distinct relevant posts, add about 3 post-specific substantive comments, responses, or replies, and selectively reshare 2 relevant posts where that platform has a clear native reshare function. When a platform genuinely lacks reactions, public comments, or reshares, mark only that unsupported action type as `not applicable` and do not invent a substitute. Never follow an account or write a comment merely to fill the count when the creator is not relevant to Official Mail's editorial pillars. - Write every comment or reply specifically for the referenced post. Add a concise observation, practical experience, respectful question, or useful distinction; never paste the same response across platforms, summarize the author's post without adding value, or insert an Official Mail link merely for promotion. - This post-specific relevance requirement is absolute and applies without exception to every configured platform where public comments, responses, or replies are allowed, including Blogger, WordPress.com, Tistory, Naver Blog, DEV.to, Medium, Disquiet, X, RocketPunch, and Reddit, plus any comment-capable platform added later. Platform style may change the tone and length, but it never relaxes the requirement that the response match the exact source post. - Before drafting any allowed public comment or reply, read the target's full visible title, opening, body, media or caption, and conclusion or question. Identify one concrete claim, example, constraint, result, or question that actually appears in that post, and make the response directly address that detail. Never infer a topic from the title, search snippet, hashtag, account biography, or another post in the thread and then leave a generic adjacent response. - Use the deliberate comment sequence `read the complete target post -> note the specific detail being answered -> draft one original platform-native response -> reread the post and response together -> confirm that the response would make no sense if pasted under an unrelated post -> submit -> reopen or reload -> verify the exact public text and author identity`. If the response remains interchangeable, only restates the post, or cannot be supported by the visible content, rewrite it or skip that target. Activity quotas never justify an irrelevant or weakly related comment, and comments must not be rushed or batch-generated from uninspected URLs. - Do not react to Official Mail's own new post to simulate engagement. Reply to genuine reader comments when an accurate, helpful response is available, but never fabricate a conversation or use another controlled account to create social proof. - Do not indiscriminately mass-like, mass-follow, exchange engagement, use generic praise, post engagement bait, or send unsolicited direct messages. The 5 reactions, 3 comments, and 2 selective reshares are deliberate per-run editorial activity across distinct relevant posts, not a rapid engagement burst. Relationship actions are limited to one relevant creator per platform per run, must be supported by a specific editorial overlap recorded in memory, and must never be removed and recreated to simulate growth. - Keep activity platform-native: - Blogger: if the Reading List has no relevant current items, find current relevant Blogspot posts through normal search, add at most one blog to the public Reading List, verify the `오피셜메일` Blogger/Google profile in every comment form, and leave about 3 substantive comments across distinct posts without promotional links. Blogger does not have a consistent native like or repost control across blogs, so mark those action types `not applicable` when they are absent rather than substituting another action. - WordPress.com: use Reader topics related to the article, like at least 5 useful posts, and leave about 3 concrete comments across distinct posts. Never subscribe to or follow third-party sites, channels, or authors, including through recommended-site dialogs; record relationship actions as `not permitted` with a zero target under `WordPress.com No-Subscription Rule`. Reblog 2 of the strongest eligible posts only when the Reader exposes its native reblog function. Verify the public profile is `오피셜메일` before interacting. - Tistory: browse recent Korean Tistory posts with direct overlap in solo business, entrepreneurship, product operations, branding, marketing, business email, or practical AI use. Verify the signed-in profile and blog identity before acting, add 공감 to at least 5 distinct useful posts when the native control is available, and leave about 3 specific Korean comments across distinct fully read posts without promotional links. Tistory has no general native repost requirement, so record reshares as `not applicable`. Subscribe to at most one consistently relevant blog only when its recent work shows durable editorial overlap; never use reciprocal-subscription language, engagement bait, or a relationship action merely to fill a quota. - Naver Blog: do not send `서로이웃` requests or one-way `이웃추가` requests during routine platform activity. Select targets only from recent posts with clear editorial overlap, add `공감` to at least 5 distinct relevant posts, and write about 3 specific Korean comments across distinct posts without keyword stuffing. Naver Blog has no direct repost equivalent required by this runbook, so mark reposts and relationship actions `not applicable`. - For every Naver comment, use the exact verification sequence `enter text → read the actual contenteditable value back → confirm it is non-empty and matches the intended comment → click 등록 → reload or reopen comments → verify the comment count increased and the exact public comment appears under 오피셜메일`. Never click `등록` or count a comment as complete before the editor-value check, and never treat a blank-submit alert as a published comment. - DEV.to: browse the most relevant tags, follow at most one relevant author, add at least 5 appropriate reactions across distinct strong technical or operating posts, and leave about 3 constructive comments grounded in distinct posts. Mark reposts `not applicable` when DEV.to does not expose a native repost function. - Medium: browse the closest topic pages, follow at most one relevant writer, clap once on at least 5 distinct relevant stories, and write about 3 thoughtful responses across distinct stories. Use Medium's native `Repost` on 2 selectively chosen stories when it is exposed; mark reposts `not applicable` only when the signed-in surface genuinely does not provide the function. - X: follow at most one relevant account, like at least 5 distinct relevant posts, write about 3 concrete replies across distinct posts, and repost 2 selectively chosen posts. Do not quote-post solely to expose the canonical link. - RocketPunch: follow at most one relevant business or product-building profile, Boost at least 5 distinct relevant posts, leave about 3 professional comments across distinct posts, and use the distinct native `재게시` action on 2 selectively chosen posts. Treat Boost and `재게시` as separate actions, and do not send unsolicited messages. - Disquiet: browse recent articles about solo business, product building, branding, marketing, customer operations, or practical AI use. Recommend at least 5 distinct useful articles, leave about 3 specific Korean comments across distinct articles, and follow at most one author whose recent work has a clear editorial overlap. Disquiet has no general native repost requirement in this runbook; mark reshares `not applicable` when the signed-in article surface does not expose a public reshare control. Count a recommendation only after the button shows its active state, and count a comment only after the exact text appears publicly under `오피셜메일`. - Reddit: first inspect the account's current standing, notifications, existing-comment replies, recent activity history, and the visible rules of every candidate subreddit. A full-distribution run may target 5 distinct useful upvotes and about 3 English comments only when inspected content genuinely supports them; a standalone `레딧 활동해줘` request instead uses the exploratory, variable activity-only behavior above and must not force those counts. Mix read-only post visits, comment-thread reading, useful upvotes, specific English comments, and warranted follow-up replies without a fixed sequence. Follow or join at most one clearly relevant account or subreddit when that relationship action is permitted. Reddit activity is English-only; do not publish Korean or bilingual comments. Do not put Official Mail links in routine comments, do not downvote competitors, do not comment only to promote the brand, and do not batch actions in a rapid burst. Reddit has no general native repost requirement for this activity pass, and activity-only requests never authorize cross-posting. - Instagram: verify that the signed-in profile is the authorized `오피셜메일` identity before any action. Browse recent Korean posts or Reels that overlap solo business, entrepreneurship, vibe coding, branding, marketing, or small-team operations. Like at least 5 distinct relevant items and follow at most one relevant creator. Use Instagram's native public repost on 2 selectively chosen items only when the signed-in surface exposes it and the repost state can be verified; otherwise mark reshares `not applicable`. Never leave comments or replies, respond to Stories, send emoji reactions, or send unsolicited direct messages during activity. - Threads: verify that the signed-in profile is the authorized `오피셜메일` identity before any action. Like at least 5 distinct relevant threads, repost 2 selectively chosen threads, and follow at most one relevant account. Never leave replies, comments, quote-post commentary, or direct messages during activity. Count only likes whose control is active, reposts whose public state is visible, and follows whose relationship state is visible under the authorized account. - If the first feed is low quality or irrelevant, use the platform's search, tags, topics, or normal web search to inspect additional current candidates. If the account identity is uncertain or the session is expired, stop that platform, request the correct login or profile, and resume after authentication. If no relevant safe target exists after reasonable search, do not manufacture engagement; mark the full activity pass incomplete and report the exact platform and reason instead of claiming all-channel completion. - Record the activity date, platform, each public URL or stable post identifier, action type, and a short reason in the automation memory. Check recent memory first and do not engage with the same external post again within 30 days unless responding to a new direct comment. Record per-platform totals separately for reactions, comments or replies, reshares, and relationship actions, including `not applicable` for unsupported native actions. - Report platform activity separately from publication URLs. Never claim that these actions guarantee impressions, clicks, followers, indexing, or search ranking.