Files and images

Use the attachment button in a composer to add supported reference material.

An attachment is context, not a complete instruction. Mango9 still needs to know why the file matters, what outcome you want, and which parts of the current app should remain. A one-sentence explanation beside the file often prevents the biggest misunderstandings.

Use the smallest relevant reference. A close screenshot of a broken footer is clearer than a full-page image when the rest of the page is correct. A short requirements document for the current workflow is more useful than a folder containing every future idea.

Example: “This screenshot shows the mobile checkout overlap. Fix only the covered Pay button; the desktop checkout and all payment behavior are already correct.”

Images

Images can communicate:

• a visual style or layout reference;
• the exact area where a defect appears;
• a logo or asset you have permission to use;
• content that should appear in the app;
• desktop and mobile differences.

Say what the image means. “Copy this” is ambiguous; “use its compact card hierarchy but preserve our colors and wording” is actionable.

Choose the image for the job. A defect screenshot proves what you saw. A design reference communicates visual direction. A logo is an asset that should be used faithfully. A photo may be content that belongs in the page. Calling out that role tells Mango9 how strongly it should influence the result.

When the image shows an existing app problem, include the page, device, and action that produced it. If only one region matters, say so. Mango9 can then focus its inspection and visual proof on the affected area instead of treating the whole screen as a redesign request.

Example: “On /pricing at iPhone width, the annual-price note is cut off under the card. The red rectangle marks the affected line. Keep all prices, card order, and desktop layout unchanged.”

Example: “Use this restaurant photo as the hero image. Crop it so the table remains visible on desktop and mobile, and keep the existing headline readable over it.”

Documents

Supported PDF and Word documents can provide requirements, copy, workflow details, or structured source material. State whether the document is authoritative or background context.

For a long requirements document, ask for one coherent implementation slice instead of expecting every future idea to ship in the first build.

Tell Mango9 whether the document contains approved facts, suggested ideas, or historical background. You can make one section authoritative and explicitly leave another for later. This is especially useful when a business document mixes current policies with long-term plans.

Before attaching sensitive business material, remove personal information that is not needed for the feature. If the document contains keys, passwords, connection strings, or private customer records, create a safe copy without them.

Example: “Pages 2–4 contain the approved intake questions and must be followed. The reporting wish list on page 8 is future context only and should not be built now.”

Generated images

When a build calls for original visual assets, describe the subject, format, placement, and tone. Generated assets and visual-verification screenshots serve different purposes:

• Generated assets become part of the project.
• Visual proof records what the running app looked like after work.

A screenshot shown in a completion card is not automatically a project asset.

Describe generated-image needs the same way you would brief a designer: subject, mood, composition, aspect, and intended placement. Mention text-free output when copy will be layered in the app. If the project needs several related images, explain the shared visual system and the distinct subject for each one.

Visual proof has a different responsibility. It captures the rendered app so you can confirm a change. It should not be copied into the project, displayed as content, or confused with an original image generated for the page.

Example: “Generate three text-free, wide illustrations of a neighborhood bakery: storefront, bread preparation, and morning counter service. Use one warm editorial style across all three.”

Privacy and rights

• Upload only material you are allowed to use.
• Remove unnecessary personal or confidential information.
• Store credentials under Environment Variables, never in an attachment.
• Do not assume an image license transfers just because it is visible online.

Treat every attachment as something that may become part of a working product conversation. Crop unrelated people, account details, browser tabs, and notifications before uploading. Use a test record instead of a real customer's record whenever it demonstrates the same issue.

If you are using a reference for inspiration rather than republication, say that clearly. Mango9 can borrow general hierarchy or mood without copying another company's brand, wording, proprietary illustration, or customer data.

Example: “This competitor screenshot is only a spacing reference. Do not use its logo, colors, copy, photographs, or product names.”

Attach the screenshot in the same request that explains the problem. Name the route, device size, and expected result so the visual reference is not interpreted in isolation.