Ghid operator pentru Documents

Ce face

Documents este capabilitatea pentru creare, editare, redline și comentarii pe artefacte .docx, Word și documente care trebuie să ajungă în Google Docs. Nu se bazează pe „pare bine în text”. Contractul corect este: construiește sau modifică documentul, îl randează în imagini de pagină, inspectează layout-ul vizual, repară defectele, randează din nou și livrează doar livrabilul final cerut.

Motivul este simplu și neplăcut: un DOCX poate avea text corect și XML valid, dar pagini proaste. Tabelele pot fi prea late, textul poate fi tăiat, glyph-urile pot lipsi, listele pot fi false, spacing-ul poate deriva, iar header-ul sau footer-ul pot intra peste conținut. De aceea verificarea reală înseamnă randare în PNG-uri de pagină și inspecție vizuală.

Pentru documente noi sau rescrieri majore, skill-ul folosește un preset de design rezolvat în valori explicite: pagină, margini, fonturi, ierarhie, liste, tabele, callouts, header/footer și culori. Pentru documente existente, regula se inversează: păstrează documentul și aplică editările locale minime cerute.

All guides

Când îmi folosește

Folosește Documents când ai nevoie de un document care trebuie să fie corect și vizual livrabil, nu doar un text pus într-un fișier:

• memo-uri, brief-uri, decizii, RFI responses sau documente board-style;
• ghiduri de lansare, checklist-uri și reference guides dense;
• proposals, grant-uri sau texte persuasive lungi;
• documente Word existente care trebuie editate determinist;
• redline-uri, comentarii sau modificări precise pe .docx;
• documente care vor fi importate ca Google Docs native;
• documente noi care trebuie să urmeze un template atașat sau reținut.

Dacă un template controlează documentul nou, template-ul devine autoritatea de design. Nu se aplică peste el un preset generic decât dacă ceri explicit abaterea.

Cum îl invoc / declanșez

Îl declanșezi cerând explicit o operațiune pe .docx, Word sau un document destinat Google Docs: creare, editare, rescriere, redline, comentarii, conversie în livrabil Word/Google Docs sau refacere după template.

Pentru un Google Docs net-new, fluxul standard este: se creează local un .docx, se verifică vizual, apoi se importă prin acțiunea Google Drive pentru documente native:

mcp__codex_apps__google_drive_import_document

cu:

upload_mode: "native_google_docs"

Înainte de randare sau import pentru orice DOCX destinat Google Docs, trebuie rulat sanitizer-ul de titlu:

python scripts/google_docs_title_sanitize.py input.docx --out sanitized.docx

apoi:

python scripts/google_docs_title_sanitize.py sanitized.docx --check

DOCX-ul sanitizat este cel folosit pentru render QA și import. Asta previne reziduuri Word de tip Title, borduri sau linii decorative care pot supraviețui în Google Docs. Dacă pluginul Google Drive nu este disponibil, trebuie cerută instalarea lui. Dacă pluginul există, dar acțiunea de import lipsește, trebuie cerut refresh/reinstall înainte de livrarea nativă Google Docs.

Exemplu practic

Cerere tipică: „Creează un brief formal de două pagini în .docx.”

Fluxul sănătos: se alege un preset potrivit, de exemplu standard_business_brief, se transformă presetul în token-uri exacte, se construiește documentul cu stiluri Word reale, liste reale și tabele cu geometrie explicită. Apoi se randează paginile în PNG-uri, se inspectează la 100% zoom și se repară orice defect: tabel prea lat, heading cu spacing greșit, listă falsă, footer intruziv, text tăiat. După reparare, se randează din nou. Nu se ghicește. Ghicitul produce documente cu cadavre sub covor.

Pentru Google Docs net-new, presetul implicit este google_docs_default: Arial, ierarhie neagră, titlu simplu. Titlul nu se creează cu stilul built-in Word Title; se creează paragraf normal și se aplică direct token-urile de stil.

Output / unde aterizează

Output-ul normal este livrabilul cerut: de obicei .docx, sau document nativ Google Docs dacă pluginul și acțiunea de import sunt disponibile. PNG-urile de pagină și PDF-ul opțional sunt artefacte interne de QA. Nu se livrează decât dacă le ceri explicit.

Răspunsul final trebuie să vorbească despre documentul rezultat, nu să expună mecanica internă sau fișierele intermediare. Dacă visual QA a fost finalizată, se poate spune că documentul a trecut randarea și inspecția vizuală. Dacă nu a fost posibilă, trebuie spus clar.

Limite / gotchas

Dacă LibreOffice sau soffice lipsește, documentul poate fi returnat fără QA vizual prin PNG, dar răspunsul trebuie să spună explicit că render/visual QA nu a putut fi completat. Nu se pretinde că a trecut gate-ul vizual. Dacă randarea eșuează din alt motiv, problema de randare trebuie reparată, nu ignorată.

Pentru Google Docs net-new, nu se folosesc Browser Use, Computer Use, creare de Google Doc gol plus API de scriere sau alte construcții directe, decât dacă ceri explicit un flux alternativ. Chiar și atunci, trebuie semnalat întâi că cea mai bună calitate este așteptată prin DOCX local verificat și import Google Drive nativ.

Nu se folosesc runtime-uri, pachete globale sau instalări improvizate când contractul cere dependențele workspace-ului. Builder-ele se rulează dintr-un loc scriibil, nu din directorul gestionat al dependențelor.