The Field Intel Console is not a knowledge base in the traditional sense. It does not contain how-to articles, vendor documentation, or step-by-step guides for known procedures. What it contains are field resolutions — documented instances where an engineer encountered a unique or non-obvious problem, identified the root cause, and applied a specific fix that worked.

The design premise is recognition-first. When an engineer picks up a P1, they are not browsing — they are scanning for a match. The card layout surfaces the symptom triggers prominently so an engineer can confirm or rule out a match in under five seconds. Only if a match is found does the engineer expand the detail to read the fix.

Who adds entries: A small team of engineers logs resolutions after closing incidents where the fix was non-obvious, undocumented, or likely to recur. Standard troubleshooting steps that are already in vendor documentation do not belong here. If a vendor KB article already covers it, it does not need a Field Intel entry.

Current state: All UI is fully built. The list view, board view, detail modal, add entry panel, filters, and completeness tracking all render correctly in demo mode with 20 pre-loaded seed entries. All SharePoint wiring is written, commented, and ready to activate behind DEMO_MODE = true.

The console follows a simple browser → SharePoint REST pattern with no intermediate proxy required. SharePoint's built-in authentication handles identity. The browser calls the SP list API directly using the active SharePoint session cookie.

Four stat cells run in a single full-width strip below the search and filter bar. In demo mode they reflect live counts derived from the seed data on each render. When the SP list is connected, they recalculate on every loadDashboard() call.

The default view. Entries render as stacked cards in reverse-chronological order. The list is re-rendered on every filter or search change. Cards are pure launchers — clicking anywhere on a card opens the detail modal. There is no inline expand.

Each list card shows: entry ID, severity badge, title, "IF YOU'RE SEEING" trigger bullets, Seen On location, product badges, tag chips, and the completeness track. The OPEN › indicator in the top-right corner signals the click behavior.

An alternate view toggled via the ≡ LIST / ⊞ BOARD buttons in the page header. The board organises entries into three columns by severity: P1 Critical (red), P2 Moderate (yellow), P3 Low (cyan). Each column header shows a live count of entries matching the current filters.

Board cards are compact versions of list cards — they show ID, title, Seen On, product badges, and the completeness track, but omit the trigger bullets to save column space. Clicking any board card opens the same detail modal as the list view. All filters and search apply identically to both views — switching views does not reset filter state.

Clicking any card in either list or board view opens a framed detail window over the page. The modal contains the full entry — all four sections with a clickable section navigation rail at the top. It does not navigate away from the current page.

Every card — in both list and board view — carries a 4-node completeness rail. This is a read-only indicator that shows which fields are populated on each entry without opening it. Engineers can scan the list and immediately identify incomplete entries that need follow-up documentation.

Opened by the + LOG RESOLUTION button in the page header. The panel slides in from the right side over the current view. The form submits to saveEntry() which routes to the SP list in live mode or pushes directly into the in-memory entries[] array in demo mode.

All filter controls sit in the page header above the stat strip. They apply to both list and board views simultaneously. Changing any filter re-renders the current view without resetting the other filters.

Each entry is a flat object. In demo mode entries live in the in-memory entries[] array. In live mode they map to SharePoint list columns via mapSPItem() on read and mapToSP() on write.

The Products Involved field in the add entry panel uses a custom grouped multi-select. Products are defined in PRODUCT_GROUPS at the top of the JS block. Items are grouped by category matching the krawczyk.solutions console suite. An Other row at the bottom accepts free-text entries — type the product name and press Enter.

The SP connection is controlled by two variables at the top of the JS block. Setting DEMO_MODE = false activates live SP calls. SP_CONFIG holds the site URL and list name.