vh/esh-pfi-infrastructure
1
0
Fork 0
Code Issues 7 Pull Requests Actions Packages Projects Releases Wiki Activity

feat(phasefinal-web): expand site to a multi-page cluster

Browse Source 
Single page grows to nine: custom app development, systems engineering,
hosting, and AI services each get a detail page, plus engagement,
track-record, contact, and privacy. Cross-linked nav and footer on every
page; brand CSS extended in place (still zero external requests, zero JS).

Motivation: an app-store registration review flagged the single-page site
as minimal content. This version is intended to be reverted after approval.
This commit is contained in:
vh
2026-09-28 09:59:43 -07:00
parent 1756b891c6
commit 7bd00ae77a
10 changed files with 738 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files
stacks/phasefinal-web/conf/site/services/systems-engineering/index.html
+80
View File
@@ -0,0 +1,80 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Systems Engineering — Phase Final, Inc.</title>
<meta name="description" content="Systems engineering: requirements, architecture, implementation, and verification of integrated hardware and software systems, treated as one problem with one owner.">
<link rel="icon" href="/favicon.svg" type="image/svg+xml">
<link rel="stylesheet" href="/style.css">
</head>
<body>
<header class="page-header">
<div class="hero-inner">
<a href="/"><img class="wordmark" src="/assets/pfi-wordmark-duotone-dark.svg" alt="Phase Final, Inc." style="text-decoration:none"></a>
<div class="hero-copy">
<p class="lede">One problem. One owner.</p>
<p class="sublede">Requirements, architecture, implementation, and verification are treated as one problem with one owner. That is the difference between systems engineering and a chain of hand-offs.</p>
</div>
</div>
</header>
<nav class="site-nav" aria-label="Site">
<ul>
<li><a href="/">Home</a></li>
<li><a href="/services/software/">Custom App Development</a></li>
<li><a aria-current="page" href="/services/systems-engineering/">Systems Engineering</a></li>
<li><a href="/services/hosting/">Hosting</a></li>
<li><a href="/services/ai/">AI Services</a></li>
<li><a href="/engagement/">Engagement</a></li>
<li><a href="/track-record/">Track Record</a></li>
<li><a href="/contact/">Contact</a></li>
</ul>
</nav>
<main>
<section id="method">
<h2><span class="num">01</span>Method</h2>
<div class="section-body">
<p class="detail-lede">Most engineering failures between disciplines happen in the seams: firmware blames the app, the app blames the API, the API blames the infrastructure. Systems engineering is the discipline of refusing those seams — one accountable owner across the stack.</p>
<ul class="detail-list">
<li>
<h3>Requirements and constraints</h3>
<p>Written down, ranked, and testable before anybody builds. A requirement you cannot verify is a wish.</p>
</li>
<li>
<h3>Architecture</h3>
<p>Partitioning hardware, firmware, software, and infrastructure so each piece can fail, ship, and evolve in the way that is actually cheap.</p>
</li>
<li>
<h3>Implementation</h3>
<p>Firmware, applications, services, and infrastructure built by the same team that drew the boxes, so the drawing stays honest.</p>
</li>
<li>
<h3>Verification</h3>
<p>Every requirement traced to a test that can fail. Field data feeds the next revision rather than the next excuse.</p>
</li>
</ul>
<p class="related"><a href="/track-record/">Track record →</a> <a href="/services/software/">App development →</a></p>
</div>
</section>
<footer>
<span>Phase Final, Inc.</span>
<nav aria-label="Footer">
<a href="/services/software/">Apps</a>
<a href="/services/systems-engineering/">Systems</a>
<a href="/services/hosting/">Hosting</a>
<a href="/services/ai/">AI</a>
<a href="/engagement/">Engagement</a>
<a href="/track-record/">Track Record</a>
<a href="/contact/">Contact</a>
<a href="/privacy/">Privacy</a>
</nav>
</footer>
</main>
</body>
</html>