DOCINT-1837: Document uploader_tool_name and fix upload status values

[yoasyo25]

Jira

DOCINT-1837

Type of Change

• Docs

Summary

Updates the Unified File Uploads tutorial to document the new uploader_tool_name field and to correct the upload status table, which was missing statuses that already shipped in the FUS API (scanning, failed) and listed a stale value (complete) as a GET-returned status.

Motivation

The Unified File Uploads tutorial is being made publicly available and the tutorial should reflect upcoming/recently-shipped contract details: the new uploader_tool_name field, and the real status vocabulary already returned by the GET status endpoint (malware-scan states were shipped but not yet fully documented).

Changes

uploader_tool_name field

• Added "uploader_tool_name": "document_management" to all POST /uploads request/response examples (project-level single-part, project-level multi-part, company-level) and to the GET status response examples.
• Added a plain-prose note explaining the field: optional today, 64-character limit, expected to become required in a future release.
• Added a "Coming Soon" bullet noting the field will move from optional to required.

Upload status accuracy

• Fixed the "Key New Feature Highlights" status list: was ready, receiving, complete, available, now ready, receiving, scanning, available, failed (matches the FUS UploadGetResponse schema's allowableValues).
• Fixed the status table: added the previously undocumented scanning and failed statuses, clarified that complete is a PATCH-response-only value that the GET endpoint always resolves into one of the other statuses.
• Added a documented error object example ({type: "scan_failure", message: ...}) returned when a failed status is due to a malware-scan rejection.
• Added a note to "Important Considerations" explaining the scanning → available/failed lifecycle, including the case where scanning is not enabled (straight receiving → available).
• Updated the "Coming Soon" section to reflect that malware scanning already exists but isn't yet applied to all uploads, and added two new forward-looking items: file-extension allow-list and content-type validation.

Validation

• Content verified against file-upload-service (FUS) main — api_docs/open-api.json, UploadStatusMapper.java, UploadGetResponse.java, CreateUploadRequest.java, UploadStatus/MalwareScanStatus enums
• Cross-referenced Jira DOCINT-1837 (this ticket) and PPC2-9064 (FUS analytics epic) for product intent
• Rendered locally via Jekyll (bundle exec jekyll serve)

Testing Instructions

1. Check out this branch and run bundle exec jekyll serve in the documentation repo.
2. Visit http://127.0.0.1:4000/documentation/tutorial-unified-file-uploads.
3. Confirm the new uploader_tool_name field appears in all request/response code samples and the status table renders correctly with the scanning/failed rows and the new error object example.

Additional Context

Known, deliberate discrepancy (not a bug): PPC2-9064 (FUS analytics epic, in progress) states as an acceptance criterion that uploader_tool_name is additive-only and will never become required. This tutorial's "will become required in a future release" wording and matching "Coming Soon" bullet knowingly diverge from that epic's current text, per an explicit product-messaging decision made in Slack. Flagging here so reviewers aren't surprised if they cross-reference the epic.

---

[yoasyo25]

@ajaykumarprocore can you confirm that this will become required in the future?

[ajaykumarprocore]

Yes - this will become required in the future - the wording is accurate. Thank you!!