From 5dec221a68b650a6f2b8aa05510257d8335071f0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Andr=C3=A9=20Padez?= <andre.padez@gmail.com>
Date: Mon, 24 Aug 2026 02:55:00 +0000
Subject: [PATCH] file viewer: hide the transcribe button
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

It calls POST /file-browser/transcribe, which refuses on every server here — no
STT endpoint is configured anywhere, so it is a control that can only fail. One
of those teaches people to distrust the controls beside it, and OCR and extract
audio sit right there.

Hidden rather than deleted. Speech-to-text is leaving the platform for a plugin,
and the wiring is the useful part: the handler, the loading state and the
sibling-markdown behaviour in FileViewerProvider are all still correct, so when
the plugin exists this becomes a call to it rather than a rediscovery.

It may not come back here at all — the other route to the same job is the file
browser's context menu, which a plugin reaches with a task, and that needs no
button in this header. The comment says so, so whoever finds `false &&` knows it
is a decision rather than debugging left behind.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Officer-Session: 656f5c85-e49a-4f1f-b9f3-042a04b4d043
---
 .../src/apps/FileViewer/FileViewerHeader.tsx    | 17 ++++++++++++++++-
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/src/workspaces/officerdev/src/apps/FileViewer/FileViewerHeader.tsx b/src/workspaces/officerdev/src/apps/FileViewer/FileViewerHeader.tsx
index bc1e28f3..2de7c55d 100644
--- a/src/workspaces/officerdev/src/apps/FileViewer/FileViewerHeader.tsx
+++ b/src/workspaces/officerdev/src/apps/FileViewer/FileViewerHeader.tsx
@@ -98,7 +98,22 @@ export const FileViewerHeader = () => {
           {ocrLoading ? <Loader2 className="h-3.5 w-3.5 animate-spin" /> : <ScanText className="h-3.5 w-3.5" />}
         </button>
       )}
-      {fileType === 'audio' && (
+      {/*
+        TRANSCRIBE — hidden, not deleted, and the distinction is deliberate.
+
+        Speech-to-text is leaving the platform for a plugin of its own. Until that lands this button calls
+        `POST /file-browser/transcribe`, which refuses on every server here because no STT endpoint is
+        configured anywhere — so it is a control that can only fail, and one of those teaches people to
+        distrust the controls beside it.
+
+        Kept because the wiring is the useful part. When the plugin exists this becomes a call to it, and
+        the handler, the loading state and the sibling-markdown behaviour in FileViewerProvider are all
+        still correct; deleting would mean rediscovering them.
+
+        It may not come back here at all. The other route to the same job is the file browser's context
+        menu, which a plugin reaches with a task — and that path needs no button in this header.
+      */}
+      {false && fileType === 'audio' && (
         <button
           onClick={handleTranscribe}
           disabled={transcribeLoading}