Rfp Writing

Action: If a section's content belongs to 2+ other sections, it should not exist as a standalone section. Split and merge into the correct owners.

2. Redundancy Elimination

Before writing any requirement, check if it is already covered elsewhere:

• Cross-cutting concerns (signing, scanning, audit logging) are typically covered by a general deployment/release section. Do not repeat them in domain-specific sections.
• Cross-references (e.g., "see 3.1.5.1") are acceptable. Restating the same requirement in both places is not.
• When deleting a section, grep the entire document for its section number and update all references (tables, cross-references, footnotes).

3. Pain Point Filter

Every requirement must address a real pain point. Ask:

• Is this specific to the domain (e.g., artifacts are 100GB+ -- genuinely different from typical deployments)?
• Or is this standard practice already covered by general infrastructure (e.g., checksum verification -- any package manager does this)?

If it's standard practice, delete it. Only keep domain-specific requirements that would not be met by the general process.

Infrastructure standard practice test: If a section could appear verbatim in any K8s/cloud platform RFP with zero modification (e.g., secret management, HA control plane, CPU sizing, backup/restore), it is infrastructure boilerplate, not a domain-specific requirement. Either delete it or move it to the infrastructure layer where it belongs — do not give it a standalone section in the application layer.

3b. Cross-Section Consistency

After editing a section, check that its content does not contradict design principles stated elsewhere in the document. Common violations:

• One section says "不依賴本地儲存" while another section's design requires local storage
• Appendix defines baselines as "由廠商提出" while main body references those baselines as acceptance criteria

Action: Grep for key terms (design principles, architecture choices) and verify all sections align.

3c. Appendix Bloat

An appendix earns its place only if it adds concrete, quantifiable information not already in the main body. Kill appendices where:

• Most rows say "由廠商提出" or equivalent — that is not a baseline, it is punting the requirement
• The concrete values (e.g., 99.9% uptime, RPO/RTO numbers) are generic enterprise standards already implied by main-body sections
• The appendix merely restates requirements from the main body in table form

Action: Move any concrete numbers worth keeping into their parent sections, update all references, then delete the appendix.

3d. Thin Section Consolidation

A section with only 1-2 bullet points and no opening context explaining why it matters is a sign it does not justify standalone existence. Merge it into the nearest parent or sibling section as additional bullets or a short paragraph.

Test: If removing the section header and indenting its content under a neighbor loses zero information, the section should not exist independently.

4. Section Justification

A section earns its place by meeting both criteria:

1. Has a concrete use case in the current or next phase
2. Has enough substance to warrant standalone treatment (opening context + 3+ requirements)

Decision tree:

• Has first-phase use case + sufficient substance: Keep as a full section with requirements.
• Has first-phase use case but thin (1-2 bullets): Merge into the nearest related section.
• Has second-phase use case with clear scope: Keep as a subsection or remark (blockquote) under the related first-phase section.
• No concrete use case, only "might need later": Demote to a one-sentence remark. Do not create a standalone section for speculative needs.

5. Reference Integrity

After any structural change (section move, delete, renumber):

1. grep the full document for the old section number
2. Update every reference: tables, cross-references, blockquotes, appendices
3. Verify zero remaining references to deleted sections

Language Rules

Mandatory: Complete Sentences

Every bullet point must be a complete sentence that explains what and why. Reject:

BAD:  - 持久卷（PV/PVC）
BAD:  - HA（控制面與關鍵服務）
BAD:  - 備份/還原（設定、資料、索引）

GOOD: - 所有儲存須透過 CSI 驅動掛載為持久卷（PV/PVC），不依賴節點本地磁碟。
GOOD: - 控制面與關鍵服務須部署為高可用架構，單節點故障不中斷服務。

Mandatory: Section Context

Each section must open with 1-2 sentences explaining why this matters before listing requirements. The reader needs to understand the problem before reading the solution.

BAD:
#### 3.3.2 儲存
- PV/PVC 支援
- 高吞吐
- 分層儲存

GOOD:
#### 3.3.2 儲存
本平台的儲存需求與一般應用不同：核心檔案動輒數十 GB，索引需要持續高吞吐讀寫，稽核日誌須長期保留且不可竄改。

**需求：**
- 所有儲存須透過 CSI 驅動掛載...

Prohibited Patterns

Allowed Patterns (do not flag)

Workflow

Reviewing an existing RFP

1. Read the full document first
2. Run structural checks (placement, redundancy, pain point filter, justification)
3. Propose structural changes as a table: section, problem, proposed action
4. Get user confirmation before editing
5. After structural edits, run language audit (grep for prohibited patterns)
6. Fix language issues
7. Final grep to verify no prohibited patterns remain

Drafting a new section

1. Start with 1-2 sentences of context (why this section exists)
2. Add **Requirements:** header
3. Write each requirement as a complete sentence
4. Cross-check against existing sections for redundancy
5. Run language audit before presenting to user