Identificação do trabalho
- Unidade Curricular
- Laboratórios de Scrum e Roadmap para a Transformação Digital (2025/2026)
- Destinatários
- Prof. João Almeida (regente), Prof. Carlos Alves, Prof. Samuel Anjos
- Aluno
- Gabriel Lima
- Grupo original
- Grupo de oito elementos (cf. §3.3)
- Cliente do projecto
- LIACC — Laboratório de Inteligência Artificial e Ciência de Computadores (Universidade do Porto)
- Natureza do documento
- Memória descritiva do percurso, artefactos e entrega MVP
Enquadramento e escolha do cliente
O LIACC foi apresentado em sala de aula como sugestão de cliente. O grupo aceitou a proposta, reconhecendo o interesse pedagógico do caso: uma unidade de investigação com um footprint digital desactualizado, utilizador-alvo com exigências diversas (investigadores, estudantes, indústria, comunidade internacional), e um portfólio de projectos e publicações com elevado potencial de reorganização informacional.
O objectivo de negócio foi formulado como sendo o de entregar um website institucional que funcionasse como montra credível, com navegação clara, ligação cruzada entre entidades (investigadores, projectos, publicações, áreas, linhas temáticas, pólos), SEO optimizado, e uma camada comercial leve (loja institucional). Tendo em conta a dimensão do LIACC e o período de avaliação da UC, foi definida uma fronteira conservadora: MVP navegável e defensável, sem deslocalização da marca oficial.
Metodologia de trabalho — Scrum híbrido
3.1. Modelo adoptado
O modelo de trabalho adoptado foi Scrum com gestão híbrida: Scrum na fase de planeamento (Product Vision, Product Backlog priorizado, Sprint Goals, Definition of Done) e Kanban na fase de execução (fluxo contínuo de tarefas em Not started → In progress → Done, sem cerimónias diárias dado o contexto).
3.2. Artefactos Scrum produzidos
- Product Vision Statement — documento de enquadramento do cliente no hub Notion.
- Product Backlog — base de dados Notion com 8 epics (E1 Analysis & Research, E2 Information Architecture, E3 Design & Identity, E4 WordPress Setup, E5 Content Migration, E6 Shop / E-Commerce, E7 Performance & SEO, E8 QA & Launch), cada ticket com prioridade (P1–P4), story points e sprint de afectação.
- Sprint Backlog mantido como view filtrada do Product Backlog.
- Definition of Done — feature funcional em desktop e mobile; cross-links verificados; Lighthouse > 80; revisão por pelo menos um elemento; deploy em staging.
- RACI pré-definido para os papéis PO, SM, Frontend e Backend.
3.3. Trabalho individual — reconhecimento
3.4. Cadência
A cadência formal de seis sprints planeada no Notion foi comprimida num ciclo contínuo de execução Kanban, mantendo a Sprint Goal de cada ciclo como objectivo semanal. Todos os tickets do backlog priorizado foram concluídos, incluindo os relativos à camada WordPress, que foi efectivamente construída e publicada (ver §9).
Decisões técnicas e escolha da stack
4.1. Postura adoptada
A abordagem adoptada foi a de empresa de consultoria especializada em desenvolvimento web. Nessa qualidade, entendeu-se que a escolha de processo de construção é uma decisão técnica de responsabilidade do prestador: o cliente especifica objectivos de negócio (montra credível, cross-linking, SEO, camada comercial leve), enquanto a equipa técnica selecciona a forma mais segura e auditável de os entregar.
O percurso técnico teve duas fases. Numa fase inicial explorou-se brevemente uma stack Next.js; optou-se depois por modelar todo o conteúdo e a interface num gerador estático em Python sem dependências, usado como protótipo de alta fidelidade e fonte única de verdade (single source of truth) do modelo de conteúdo. Sobre essa base, a entrega final foi migrada e publicada em WordPress, conforme indicado na brief, ficando o site institucional vivo em liacc.gablima.com. O gerador em Python permaneceu como documentação executável e referência de design.
4.2. Stack entregue (WordPress, em produção)
liacc — vivo em liacc.gablima.comperson, project, news_item, education e unit, com taxonomias research_area e thematic_line e campos Advanced Custom Fields (ACF)the_content, editável em wp-admin; listagens dinâmicas por shortcodesdata-i18n para a interface; comutador de idioma + hreflangwp_option, nunca no cliente); formulários ligados com opt-in único e registo de prova de consentimento RGPDProtótipo / SSOT. O gerador estático em Python 3 (biblioteca padrão, zero dependências, build.py → dist/), com tokens de design em custom properties (static/assets/liacc.css) e conteúdo em dicionários Python (site_gen/data.py), continua a servir de fonte única de verdade do modelo de conteúdo e deste relatório navegável.
4.3. Justificação da abordagem
- Fidelidade. Modelar primeiro num gerador determinístico permitiu congelar a arquitectura de informação e o sistema de design antes da migração, reduzindo retrabalho no CMS.
- SEO. O conteúdo é servido em HTML indexável por motores tradicionais e por retrievers de LLM; em WordPress reforçado por Yoast (schema, sitemaps, canonical, hreflang).
- Acessibilidade. Controlo integral sobre semântica, landmarks ARIA e tokens de design, transposto para o tema personalizado.
- Manutenção pelo cliente. Em WordPress, o conteúdo é editável de forma autónoma em Gutenberg e em wp-admin, sem dependência do prestador.
- Segurança. Cabeçalhos endurecidos (HSTS, CSP nonce-based, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy), enumeração de utilizadores bloqueada, credenciais rotacionadas e plugins não usados desactivados (ver §9).
4.4. Aderência à brief
A entrega cumpre a indicação WordPress + E-Goi da brief: o site está vivo em WordPress com tema personalizado, e a integração E-Goi está implementada através de um proxy do lado do servidor. A arquitectura de conteúdo é integralmente nativa do WordPress — os tipos de entidade mapeiam em Custom Post Types com ACF e taxonomias partilhadas; a lista de publicações remete para a fonte oficial em liacc.fe.up.pt/publications. Em §9 detalha-se a execução da migração e a auditoria final.
Arquitectura de informação
5.1. Navegação
A navegação primária foi padronizada num modelo de seis itens — Research, People, Education, News & Events, Collaborate e About — com mega-menus em Research, News & Events, Collaborate e About. Esta topologia replica o denominador comum da arquitectura de informação de centros de investigação de referência (MIT CSAIL, Mila, Max Planck, Alan Turing Institute, INESC TEC), onde as secções de Eventos/Seminários e Careers são quase universais e o rótulo ambíguo «Work» não existe.
A barra utilitária do header concentra Search, My account, Shop (despromovida de item institucional para ícone) e o painel de idioma/tema/tamanho de texto. O presente relatório de projecto — sendo meta-trabalho da unidade curricular — foi retirado da navegação institucional e remetido para a meta-zona no rodapé, mantendo a separação entre a oferta do LIACC e os entregáveis de consultoria. A topologia reduz a dispersão identificada na análise do site actual do LIACC (oito secções em navegação plana).
5.2. Modelo de cross-linking
Todas as entidades do modelo de conteúdo ligam bilateralmente através de um padrão único — Person ↔ Publication ↔ Project ↔ Area ↔ Thematic ↔ Unit. Cada página de detalhe apresenta uma sidebar com as ligações relevantes (content + sidebar pattern), aprovado como padrão de IA durante a Sprint 2 do planeamento Notion.
5.3. Publicações — ligação à fonte oficial
A secção de publicações do site funciona como espelho indexado da fonte canónica. A página de listagem integra um banner explícito com a origem dos dados e ligação directa para liacc.fe.up.pt/publications, preservando a autoridade da fonte.
5.4. Inventário de rotas
- Página inicial & sobre o LIACC
- Índice + 7 páginas de áreas de investigação
- Índice + 7 páginas de linhas temáticas
- Directório (espelho de 101 membros) + 11 perfis curados
- Índice + 31 páginas de projectos
- Publicações — espelho indexado da fonte oficial (sem página por publicação)
- Índice + 4 página de notícias
- Índice de eventos & seminários + 4 eventos
- Educação (6 programas), pólos, contacto, newsletter
- Colaborar (parcerias) e Careers (vagas)
- Índice de blog + 20 artigos
- Loja + 9 produtos + manifestação de interesse via E-Goi
- Conta de utilizador (tópicos guardados e preferências)
- Auditoria SEO e este relatório (PT/EN)
A mesma arquitectura de informação está publicada em WordPress em cerca de 123 rotas (páginas hierárquicas, singles dos CPT, arquivos de taxonomia, blog e landings), com URLs alinhados à IA e redireccionamentos 301 a partir do site antigo.
Sistema de design e identidade visual
6.1. Tokens
O sistema é totalmente token-based, exposto como CSS custom properties em static/assets/liacc.css. Não há pré-processador nem toolchain: os tokens são consumidos directamente pelo CSS, pelo que não existem divergências entre origem e produção.
Paleta de marca
#EEF4FB#ADC8E7#2C60A8#1A3C6E#112440#0A172APaleta de acento (AI / domínio)
#EAFBF6#A1ECD3#3FC49A#22A67F#146A53Paleta de texto e superfície
#0B1220#28334A#5B6678#F6F8FC#EEF1F76.2. Tipografia
Display · Source Serif 4
Trustworthy AI, shipped.
Body · Inter
Família sans-serif neutra e legível, utilizada em interface, texto corrido e metadados. Activa font-display: swap e preconnect para reduzir o impacto de carregamento.
6.3. Logótipo e favicon
Na ausência do mark oficial do LIACC, foi desenhado um logótipo tipográfico de transição: um L em negativo branco sobre fundo azul-noite, acompanhado de um nó verde-teal ligado por um filete fino. O L identifica a sigla; o nó representa a dimensão AI / computação. Ocupa os mesmos 36×36 do favicon, escala sem perda e é substituível sem impacto sobre o restante sistema.
6.4. Componentes
O inventário de componentes cobre cabeçalho e rodapé, hero, barra de estatísticas, secções tipadas, cartões de diferentes densidades (área, linha temática, projecto, pessoa, notícia, produto, blog post), badges, botões (primário, acento, contorno, fantasma, específicos de dark mode), avatares, breadcrumbs, cabeçalhos de página (claro e escuro), padrão content + sidebar, barra de filtros, linha de publicação, call-to-action de produto, tabela de carrinho e painel de acessibilidade.
Cada componente está tokenizado: a alteração de um token propaga-se consistentemente. Esta consistência foi verificada nas páginas novas (blog, account, newsletter, SEO, relatório) — todas reutilizam as mesmas classes e padrões, sem estilos ad-hoc.
6.5. Placeholders visuais
Todas as imagens do site são SVG nativos desenhados para o efeito: 9 ilustrações de produto para a loja (uma por SKU), seis capas temáticas para o blog (Research, Applied, Opinion, Tutorial, Lab notes, Events), sete placeholders temáticos partilhados entre projectos e notícias (Saúde, Cidades Inteligentes, Indústria, Administração Pública, Infraestruturas, Entretenimento e um geral). Esta aproximação garante peso reduzido (aprox. 1,5 KB por ilustração), independência de resolução e identidade visual consistente até à substituição por fotografia real.
6.6. Acessibilidade e modo escuro
O sistema incorpora um painel de acessibilidade fixo no header, com comutação entre tema claro e escuro (com detecção de prefers-color-scheme) e quatro escalas de tamanho de tipo. As preferências são persistidas em localStorage e aplicadas antes do primeiro paint para evitar flash of unstyled content. O sistema cumpre WCAG AA em contraste, possui skip-link, aria-current na navegação activa, landmarks semânticos e respeita prefers-reduced-motion.
Na entrega em WordPress, estas garantias foram verificadas e reforçadas: correcção de contraste em modo escuro para WCAG AA, anel de foco visível (incluindo em tema escuro), cobertura integral de alt e correcção da hierarquia de cabeçalhos.
Sprints e entregas
7.1. Planeamento original (Notion)
O hub Notion do grupo estabeleceu seis sprints de duas semanas, somando o ciclo completo entre análise e launch. Cada sprint teve Sprint Goal, Definition of Done e epics afectos.
7.2. Execução real
A execução seguiu fluxo Kanban contínuo, absorvendo todos os objectivos dos seis sprints em ciclos mais curtos. O ritmo foi determinado por dependências entre epics, e não por janelas calendarizadas. Todos os objectivos foram concluídos, culminando na migração e publicação do site em WordPress (ver §9).
7.3. Entregáveis concretos
- Site institucional vivo em WordPress com tema personalizado
liacc, em liacc.gablima.com. - Modelo de conteúdo nativo em WordPress — Custom Post Types (
person,project,news_item,education,unit), taxonomias (research_area,thematic_line) e campos ACF — com cross-linking completo entre tipos de entidades. - Cerca de 123 rotas publicadas (páginas hierárquicas, singles dos CPT, arquivos de taxonomia, blog e landings), com URLs alinhados à IA e redireccionamentos 301 a partir do site antigo.
- Blog com 20 artigos originais em temas contemporâneos de IA.
- Loja com 9 produtos e manifestação de interesse via E-Goi (não há checkout: o produto é reservado por registo de interesse, com divulgação explícita de que se trata de protótipo).
- Directório de 101 membros (11 com perfil curado), com e-mail real e biografias importadas dos perfis oficiais do LIACC para o WordPress, e ligação cruzada a projectos, áreas e linhas temáticas.
- Área de utilizador com tópicos guardados e preferências, ligada ao funil E-Goi.
- Integração E-Goi por proxy do lado do servidor (chave em
wp_option), com opt-in único e registo de prova de consentimento RGPD. - Sistema de design tokenizado, documentado e verificado em modo claro e escuro, transposto para o tema WordPress.
- Auditoria SEO com scorecard, práticas implementadas e recomendações priorizadas; Yoast (focus keyphrases, meta-descrições, schema, sitemaps EN+PT, canonical, hreflang) em produção.
- Estratégia de marketing funnel com seis estágios, activações por cohort e stack implementada em E-Goi.
- Suporte bilingue (PT-PT / EN) com Polylang e páginas PT reais, comutador de idioma e
hreflang. - LIACC Companion «Lúmen» — assistente conversacional MVP com três modos, entregue como trabalho individual (ver §10).
Aderência à grelha de avaliação
A brief da UC estabelece uma avaliação decomposta em 70% de trabalho de grupo e 30% de trabalho individual. A tabela que se segue posiciona cada componente face ao que foi efectivamente entregue.
liacc, CPTs, taxonomias, ACF, cerca de 123 rotas e redireccionamentos 301 (ver §4 e §9).Migração para WordPress + E-Goi — execução e auditoria final
A indicação WordPress + E-Goi da brief foi executada e publicada. O site institucional está vivo em liacc.gablima.com, com a arquitectura de informação, o sistema de design e o modelo de conteúdo descritos nos capítulos anteriores transpostos para uma instalação WordPress nativa. Esta secção documenta o que foi efectivamente entregue e, no fim, as lacunas reais identificadas na auditoria final — declaradas com honestidade.
9.1. Migração para WordPress (executada)
- Tema personalizado
liacc— construído de raiz; o conteúdo é editável de forma autónoma em Gutenberg (cada secção de página é um bloco HTML personalizado editável) e os singles dos CPT renderizamthe_content, editável em wp-admin; as listagens são dinâmicas via shortcodes. - Custom Post Types —
person,project,news_item,educationeunit, com taxonomias partilhadasresearch_areaethematic_linee campos Advanced Custom Fields (ACF) para as relações de cross-linking. - Estrutura de páginas hierárquica, blog com 20 posts, e cerca de 123 rotas (páginas, singles, arquivos de taxonomia, blog e landings), com URLs alinhados à IA e redireccionamentos 301 a partir do site antigo.
- Pessoas — e-mail real e biografias («About me») importadas dos perfis oficiais do LIACC para dentro do WordPress; as páginas são auto-contidas, sem ligações externas para o site antigo.
9.2. SEO (em produção)
Yoast configurado com focus keyphrases, meta-descrições e scores de SEO e legibilidade escritos no indexable; sitemaps XML em EN e PT; canonical; hreflang; schema/JSON-LD; e categorias/tags por item. O detalhe e o scorecard autocrítico encontram-se na auditoria SEO.
9.3. Integração com E-Goi (executada)
- Proxy do lado do servidor — a chave da API reside numa
wp_option, nunca exposta no cliente. - Formulários ligados — newsletter, manifestação de interesse em educação, colaborar, contacto, «reservar interesse» na loja e tópicos da conta.
- Opt-in único — os contactos entram activos; com registo de prova de consentimento RGPD (data/hora + origem + IP em hash).
9.4. Bilingue, segurança, desempenho e acessibilidade
- Bilingue PT/EN — Polylang com páginas PT reais (sobre, investigação, educação, colaborar, contacto, notícias, home, loja) e
data-i18npara a interface; comutador de idioma ehreflang. - Segurança — HSTS, Content-Security-Policy (nonce-based para visitantes anónimos), X-Frame-Options, X-Content-Type-Options, Referrer-Policy e Permissions-Policy; enumeração de utilizadores bloqueada; credenciais de administração rotacionadas; plugin Astra Starter Templates (não usado) desactivado; sem segredos no repositório.
- Desempenho — caching imutável e gzip nos assets; imagem de hero reduzida de 418 KB para 289 KB e em cache; imagens sobredimensionadas reduzidas (aprox. −89%) com
srcsetresponsivo. - Acessibilidade — correcção de contraste em modo escuro para WCAG AA, anel de foco visível (incluindo em tema escuro), cobertura integral de
alte correcção da hierarquia de cabeçalhos.
9.5. Veracidade do conteúdo
Na transposição para WordPress, foram removidas afirmações fabricadas que existiam no rascunho de conteúdo (por exemplo «3 711 publicações», «maior laboratório de IA» ou «um dos primeiros»), suavizados exageros no blog e adicionadas advertências explícitas de «protótipo — não é um serviço em produção» nas funcionalidades de proposta (como a loja). O site apresenta apenas o que é verificável.
9.6. Auditoria final — lacunas reais
/wp-json/liacc/v1/ a pedir ao alojamento (falso-positivo 406 em pedidos POST de browser sob carga).Trabalho individual (30%) — LIACC Companion «Lúmen»
A componente individual foi entregue como MVP funcional, integrado no site publicado — não como mera proposta. Chama-se LIACC Companion «Lúmen»: um assistente representado por uma mascote em forma de lâmpada (lançador em SVG animado, com a identidade da marca em azul-noite e verde), bilingue (PT/EN) e compatível com a Content-Security-Policy do site. As secções seguintes descrevem o que foi construído e articulam-no com os entregáveis de marketing já produzidos.
10.1. Tese de partida
Qual é o objectivo primário de um site académico? Construir e sinalizar capital reputacional científico. Não é divulgar publicações — isso é mecanismo; não é vender mestrados — isso é consequência; não é atrair indústria — isso é derivado. O objectivo primário é o activo que se traduz em três retornos concretos:
- Captação de financiamento — FCT, Horizon Europe, ERC, contratos com indústria.
- Atracção de talento — doutorandos com bolsa, pós-docs internacionais, concursos.
- Parcerias estratégicas — B2B, B2G, redes internacionais, transferência de tecnologia.
10.2. Diagnóstico do site actual
Um site informacional num mundo que pede um site relacional. Quatro segmentos com intenções distintas — investigador, estudante, indústria, comunidade internacional — recebem a mesma narrativa institucional indiferenciada.
- Navegação plana — oito secções no primeiro nível, sem hierarquia visível e com comportamento móvel deficitário.
- Acrónimos sem chave — PRODEI, PDCC, MAP-I, LASI usados sem contextualização para o leitor externo.
- Densidade textual — conteúdo acumulado por adição, nunca por curadoria; desencoraja a leitura.
- Tecido relacional ausente — sem aquisição, sem retenção, sem conversão; tráfego restrito a quem já conhece a marca.
10.3. O que foi entregue — três modos
O Lúmen é uma plataforma com três modos, todos funcionais no site:
A partir dos tópicos guardados na conta do utilizador, sugere conteúdo relevante através de
WP_Query (sem LLM). É a camada de retenção: a conta com sessão é a memória.Identifica o público — estudante, investigador, indústria ou comunidade internacional — e encaminha para as páginas certas do site.
Pesquisa o conteúdo do próprio site (pesquisa nativa do WordPress) e um LLM gratuito (Groq, Llama-3.3-70B) responde apenas a partir dessas páginas, com citações e um fallback explícito de «não disponho dessa informação».
A memória do companheiro é a própria conta com sessão: os tópicos guardados alimentam o modo Descobrir e o contexto da conversa.
10.4. Decisões técnicas e salvaguardas
Diagnóstico honesto do que ficou dentro e fora do âmbito, com as salvaguardas correspondentes.
Recuperação sobre o conteúdo do site, não RAG sobre todas as publicações
O deck inicial previa RAG sobre todos os artigos do LIACC. Por viabilidade, o âmbito foi deliberadamente reduzido para recuperação sobre o conteúdo do próprio site (pesquisa do WordPress), mantendo respostas ancoradas e citáveis.
Salvaguardas · Apenas conteúdo público é enviado ao LLM; citações obrigatórias; fallback explícito quando a resposta não consta das páginas.
Memória = a conta com sessão
A memória do Companion é a própria conta do utilizador (tópicos guardados), não um histórico identificado adicional.
Salvaguardas · Só conteúdo público vai para o LLM; chave do provider no lado do servidor; comportamento compatível com CSP; sem dados pessoais enviados ao modelo.
Proxy agnóstico do fornecedor
O proxy que medeia o LLM é independente do fornecedor.
Salvaguardas · Pode trocar-se para Claude (ou outro) mais tarde sem alterar a interface; a chave nunca é exposta no cliente.
Protótipo assumido
O Lúmen é entregue como MVP funcional, não como serviço completo de produção.
Salvaguardas · As funcionalidades de proposta exibem advertência explícita; o objectivo é demonstrar valor e ancoragem, não substituir um motor de pesquisa académico completo.
10.5. Aquisição e conversão — a estratégia de marketing
Blog SEO atrai. Registo retém. Cada artigo é uma porta de entrada construída para uma pergunta concreta («Como aplicar RL em mobilidade urbana?», «PRODEI vs MAP-I?»), alinhada às linhas temáticas e optimizada para Google e para LLMs. O registo é apresentado como ganho de utilidade, nunca como muro. Quatro alavancas:
- Registo como utilidade — tópicos guardados, recomendações do Lúmen, preferências entre sessões.
- Conteúdo editorial premium — whitepapers, industry reports, guias; gating eticamente neutro.
- Newsletter por linha temática — Saúde, Cidades, Indústria; lead magnet de altíssima qualificação.
- Acesso prioritário a eventos — open days, workshops, seminários, anúncios de bolsas.
Esta camada concretiza directamente os entregáveis de marketing produzidos no projecto: a estratégia de marketing (funil de audiência e activações por cohort) e a jornada de leads (drip de 7 emails despoletado pela subscrição, em E-Goi). Os formulários de manifestação de interesse em Collaborate, Careers e na página de Educação são as portas de entrada deste funil, todos ligados ao proxy E-Goi.
10.6. Métricas-alvo (a medir com analítica)
As metas que se seguem orientarão a avaliação do impacto. A analítica própria (first-party, sem cookies, conforme RGPD) já está instalada (ver §9.6), pelo que estas metas passam a ser mensuráveis; mantêm-se como objectivos, não resultados medidos.
10.7. Evolução pós-MVP — fidedignidade e relevância
Após a entrega do MVP, o modo Conversar foi endurecido para máxima fidelidade factual e relevância, por ser este o requisito crítico de um assistente institucional:
- Recuperação semântica — embeddings multilingues (Jina v3) indexam todo o conteúdo do site (314 páginas/CPTs); uma pergunta em português encontra conteúdo em inglês sem depender de palavras-chave.
- Anti-alucinação em camadas — bloco de factos institucionais verificados na fonte, temperatura 0, auto-verificação de grounding, limiar de confiança da recuperação e um verificador de fidelidade em 2.ª passagem que corrige ou recusa afirmações não suportadas; cita apenas as fontes efectivamente usadas.
- Memória e proatividade — contexto multi-turno, perguntas iniciais e de seguimento, e sugestão contextual à página em que o visitante está.
- Confiança e operação — respostas em markdown, botão copiar, feedback 👍/👎, registo anónimo de perguntas (sem IP, RGPD) com painel no wp-admin, cache de respostas e protecção contra injecção de instruções.
Em paralelo, o diretório de pessoas foi alinhado à página pública oficial e todos os indicadores verificáveis do site reconciliados com a fonte; a captação de leads em E-Goi passou a registar a temperatura do lead (quente/morno/frio) e a mensagem do formulário de contacto (ver §9).
Fecho. Transformação digital não é adopção de tecnologia — é a alteração efectiva da relação entre a instituição e os seus públicos. O LIACC produz inteligência artificial diariamente; o Lúmen, entregue e a funcionar, garante que o site se apresente à altura.
Entregáveis de consultoria
Para além do MVP navegável, o projecto produziu quatro entregáveis de consultoria autónomos. Foram retirados da navegação institucional — por serem meta-trabalho da unidade curricular, e não oferta do LIACC — e reagrupados aqui, dentro do relatório, onde pertencem.
Estratégia de marketing
Funil de audiência, activações por cohort e plano de integração E-Goi.
Jornada de leads
Drip de 7 emails ao longo de 30 dias, despoletado pela subscrição — desenhado para E-Goi.
Auditoria SEO
Scorecard transparente, práticas implementadas e próximos passos priorizados.
Sumário em inglês
Versão condensada do relatório para revisores internacionais.
Considerações finais
O trabalho foi executado individualmente, assumindo uma postura de consultoria técnica. A entrega consiste num MVP funcional, auditável e já publicado, que cumpre o objectivo de negócio — site institucional LIACC vivo em WordPress (liacc.gablima.com) com arquitectura de informação sólida, sistema de design coerente, loja com manifestação de interesse via E-Goi, blog activo, área de utilizador, integração E-Goi, estratégia de marketing funnel, conformidade SEO e acessibilidade. A indicação WordPress + E-Goi da brief foi efectivamente cumprida (ver §9).
A componente individual (§10 — LIACC Companion «Lúmen») foi entregue como MVP funcional — um assistente de descoberta, orientação e conversação ancorada, integrado no site. A estratégia de marketing e a jornada de leads em E-Goi não são anexos: são a camada de aquisição e conversão, já operacional, que alimenta o funil.
A analítica (própria, first-party), as cópias de segurança e a rotação de credenciais já foram resolvidas; as lacunas remanescentes — cauda de SEO/legibilidade, Brotli/AVIF e uma exclusão de Mod_Security a pedir ao alojamento — estão declaradas com honestidade na auditoria final (§9.6).
Agradece-se aos docentes João Almeida, Carlos Alves e Samuel Anjos a disponibilidade para avaliação.
Documento navegável. Uma versão em inglês está disponível em /report/en/. A fonte canónica de publicações do LIACC encontra-se em liacc.fe.up.pt/publications.