MASTER PROMPT — ADVANCED, PRODUCTION-GRADE, FUTURE-AI-READY
Government Document → Knowledge Archive → Blogger Publishing Automation System
ROLE
You are a senior Google Apps Script systems architect, production engineer, data architect, AI-integration architect, reliability engineer, and QA engineer.
Your task is to design and build from scratch the best possible version of a fully automated government-document processing, knowledge-archiving, and Blogger publishing system using the Google ecosystem:
Google Drive
Google Sheets
Gmail
Blogger
Google Apps Script as the orchestration layer
Gemini API as the external AI model
The source documents are usually government letters, orders, notices, circulars, office memoranda, notifications, or related official documents. They may be PDFs, scans, photographs, low-quality OCR, handwritten documents, or stamped documents.
The system must be unattended, resumable, fault-tolerant, auditable, quota-safe, and future-AI-ready.
ABSOLUTE INSTRUCTION ABOUT EXISTING REQUIREMENTS
The original requirements below are HARD constraints.
DO NOT alter, weaken, reinterpret, remove, merge away, reverse, reorder, relax, or silently replace any original rule, numeric limit, character rule, state-machine ordering, failure rule, validation rule, or “must/never” condition.
If you believe an original rule must be changed to make a new feature work, DO NOT make that change silently.
Instead:
Identify the exact old rule.
Explain the proposed change.
Ask the operator for approval.
Until approval is given, preserve the old rule exactly.
All NEW requirements in this prompt are ADDITIVE unless explicitly stated otherwise.
When an old requirement and a new convenience feature appear to conflict, the OLD requirement wins.
1. WHAT THE SYSTEM DOES — END TO END
One source document at a time enters the system and becomes:
one validated archival record,
one future-AI-ready knowledge record,
one publish-ready Blogger post, normally as a draft unless configured otherwise,
one thumbnail,
one auditable processing history.
The system runs unattended through exactly one recurring time-driven worker trigger.
Required pipeline stages, in order:
INTAKE
INTEGRITY / DUPLICATE CHECK
AI CONTENT GENERATION
AI CHECKPOINT
DUPLICATE-TEXT CHECK
BLOGGER DRAFT
THUMBNAIL GENERATION
ARCHIVE
DONE
The exact original state-machine ordering specified below remains authoritative.
1.1 EXACT PER-DOCUMENT STATE MACHINE — DO NOT CHANGE
Every document must use this exact sequence:
NEW
→ CLAIMED
→ HASHED
→ AI_PROCESSING
→ AI_CHECKPOINT
→ DUPLICATE_CHECK
→ DUPLICATE OR UNIQUE
→ BLOGGER_PENDING
→ BLOGGER_DRAFT
→ THUMBNAIL_PENDING
→ THUMBNAIL_DONE
→ ARCHIVE_PENDING
→ DONE
Cross-cutting states:
RETRY_WAIT
FAILED
The exact semantics remain unchanged:
CLAIMED prevents overlapping executions from claiming the same document.
HASHED performs the binary SHA-256 duplicate check before AI quota is spent.
AI_PROCESSING performs the AI workflow.
AI_CHECKPOINT is written immediately after a successful and validated AI response.
Once AI_CHECKPOINT exists, no later retry may call Gemini again for that document.
DUPLICATE_CHECK compares corrected text after the AI checkpoint.
BLOGGER_DRAFT MUST happen before THUMBNAIL generation.
Thumbnail failure must never recreate the Blogger post or call AI again.
ARCHIVE_PENDING is deliberately last.
FAILED is terminal.
RETRY_WAIT resumes from the exact failed state, never from NEW.
A timeout, crash, trigger overlap, authorization error, temporary API outage, or later-stage failure must never silently restart the document from stage 1.
1.2 AI CHECKPOINT — ABSOLUTE QUOTA-SAFETY RULE
This is one of the most important requirements.
After the AI call succeeds and the response passes validation:
Immediately persist the complete AI response.
Persist the checkpoint before doing anything else.
Persist enough information to resume every later stage without Gemini.
Record checkpoint timestamp and version.
Record the AI model/version used.
Record the source file hash.
After the checkpoint exists:
NEVER call Gemini again for that document merely because:
Blogger failed,
thumbnail failed,
archive failed,
the trigger timed out,
a later API failed,
the document entered RETRY_WAIT,
the worker restarted,
the script execution restarted,
a duplicate-text comparison failed,
an attachment update failed,
an archive write failed.
Any later retry MUST use the persisted checkpoint.
1.3 GEMINI FILE PROCESSING SUB-FLOW
The AI provider file workflow must be implemented exactly:
Upload the source file first.
Poll the provider-side file-processing state.
Wait until the file is ready/active.
Only then send the generation request referencing the uploaded file.
If file readiness exceeds the configured polling limit, treat it as transient.
Do not send generation requests against files that are still processing.
The system must distinguish:
upload failure,
file-processing failure,
file-not-ready timeout,
generation failure.
Do not falsely classify these as content-quality problems.
2. DUPLICATE SAFETY
2.1 Binary duplicate
Compute SHA-256 of the raw source file.
Check it against all relevant previously processed records BEFORE Gemini is called.
If an identical hash is found:
do not call Gemini,
mark the new document as DUPLICATE,
preserve the audit record,
move/rename it according to the duplicate-file rule,
safely terminate processing.
2.2 Corrected-text duplicate
After AI_CHECKPOINT:
use corrected_text as the ground-truth duplicate text,
compare it with previously processed corrected_text values,
use a robust similarity algorithm,
catch scans/photos of the same notice that have different binary hashes.
The corrected_text used for duplicate detection must never be truncated or summarized.
The duplicate threshold remains the configured threshold from the original specification.
2.3 DELETION SAFETY — ADDITIVE FUTURE-READY REQUIREMENT
The system MUST NOT depend on the physical continued existence of files in:
Duplicate folder
Failed folder
after their terminal processing record has been persisted.
Therefore:
Deleting a file from Duplicate or Failed folder later MUST NOT corrupt:
processing history,
duplicate history,
failure history,
knowledge archive,
Blogger record,
audit logs,
future-AI dataset.
The authoritative history must live in persistent metadata/database records, not in the continued existence of the terminal Drive file.
IMPORTANT:
Deleting a RETRY file while it is still required for continuation is different.
If an active document required for RETRY is manually deleted before completion, record an explicit source-missing failure instead of silently losing the document.
Do not treat RETRY files as disposable until their processing is complete.
2.4 FILE NAMING LIFECYCLE — ADDITIVE REQUIREMENT
Files moved into lifecycle folders must receive a deterministic, sanitized, collision-safe name.
Use this general pattern:
PREFIX_<letter_number><short_meaningful_name>.ext
Where:
PREFIX = U / D / F / R
letter_number = actual short reference number when legible
date = actual document date when clearly legible
short_meaningful_name = short factual meaning derived from the document
ext = original extension
Prefixes:
U_ = Unique / successfully processed document
D_ = Duplicate
F_ = Failed
R_ = Retry / currently waiting for retry
Examples:
U_123_20260829_Scholarship_Order.pdf
D_123_20260829_Scholarship_Order.pdf
F_123_20260829_Scholarship_Order.pdf
R_123_20260829_Scholarship_Order.pdf
Never fabricate a letter number or date.
If genuinely unavailable:
use a safe placeholder such as NA,
never infer a fake value.
Filename sanitization must prevent:
illegal path characters,
uncontrolled length,
line breaks,
duplicate separators,
accidental folder traversal,
unsupported characters,
unstable names.
When filenames collide, add a deterministic safe suffix rather than overwriting another document.
The file ID remains the authoritative identity; filename is only a human-friendly representation.
3. AI CONTENT-GENERATION CALL — ORIGINAL RULES REMAIN EXACT
Design the AI instruction prompt yourself, but it MUST enforce every requirement in Sections 3.0 through 3.12 of the original specification.
The following rules are NOT to be altered.
3.0 NO RAW MARKDOWN / FORMATTING LEAKAGE
The AI must never use markdown syntax anywhere.
No:
**
__
`
~~
markdown bullets
markdown numbering
The code must independently clean all text fields before use.
The AI prompt MUST explicitly instruct this.
Code cleanup is only the safety net.
3.1 MANDATORY OUTPUT FIELDS
The successful AI response must contain, at minimum:
corrected_text
blogger_title
summary
article_html
blogger_label
thumbnail_main_title
thumbnail_subtitle
seo_json
No successful response may leave mandatory fields empty.
3.2 BLOGGER TITLE
All original rules remain exactly:
12–22 words
natural human-quality headline
exactly one clause separator
maximum 120 characters
allowed character whitelist exactly as originally specified
no newline
no surrounding whitespace
no competing second headline
no separate alternate SEO title
Do not modify these limits.
3.3 ARTICLE HTML
All original structural and content rules remain exactly:
factual length driven by source
~1500 words is only a rough center
never omit facts to meet length
preserve tables completely
opening paragraph must be self-contained
2–5 document-specific subsections
no generic headings unless genuinely appropriate
no consecutive headings
no repeated generic headings across unrelated documents
no unnecessary Source heading
knowledgeable reporter-like explanation
practical meaning, affected groups, deadlines, next steps
zero filler
zero boilerplate repetition
exact markup whitelist
no images
no iframes
no external resource links
no styles/scripts/classes except the explicitly permitted wrapper
3.4 BLOGGER LABELS AND TAGS
All original rules remain exactly:
blogger_label = 1–3 words
tags = maximum 8
final platform label count = maximum 4
each final label = 1–3 words
Latin/basic machine-facing character set exactly as specified
no Devanagari in platform taxonomy field
total joined label length <150 characters
no duplicates case-insensitively
candidate labels must be skipped when they exceed the budget
do not truncate valid labels merely to force them into the budget
3.5 HIGHLIGHTS
When produced:
exactly 3–7 bullets
document-specific heading required
never use fixed generic fallback heading
omit the block if a genuine specific heading cannot be produced
heading must vary by document
normal-weight bullets
one important word/number emphasized per bullet
3.6 SEO JSON
Must contain valid structured data with:
headline
description
publish/modify dates
author
publisher
page identity
language
No fabricated:
reviews
ratings
prices
3.7 FAQ
Optional.
When present:
2–6 pairs
only real document facts
self-contained questions and answers
document-specific heading
clear question/answer labels during assembly
If there is insufficient genuine FAQ material:
omit it rather than fabricate it.
3.8 RELATED TOPICS
Optional.
When present:
3–6 short phrases
based only on document content
no fabricated URLs
document-specific heading
3.9 ATTRIBUTION
Preserve all original rules:
issuing_authority = clean short proper name
letter_number = only actual short reference token
do not guess illegible reference number
date/place only when clearly supported by source
3.10 RESERVED FUTURE FIELDS
Retain:
spoken/video script
corrected-source HTML
source outline
AI slug
The system must still derive its own authoritative slug from final title in code.
3.11 RESPONSE VALIDATION
Reject an AI result when:
invalid structured response
wrong expected shape
mandatory field missing
mandatory field empty
article_html is implausibly long
any code-enforced hard rule is violated
Never send unvalidated AI output to Blogger.
3.12 TWO ABSOLUTE BOUNDARIES
NEVER INVENT.
NEVER OMIT A REAL FACT.
A blank value is correct when the source is illegible.
A plausible fabricated value is always a failure.
Every real:
date
number
name
condition
table row
must survive into the output.
4. NEW — FUTURE-AI-READY KNOWLEDGE EXTRACTION
This is an additive extension.
It MUST NOT replace, reduce, merge away, or alter the original Blogger-oriented output.
The same successful Gemini request should also return a machine-readable:
knowledge_extraction
object.
The purpose is to build a high-quality government-document knowledge corpus for future:
RAG
semantic search
question answering
document comparison
knowledge graphs
domain-specific AI
training/evaluation datasets
future private/local AI systems
The new knowledge object must be generated from the source document only.
Never inject external facts.
Never allow knowledge extraction to cause omission from corrected_text.
4.1 KNOWLEDGE EXTRACTION SCHEMA
Add this structure to the AI response:
knowledge_extraction:
document_type
document_category
subject
sub_subject
issuing_authority
issuing_office
letter_number
document_date
effective_date
place
persons
organizations
locations
schemes
programs
departments
references
cited_documents
facts
conditions
eligibility
exclusions
deadlines
dates
amounts
percentages
thresholds
procedures
required_documents
responsibilities
beneficiaries
affected_groups
exceptions
consequences
tables
questions_answers
key_terms
search_text
source_quality
extraction_notes
Every field must obey the same fundamental rules:
source-grounded,
no invention,
blank when genuinely unavailable,
preserve exact numbers/dates,
preserve distinctions and conditions,
retain table information.
4.2 STRUCTURED FACTS
Do not store important facts only as prose.
Represent important facts in machine-readable form.
Example conceptual structure:
{
"fact": "...",
"value": "...",
"unit": "...",
"date": "...",
"scope": "...",
"condition": "...",
"source_evidence": "..."
}
Do not fabricate source evidence.
4.3 ENTITIES
Extract source-supported entities such as:
authority
department
office
person
organization
location
scheme
program
act/rule/order reference
subject
Keep spelling faithful to corrected source content.
4.4 CONDITIONS AND EXCEPTIONS
Conditions are especially important for future AI.
Never flatten:
“X applies only if Y”
into:
“X applies.”
Preserve:
if
only if
unless
except
subject to
not applicable
eligible/ineligible
deadline constraints
4.5 TABLE PRESERVATION FOR FUTURE AI
Every meaningful source table must be represented both:
in article output where required,
in machine-readable knowledge data.
Retain:
row order,
column meaning,
values,
units,
headings,
footnotes when they carry meaning.
Never discard a table because the article is long.
4.6 GROUNDED Q&A
The knowledge object may contain:
questions_answers
with 2–N source-grounded Q&A pairs as appropriate.
Every answer must be independently understandable.
Never invent answers simply to reach a target count.
4.7 SEARCH TEXT
Create a clean machine-searchable text representation containing the highest-value factual information from the document.
It must remain source-grounded.
Do not convert it into keyword spam.
4.8 SOURCE QUALITY
Where possible classify source quality using source-supported observations, such as:
clear
partially unclear
poor scan
handwritten
stamped
partially illegible
Do not convert uncertainty into false confidence.
4.9 REVIEW STATUS
New knowledge records must support a review lifecycle.
Recommended values:
UNREVIEWED
VERIFIED
CORRECTED
REJECTED
Do not mark data VERIFIED merely because Gemini generated it.
The default generated state is:
UNREVIEWED
This distinction is important for any future training dataset.
4.10 DATASET SPLIT
Support future dataset classification without forcing every document into training.
Recommended values:
UNASSIGNED
TRAIN
VALIDATION
TEST
EXCLUDED
Default:
UNASSIGNED
Never automatically place all records into TRAIN.
5. ARCHIVE ARCHITECTURE
Keep operational and future-AI data logically separate.
Recommended major structures:
DOCUMENTS
Operational document state and publishing audit.
Contains:
document ID
source file ID
source hash
current state
retry data
timestamps
Blogger post ID
thumbnail data
duplicate information
errors
completion state
ARCHIVE_KNOWLEDGE
Future-AI knowledge dataset.
Contains:
document ID
source hash
corrected_text
knowledge_extraction fields
search_text
metadata
review status
dataset split
knowledge schema version
AI model/version
checkpoint reference
created/updated timestamps
LOGS
Immutable/semi-immutable operational event history.
Every important transition should be auditable.
CHECKPOINT STORAGE
The complete AI response must be recoverable without re-calling Gemini.
For large payloads, use Drive checkpoint JSON files rather than forcing oversized data into a single Script Property.
5.1 SOURCE/ARCHIVE DECOUPLING
The authoritative identity is document_id/file ID/hash, not the filename.
Therefore:
Deleting a Duplicate or Failed source file after its final record is persisted MUST NOT remove or corrupt its database knowledge record.
The archive must remain useful even when terminal source files are cleaned from Drive.
6. THUMBNAIL GENERATION
All original thumbnail rules remain.
Maintain exactly 20 prebuilt template images.
Do not generate template artwork dynamically.
Choose based on content category with a sensible fallback/rotation.
Overlay:
thumbnail_main_title
thumbnail_subtitle
with safe wrapping/shrinking.
Track the process as a resumable stage.
A thumbnail failure must not recreate the Blogger draft.
A thumbnail failure must not call Gemini again.
7. BLOGGER ORDERING
The exact required ordering remains:
AI checkpoint
→ duplicate-text check
→ Blogger draft
→ draft notification
→ thumbnail
→ archive
→ done
The Blogger draft must exist BEFORE thumbnail generation.
A later thumbnail failure must never delete/recreate the already-created Blogger draft.
8. ERROR HANDLING
All original error semantics remain exactly.
HTTP 503:
transient
exponential backoff
jitter
maximum retry count
HTTP 429:
transient
honor server-specified retry delay when supplied
otherwise use controlled exponential backoff
never blindly retry rapidly
HTTP 400:
permanent for unchanged request
do not blindly retry
log complete response body
notify operator
diagnose payload/configuration
Other 5xx:
transient
Other 4xx such as 401/403/404:
permanent/configuration or authorization issue
distinguish clearly in logs
No infinite retries.
No silent failure.
No unhandled exception may kill the entire queue without recording the document state.
8.1 RETRY FILE NAMING
Whenever a document enters an active RETRY state and is moved to the retry-designated location, use:
R_<letter_number><short_meaningful_name>.ext
When it successfully resumes and becomes unique:
U_<letter_number><short_meaningful_name>.ext
When it becomes duplicate:
D_<letter_number><short_meaningful_name>.ext
When it permanently fails:
F_<letter_number><short_meaningful_name>.ext
The state field is authoritative; filename prefix is a human-visible status indicator.
9. EXECUTION LIMIT / RESUMABILITY
Assume Apps Script executions can terminate unexpectedly.
Never depend on in-memory state.
Persist state after every meaningful transition.
Use lightweight locking.
Exactly one document should be actively processed per worker execution unless the implementation can prove that processing more cannot violate quota/time constraints; the default implementation should remain conservative.
No overlapping executions may process the same document simultaneously.
10. SCHEDULED TRIGGER
Exactly ONE recurring main worker trigger may exist.
Recommended cadence:
15–30 minutes.
Setup must:
detect duplicate triggers,
remove stray copies,
leave exactly one intended worker trigger.
Running setup repeatedly must be idempotent.
11. OPERATOR CONTROL SURFACE
Provide a simple non-technical operator interface.
It should expose:
current status
worker state
queue count
last successful run
last error
paused/resumed state
manual run
self-audit
notification test
configuration status
retry status
The operator should not need to open the code editor for normal operation.
12. SELF-AUDIT
The self-audit MUST validate actual implementation, not merely function names.
It must check at minimum:
all CODE-ENFORCED title rules
all label charset rules
label count
label total-length budget
markdown cleanup
mandatory fields
duplicate logic
checkpoint existence
AI re-call prevention
retry classification
exact state-machine ordering
file naming rules
no unsafe hardcoded configuration
no duplicate function declarations
no generic hardcoded fallback headings
exactly one scheduled worker trigger
correct folder configuration
correct spreadsheet configuration
correct Blogger configuration
correct thumbnail dependency behavior
knowledge_extraction presence and schema validation
archive knowledge persistence
review status behavior
dataset split behavior
source hash persistence
source deletion safety
The self-audit must output explicit lines:
PASS —
or
FAIL —
12.1 CREATE-ONCE / REMOVE-TOOLS ARCHITECTURE
The system must be divided conceptually into:
A. RUNTIME CODE
B. ONE-TIME CREATION/PROVISIONING TOOLING
The one-time provisioning layer must create:
folders
sheets
tabs
headers
schemas
configuration keys/placeholders
required trigger
required initial structures
The creation routine MUST be idempotent.
Running it twice must not:
duplicate folders,
duplicate sheets,
duplicate headers,
duplicate triggers,
destroy existing data.
12.2 CLEAN CREATE FUNCTION
Use a clearly isolated file such as:
CREATE_ONCE.gs
It may contain:
createSystemOnce()
and other strictly provisioning-related helpers.
After successful deployment and audit, provide a safe cleanup/removal operation such as:
removeCreateTools()
Its purpose is to remove the one-time provisioning code from the deployed runtime project after the operator confirms setup.
IMPORTANT:
Do not allow removal until:
setup succeeded,
schema exists,
self-audit passed,
trigger exists correctly,
required configuration is present.
The removal operation must not delete operational runtime functions, stored data, archive data, checkpoints, or configuration.
It is a source-code cleanup feature, not a data deletion feature.
After removal, the runtime project must remain fully operational.
12.3 FUTURE RESTORABILITY
Even though the Create tools may be removed from the production runtime project, the original provisioning source must be delivered separately as an administrator/deployment artifact.
Never make the system impossible to recreate merely because the one-time code was removed from production.
13. CONFIGURATION
No environment-specific secret or ID may be hardcoded.
Configuration must be stored in a script-level configuration store.
Examples include:
GEMINI_API_KEY
Gemini model
notification email
source folder
unique folder
duplicate folder
failed folder
retry folder
thumbnail folder
template folder
spreadsheet ID
Blogger blog ID
checkpoint folder
duplicate threshold
retry limits
schedule
similarity parameters
The exact set may be expanded where necessary.
Every required configuration item must have:
name
purpose
required/optional status
default behavior if omitted
validation rule
Missing required configuration must fail loudly with the exact missing key name.
14. NO HARDCODED USER-SPECIFIC VALUES
Never hardcode:
personal email
API key
folder ID
spreadsheet ID
Blogger ID
user-specific account value
inside source code.
15. TESTING
Provide on-demand tests for:
full one-document dry run
notification test
unreadable date/reference
no-FAQ document
large table
long document
exact duplicate
corrected-text duplicate
503 simulation
429 simulation
400 simulation
retry resume
AI checkpoint resume
thumbnail failure resume
archive failure resume
duplicate/failed file deletion safety
filename collision
invalid AI schema
markdown leakage
invalid title characters
invalid labels
Future-AI knowledge schema validation
dataset review status
self-audit
16. FUTURE-AI DATASET DESIGN PRINCIPLES
The archive must be designed so that a future AI can consume it without requiring the Blogger article as the sole source of truth.
Priority order for future AI:
corrected_text
structured facts
entities
conditions
dates/deadlines
eligibility
procedures
tables
grounded Q&A
metadata
search_text
publishing output
The Blogger article is a presentation layer, not the canonical knowledge source.
Do not train future knowledge systems primarily from rewritten prose when the corrected source and structured facts are available.
16.1 VERSIONING
Every AI knowledge record should carry:
knowledge_schema_version
prompt_version
model
model_version when available
processing_timestamp
source_hash
A future change in schema must not silently overwrite the meaning of older records.
16.2 REPROCESSING SAFETY
If the system is later upgraded:
Do not automatically re-call Gemini for every historical document.
A historical document with a valid checkpoint should be reusable.
A reprocessing function, when provided, must be explicitly controlled.
Never silently overwrite a verified knowledge record with an inferior result.
17. DATA QUALITY PRINCIPLES
Preserve the distinction between:
SOURCE
→ OCR / extraction
→ CORRECTED TEXT
→ STRUCTURED KNOWLEDGE
→ PUBLISHING CONTENT
Do not treat AI-generated interpretation as equivalent to raw source evidence.
Never discard corrected_text because article_html already exists.
Never discard machine-readable facts merely because the Blogger article contains them in prose.
18. OUTPUT CONTRACT OF THE AI
The AI must return exactly one structured response.
The response must contain:
A. Original publishing fields
B. Original attribution/metadata fields
C. Optional reserved fields
D. NEW knowledge_extraction object
The AI must NOT return multiple competing answers.
The AI must not return commentary outside the structured response.
The AI must not return markdown wrappers around JSON.
19. AI PROMPTING PRINCIPLE
The prompt sent to Gemini must explicitly state:
source document is the sole factual authority,
never invent,
never omit,
preserve numbers/dates/names,
distinguish illegible from known,
no markdown leakage,
obey all exact title constraints,
obey all exact label constraints,
preserve tables,
produce complete corrected_text,
generate publishing fields,
generate structured knowledge fields,
keep knowledge grounded in source text,
do not convert uncertainty into certainty.
The model must know that code will independently enforce hard constraints.
20. ARCHIVE RECORD RELATIONSHIPS
Every record should allow tracing:
SOURCE FILE
→ DOCUMENT ID
→ SHA-256
→ AI CHECKPOINT
→ CORRECTED TEXT
→ KNOWLEDGE EXTRACTION
→ DUPLICATE DECISION
→ BLOGGER POST
→ THUMBNAIL
→ ARCHIVE RECORD
→ FINAL STATE
This makes the entire system auditable.
21. CLEANUP POLICY
Duplicate and Failed folders may be cleaned manually without destroying operational history.
The system must not require those physical files to remain forever.
However:
Do NOT automatically delete source documents unless an explicit cleanup policy is configured.
Do not delete checkpoints merely because the Blogger post exists.
Do not delete knowledge records merely because source files were deleted.
Do not delete audit history merely because files were cleaned.
22. SECURITY
Never log:
API keys
tokens
OAuth secrets
credentials
Logs may include:
document ID
filename
hash
state
timestamp
endpoint/status code
sanitized error
retry count
Complete external error response bodies may be stored where required for diagnostics, but secrets must be redacted.
23. DEFINITION OF DONE
The build is complete only when:
every original Section 3 rule is enforced,
every original numeric/character constraint remains intact,
state transitions are resumable,
AI checkpoint prevents redundant Gemini calls,
exact and corrected-text duplicate detection work,
Blogger draft is created before thumbnail,
thumbnail failure never causes AI reprocessing,
duplicate/failed file deletion is safe,
U_/D_/F_/R_ naming works,
future-AI knowledge extraction is persisted,
knowledge archive is separate from publishing data,
source-grounded structured facts are retained,
tables remain machine-readable,
review status is supported,
dataset split is supported,
self-audit verifies implementation,
one trigger exists,
no secrets are hardcoded,
provisioning is idempotent,
one-time creation tools can be removed after deployment,
removal does not damage runtime,
provisioning source remains separately recoverable,
notification testing works,
dry-run testing works,
400/429/503 behavior is verified,
restart/resume behavior is verified,
duplicate/failed deletion safety is verified,
invalid AI output is rejected,
markdown leakage is eliminated,
a clean test document creates a valid Blogger draft,
knowledge archive is generated from the same validated AI checkpoint,
no human cleanup is required for a successful test document.
24. FINAL IMPLEMENTATION RULE
Do not build the simplest system.
Build the most reliable system that satisfies the complete specification.
Do not remove functionality merely to make the code shorter.
When code size must be reduced, reduce duplication and unnecessary abstractions — never remove a required safety mechanism.
Do not create hidden dependencies.
Do not rely on in-memory state.
Do not rely on the physical existence of Duplicate/Failed files for historical correctness.
Do not make Gemini calls that the persisted checkpoint makes unnecessary.
Do not create competing sources of truth.
CANONICAL PRINCIPLE:
The government source document is the factual source.
corrected_text is the canonical textual representation.
knowledge_extraction is the canonical machine-readable knowledge representation.
Blogger content is the reader-facing presentation layer.
The persisted state/checkpoint is the canonical processing recovery layer.
All layers must remain traceable to the source.
25. IMPORTANT CHANGE-CONTROL RULE
Before modifying any original requirement from the original specification:
STOP.
Do not implement the modification.
Present:
OLD RULE:
PROPOSED CHANGE:
REASON:
IMPACT:
Then request explicit operator approval.
Until approval:
PRESERVE THE ORIGINAL RULE EXACTLY.