AWX WI Generator Prompt

WI_DOC_INSTRUCTION.md

Ansible Playbook Documentation Specifications

Goal

Create a single-page HTML document at <PROJECT_ROOT>/docs/wi/<PLAYBOOK_BASENAME>.html that contains both a Work Instruction (WI) and a User Acceptance Test (UAT) for the playbook listed below.

Audience: System Administrators who will operate the playbook from AWX (not developers).

---

Reference

A reference document with the exact layout, CSS, fonts, components, and tone already exists in the sibling workspace:

.\awx-playbook-common-linux\docs\wi\password_policy.html

Read it first. Mirror its structure section-by-section. Do not invent new components. The style is intentionally formal/professional; do not use emojis.

---

Project-Specific Inputs

(Fill these placeholders in before executing the generation process)

• Playbook display name: <e.g. "Common - Disable Root SSH">
• Playbook file path: <playbooks/security/disable_root_ssh.yml>
• Role(s) used: <e.g. security/disable_root_ssh>
• Target OS family: <RHEL 7/8/9 | RHEL 5/6 Legacy | Solaris | Windows>
• WI document code: WI-<DETAIL-YYYYMM-NNNN>
• UAT document code: UAT-<DETAIL-YYYYMM-NNNN>
• Effective date (Thai BE): <DD/MM/YYYY e.g. 01/05/2569>
• Author: <Full name>
• One-line purpose (Thai): <e.g. "ปิดการ login เป็น root ผ่าน SSH โดยตรง">
• Files this playbook modifies: <list of absolute paths on target host>
• Hard backup paths produced: <list of *.YYYY-MM-DD.bak paths if the role produces them>
• Audit log path on target: </var/log/ansible-<name>.log>
• Survey fields (table input): <list of name / description / default / valid range — copy from surveys/<name>.json>
• Operational cautions: <bullet list of known caveats: lockout risks, package install assumptions, service restarts, distro support gaps>

---

Required Structure

(Must match the reference document explicitly)

Layout Elements

• <header>: Sticky top bar with shield SVG, document title, OS label, and a Print button.
• <aside>: Sticky Table of Contents (TOC) with two top-level entries (ส่วนที่ 1, ส่วนที่ 2) and their corresponding 1.x / 2.x sub-anchors.
• <footer>: Internal-use notice + last-modified date.

Content Sections

1. <section> Cover

• Pill badge labeled "เอกสารวิธีปฏิบัติงาน & การทดสอบยอมรับ"
• <h1> Thai title (English allowed for technical names)
• Lede paragraph (3-4 sentences outlining who and why)
• Two document-control tables positioned side-by-side:
  • WI Control Table & UAT Control Table
  • Required fields: รหัสเอกสาร / เวอร์ชัน / วันที่มีผลบังคับใช้ / ผู้จัดทำ / Job Template / Repository

2. <article> Part 1 — Work Instruction (วิธีปฏิบัติงาน)

Must include the following subsections strictly in this order:

• 1.1 วัตถุประสงค์: Purpose statement (2-3 sentences).
• 1.2 ขอบเขต: Scope, containing a bulleted list of supported OS versions and explicit "out of scope" entries.
• 1.3 ผู้รับผิดชอบ: Role and responsibility matrix table.
• 1.4 สิ่งที่ต้องเตรียม: Ordered prerequisite checklist.
• 1.5 ภาพรวมการทำงาน: Inline-SVG horizontal flow diagram featuring 5-7 step boxes, accompanied by a one-line caption below.
• 1.6 พารามิเตอร์ใน Survey: Table tracking: Field / คำอธิบาย / Default / ค่าที่ยอมรับ. (Skip this section entirely if the playbook does not utilize a survey).
• 1.7 วิธีรัน: Explicitly ordered step-by-step actions within the AWX UI.
• 1.8 ไฟล์ที่ถูกแก้ไข: Table mapping: File path / Role on system.
• 1.9 Backup และ Rollback: Details on paths, combined with a callout-info block containing exact cp -a fallback rollback commands.
• 1.10 Audit log: Target file path + structured log format description.
• 1.11 ข้อพึงระวัง: Bulleted list of operational caveats and edge-case behaviors.

3. <article> Part 2 — UAT (แบบทดสอบยอมรับ)

• 2.1 สภาพแวดล้อมการทดสอบ: Description of the test environment setup.
• 2.2 Test Cases: Produce between 6–9 test cases. Each case must be wrapped in a <section class="tc"> containing:
  • TC-NN identifier code (formatted in monospace)
  • A short title
  • Right-aligned Pass/Fail checkboxes
  • A two-column layout separating Steps and Expected Result
  • A single-line "Note:" entry field
  • Recommended baseline test cases:
    • TC-01: Run with WI defaults
    • TC-02: Verify config on target
    • TC-03: Backup files created (skip if role has no backup logic)
    • TC-04: Idempotency verification (re-run results in changed=0)
    • TC-05: Negative test (where applicable)
    • TC-06: Positive test (where applicable)
    • TC-07: Audit log entry confirmation
    • TC-08: Rollback procedure execution (if backups exist)
• 2.3 Sign-off block: Must feature:
  • Total / Pass / Fail outcome counters
  • Overall Pass/Fail radio buttons
  • Date input field
  • Tester name + title + signature line
  • Supervisor name + title + signature line
  • Remarks entry box

---

Style Rules

(Non-negotiable)

• Language: Thai. English text is permitted exclusively for technical variables, asset paths, terminal commands, and AWX field labels. Do not use automated translations for technical instructions.
• Typography: Google Fonts CDN deployment. Use Sarabun for general body text and JetBrains Mono for code fragments.
• CSS Framework: Tailwind CSS loaded via cdn.tailwindcss.com.
• Color Palette: Select ONE explicit accent color per OS family and use it universally (e.g., blue for modern Linux, amber/brown for legacy). Apply this same accent variable for h2 underlines, primary pills, and callout-info borders.
• Graphics: No emoji icons under any circumstance. Use native inline SVGs for all visual iconography.
• Interactivity: All input fields within the sign-off block must utilize native <input> elements to ensure the file can be filled out on-screen before printing.
• Print Optimization: Include specialized print CSS to hide the header and TOC navigation (.no-print), enforce page-break avoidance inside individual test case containers, and scale the font size cleanly to 11pt.
• Architecture: Maintain a completely self-contained, single HTML file ecosystem. No JS frameworks are allowed. CDN calls are permitted solely for typography and Tailwind CSS.
• Target Audience Filtering: Do NOT include code-level or developer-oriented artifacts. Exclude Ansible task names, Jinja2 syntax logic, raw role directory structures, execution environment/ansible-core variations, lint rules, or Docker configurations. This document is a functional operational manual, not a code reference.
• Philosophy: Treat this output with a mobile-app-manual level of technical abstracting. Cover preparation, what the script accomplishes, and how to execute it safely. Avoid implementation details or deep task-dependency graph mappings.

---

Output Expectations

• Generate exactly one file located strictly at <PROJECT_ROOT>/docs/wi/<PLAYBOOK_BASENAME>.html.
• Do not produce auxiliary readmes, index indices, or standalone asset files.
• Verify that the document loads seamlessly in a browser with zero console warnings or errors.
• Confirm Thai characters render flawlessly by validating that the file saves as UTF-8 (without BOM) and that the <html> root contains the explicit lang="th" property.

⚠️ When Information is Missing

If any of the PROJECT-SPECIFIC INPUTS are unclear, you MUST ask for clarification before generating the final artifact. Do not invent survey fields, backup paths, or audit log locations; they must accurately correspond with the actual underlying code implementation.