{{-- Project Details — docs/wireframes-v12/view-project.html, rebuilt on the wireframe's own markup (CR-2b, spec §12). v12's layout, top to bottom: 1. a header row: the three status pills on the left, Edit Project and Download Brochure on the right, both `.btn.btn-outline`; 2. a card carrying the two-tab strip, Project Details | Unit Inventory; 3. the Details panel — Project Overview + Location side by side as `.detail-grid` label/value pairs, the four unit tiles, the tower summary, and a Recent Activity timeline; 4. the Inventory panel — one card, one `.data-table` of units. The project's name and code are NOT in the content: v12 puts them in the page title ("Navratna Gulmohar Park - PRJ-009"), which is where they are here too. That is where the old `@section('subtitle')` line went — it said the project's name, and the title says it now. ## What this screen has that v12 does not Three cards, all of them showing fields the project FORM collects and that v12's detail panels stop short of: Structure Details, Compliance & Legal and Marketing & Media. A detail screen that cannot show what its own form captures sends the reader to the edit page to read. They are titled with the form's own section names and drawn in the same `.detail-grid` language, so the two screens are read in the same order. The wireframe's "Tower Wise Summary" — four static tower cards with a sold bar — used to be a wings section here, reading and managing the project's wings and their floor plans. CR-5 §15.1 removed it with the tables behind it; the Structure Details card's "Towers" row is what is left, and it reads the project's own `towers_count` field rather than a live count. The wireframe's "Recent Activity" timeline is not carried over at all: the activity log it would read is per-model and gets its own screen. The Inventory tab's table carries three columns — Unit No., Carpet Area, Status — and no row actions. That is the whole of a unit since CR-5 §15.1: it is not editable anywhere, and the wing/floor/type/price columns it used to carry are gone with the modules that maintained them. `parking_slots` and `configurations` are deliberately absent. v12 has no field for either; the columns stay in the database (spec §3) and no screen reads them. ## RERA number v12 shows it twice — as a header pill and as the last row of the Location card — because it has nowhere else to put it. Here it is the header pill and a row of Compliance & Legal, which is where the rest of the RERA paperwork (valid-until, NA permission, certificates) already lives. One value, one detail row. --}} @extends('layouts.app') @section('title', __('projects.show_title_for', ['name' => $project->name, 'code' => $project->code])) @section('breadcrumbs') @endsection @section('content') @php // Rendered as a dash rather than an empty cell, so an unanswered row // still reads as a row. projects has no not-recorded key of its own — // the character is the whole string. $blank = '—'; $brochureSlot = \App\Enums\ProjectFileSlot::Brochure; @endphp
{{-- One pill holding the comma-joined labels since CR-5 §15.2.3, for the same reason the listing's cell is one pill: v12 draws a single badge here and a multi-typed project must not turn the header strip into a second row of chips. --}} {{ $project->typeLabels() }} @if (filled($project->rera_no)) {{ $project->rera_no }} @endif
{{-- v12 puts Download Brochure beside Edit Project, both as outline buttons and in that order. It is not behind the same gate: editing needs the update policy, and downloading is a read, gated by ProjectPolicy@view like this page — so a sales user who cannot edit still gets the file. It renders only when the slot holds something. --}}
@can('update', $project) {{ __('projects.actions.edit_project') }} @endcan @if (filled($project->{$brochureSlot->pathColumn()})) {{ __('projects.actions.download_brochure') }} @endif
{{-- v12's two-tab strip, in a card of its own with no bottom margin so the panel below reads as attached to it. The tabs are real links to the panels they reveal, not buttons with an inline onclick the way v12 writes them: nrems-tabs.js (pushed below) upgrades them in place, and with no Javascript at all both panels simply render one under the other — every unit and every detail still on the page, which is the right way for a read-only screen to fail. Avoiding the inline handler is a step toward the planned strict CSP, not arrival at it: this screen still emits `@push('scripts')` inline ` @endpush